[Jenkins-infra] Board election (INFRA-536)

R. Tyler Croy tyler at monkeypox.org
Tue Oct 18 19:53:04 UTC 2016


(replies inline)

On Tue, 18 Oct 2016, nicolas de loof wrote:

> 2016-10-18 21:18 GMT+02:00 R. Tyler Croy <tyler at monkeypox.org>:
> 
> > (replies inline)
> >
> > On Tue, 18 Oct 2016, nicolas de loof wrote:
> >
> > > l have some cycles I can spend on INFRA-536 (implement board election
> > > voting)
> > > I don't know the context about Apache STeVe, IIUC there have been some
> > > prior experiments to integrate with it jenkins infra.
> >
> >
> > orrc suggested Apache Steve but it's *way* too immature IMHO, has some
> > problematic infrastructure requirements (lol elasticsearch), and lacks
> > integration with LDAP :/
> >
> >
> > > I can give it a try, other option is for me to implement STV inside
> > > jenkins.io account application,
> > > using https://wiki.jenkins-ci.org/display/JENKINS/Board+Election+Process
> > as
> > > a spec.
> >
> >
> > This is the direction I was thinking on hacking towards. The only
> > persistent
> > store behind the account-app is LDAP, which is certainly not where votes
> > should
> > go IMO. One approach I was thinking about was configuring an "election
> > transaction file" which would be append-only, and then making the
> > account-app
> > write votes to that file.
> >
> > That would make the changes to the account-app minimal, and then we can
> > just
> > write some Groovy or Python to process the election transaction log.
> >
> >
> Ho wis this app hosted ? I can see a Dockerfile, so wonder if we run a
> docker container. In such case I guess we can get a volume with backup ?
> Because replacing a database (elastic or whatever) with a flat file doesn't
> seem to me a way to make this a robust solution :P


The account-app is deployed in a standalone container which only has access to
LDAP (different host).

Right now there is no external storage of any kind attached to it, relational
database or not.



> > The challenge I haven't given much thought to was how to present the
> > election
> > options, basically, how would the account-app know who the candidates
> > would be?
> > How would it know how long the election should run, etc.
> >
> 
> Administrator UI seems to be the simplest option.


See previous statement about no currently attached database.



That said, if you believe that attaching SQL Server (yay Azure) as a backend to
the account-app to make some of these tasks easier, I don't think that's
unreasonable. The account-app is not currently deployed into Azure, but
certainly will need to migrate regardless of this work. I can prioritize that
work if it makes your life implementing board elections easier.


The flat-file transaction log would have the least impact as far as underlying
infrastructure changes, but I agree, it kinda sucks.


If you want to expand the infrastructure requirements for account-app to
support board elections, perhaps create a wiki page with a proposed
architecture design and requirements + nice-to-haves?



Cheers
- R. Tyler Croy

------------------------------------------------------
     Code: <https://github.com/rtyler>
  Chatter: <https://twitter.com/agentdero>

  % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.jenkins-ci.org/pipermail/jenkins-infra/attachments/20161018/317283af/attachment.asc>


More information about the Jenkins-infra mailing list