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

nicolas de loof nicolas.deloof at gmail.com
Thu Oct 20 14:42:26 UTC 2016


s/jquery/fontawesome

Also, board election process require to exclude >2 board members from same
company, BUT this information isn't available on jenkins.io LDAP afaik.
How do we plan to handle this ?

I suggest we add this as a new LDAP attribute that would be set as board
candidates get defined (this would avoid people to enter by themselves with
risk for distinct names for same actual company), wdyt ?

2016-10-20 14:17 GMT+02:00 nicolas de loof <nicolas.deloof at gmail.com>:

> 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/058aad6e/attachment.html>


More information about the Jenkins-infra mailing list