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

nicolas de loof nicolas.deloof at gmail.com
Thu Oct 20 12:17:02 UTC 2016


I've setup a voting page prototype on account app :
https://github.com/ndeloof/account-app

not trivial to test, as it relies on jquery which is provided by
jenkins-ci.org-theme BUT does not allow cross origin so can't be used if
you run the app on localhost :-\

election open/close period is stored on configuration file.
about storing election data : I suggest we add a "vote" attribute to LDAP
users when the vote from web UI. Same to track election candidates




2016-10-18 21:53 GMT+02:00 R. Tyler Croy <tyler at monkeypox.org>:

> (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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.jenkins-ci.org/pipermail/jenkins-infra/attachments/20161020/7550cf96/attachment.html>


More information about the Jenkins-infra mailing list