783506 - Establish method to automatically insert specific RPMs into mrepo

Status: RESOLVED WONTFIX

(Cloud Services :: Operations: Miscellaneous, task)

Description

[Gene Wood [:gene]]

Establish a method to enable QA to insert rpms, which are listed in a whitelist, into mrepo to make them available to yum and puppet for deployment

This insertion process would need to either call existing scripts which do the yum re-indexing or kick off those processes itself.

Ideally the access control for this (to constrain access to only QA) would utilize existing ACL group data (e.g. LDAP groups, or some existing authoritative indicator that a given user is in QA or not)

Potential solutions :
* script on a host (mrepo?) executable only by QA folks which moves the rpm from where they're scp'd it up into mrepo [this would use unix file permissions to control access by who can execute the script]
* a web interface that one does an ldap auth to and an http upload [this would control access by a backend ldap auth call]
* a script on a host that (mrepo?) which checks `whoami` against a user whitelist [access control is hard coded into a local user whitelist file =( ]

This tool should respond back to the requester in machine readable form about the success of failure of the mrepo addition

Comment 1

[Bob Micheletto [:bobm]]

Proposed solution: (Thanks to Chris Kolosiwsky for suggesting it.)

1. When a new RPM train tag is added to the github repository for broswerid, or browserid hotfix, Jenkins is triggered to build the RPM.  
2. Jenkins builds the RPM, ideally signing it, and pushes it to an mrepo server.  
3. A job on the mrepo server, performs sanity checks on the RPM: verifies signature, potentially examining the file inventory and trigger scripts, and then if everything looks good adds it to the mozilla-services mrepo.

Comment 2

[Bob Micheletto [:bobm]]

The staging and production BrowserID servers can successfully query the mozilla-services mrepo using: yum --disablerepo="*" --enablerepo="*services" list

Verification of the suitability of triggering an RPM build off of new train tags has been requested of the BrowserID developers.

Requirements for adding a new build process to Jenkins have been requested from the current Jenkins contact listed in mana. 

Allowing Jenkins to copy files to the mrepo server may require opening up firewall rules, adding routes, and will definitely require distributing SSH keys for the source and target copy users.  The current maintainers for Jenkins and mrepo have been queried for their input.

Comment 3

[Gene Wood [:gene]]

I manually added browserid-server-0.2012.07.30-3.el6_108160.x86_64.rpm to mrepo "mozilla-services" repo for 6Server x86_64 to test with.

Comment 4

[Bob Micheletto [:bobm]]

Submitted security review bug 785539.

Spoke with Identity development and received the following feedback:
    1. Ensure Jenkins access for Services Operations team members.
    2. Provide documentation to Services Operations personnel for Jenkins builds.

Will submit bugs to follow up on the todo items above pending outcome of security review.

Comment 5

[Bob Micheletto [:bobm]]

Identity Development verified that triggering and RPM off of a new train tag was suitable.

The Mozilla Jenkins maintainer has no problem with the RPM builds, but expressed concern about pushing the RPM from the Jenkins server, and suggested that the RPM might best be pulled by mrepo from Jenkins.  That is process that has been submitted for review.

Comment 6

[Bob Micheletto [:bobm]]

No longer doing deploys this way.  Closing this ticket.