Closed Bug 870414 Opened 12 years ago Closed 12 years ago

setup scheduler manifests in puppetAgain

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hwine, Assigned: rail)

References

Details

Attachments

(5 files, 5 obsolete files)

The scheduler master (currently bm36) was a special case in the old puppet manifests, even before the addition of multiple masters on the box. Making separate from bug 803823 to highlight the differences.
Note: bug 823948 just added a new service to the scheduler host. It would be ideal if that could get folded into the new puppet configs, but the service can easily be installed manually again.
Product: mozilla.org → Release Engineering
Hal, is there anything left here? AFAIK we moved the scheduler masters to bm81.
Flags: needinfo?(hwine)
Assignee: nobody → rail
Flags: needinfo?(hwine)
Attached patch [puppet] selfserve-agent (obsolete) — Splinter Review
One stop closer to the moment when we can kill bm36 with fire! :) * I still need to add bouncer_check nagios plugin/check * Not sure what is the best way to manage a hg checkout (buildapi) * Not tested. At all.
Attachment #815894 - Flags: feedback?(dustin)
Callek suggested to extend mercurial::repo so it keeps repo checkout up to date, something like: define mercurial::repo($hg_repo, $dst_dir, $user, $branch="", $rev="", $auto_update=false)
Comment on attachment 815894 [details] [diff] [review] [puppet] selfserve-agent Review of attachment 815894 [details] [diff] [review]: ----------------------------------------------------------------- ::: modules/config/manifests/base.pp @@ +66,5 @@ > $releaserunner_sendchange_master = "" > $releaserunner_ssh_username = "" > $releaserunner_ssh_key = "" > $install_avds = "no" > + $selfserve_agent_root = "/builds/selfserve-agent" Does this really need a config argument? Particularly since the manifest invokes dirs::builds, which basically assumes it's in /builds. @@ +67,5 @@ > $releaserunner_ssh_username = "" > $releaserunner_ssh_key = "" > $install_avds = "no" > + $selfserve_agent_root = "/builds/selfserve-agent" > + $selfserve_agent_buildapi = "http://hg.mozilla.org/build/buildapi" This should probably be $selfserve_agent_buildapi_repo @@ +71,5 @@ > + $selfserve_agent_buildapi = "http://hg.mozilla.org/build/buildapi" > + $selfserve_agent_buildapi_branch = "default" > + $selfserve_agent_sendchange_master = "bm81-build_scheduler" > + $selfserve_agent_branches = "http://hg.mozilla.org/build/tools/raw-file/default/buildfarm/maintenance/production-branches.json" > + $selfserve_agent_masters = "http://hg.mozilla.org/build/tools/raw-file/default/buildfarm/maintenance/production-masters.json" These should both be $selfserve_agent_..._json @@ +73,5 @@ > + $selfserve_agent_sendchange_master = "bm81-build_scheduler" > + $selfserve_agent_branches = "http://hg.mozilla.org/build/tools/raw-file/default/buildfarm/maintenance/production-branches.json" > + $selfserve_agent_masters = "http://hg.mozilla.org/build/tools/raw-file/default/buildfarm/maintenance/production-masters.json" > + $selfserve_agent_clobberer = "http://clobberer.pvt.build.mozilla.org/index.php" > + $selfserve_agent_carrot_hostname = "rabbit2.build.scl1.mozilla.com" /me hates on carrot for its SPOFfiness :( @@ +77,5 @@ > + $selfserve_agent_carrot_hostname = "rabbit2.build.scl1.mozilla.com" > + $selfserve_agent_carrot_vhost = "/buildapi" > + $selfserve_agent_carrot_userid = "buildapi" > + $selfserve_agent_carrot_exchange = "buildapi.control" > + $selfserve_agent_carrot_queue = "buildapi-agent-rabbit2" That's a lot of config options to document :) ::: modules/selfserve_agent/manifests/init.pp @@ +46,5 @@ > + creates => "${selfserve_agent::settings::root}/lib/${packages::mozilla::python27::libdirname}/site-packages/buildapi.egg-link", > + user => "${users::builder::username}", > + require => [Python::Virtualenv["${selfserve_agent::settings::root}"], > + Mercurial::Repo["selfserve_agent-buildapi"]]; > + } Ewww, yuck! The best choice here will be to make a buildapi package and put it in the puppetagain python repo. When an upgrade needs to happen, put the new version in there and change the version string in the python::virtualenv. This is what we're doing with mozpool, slaveapi, and a few others. I see the automatic deployment from the branch in services.pp, though. If that's really so common that you don't want to do new releases of buildapi for every change, then I'd rather see python::virtualenv extended to handle this case, maybe with editable => [ "/path/to/package/dir" ]. It can probably use the existing pip_check.py to determine whether the install is complete. ::: modules/selfserve_agent/manifests/services.pp @@ +28,5 @@ > + extra_config => template("${module_name}/extra_config.erb") > + } > + > + exec { > + # TODO: maybe use cronjob instead? Yes please :)
Attachment #815894 - Flags: feedback?(dustin) → feedback+
"python setup.py release sdist" creates a tarball without "dev" suffix now
Attachment #825885 - Flags: review?(catlee)
Attachment #825885 - Flags: review?(catlee) → review+
Dumping my current status. * Need to include buildapi/scripts into tarballs (added to MANIFEST.in) * add console_scripts for selfserve-agent to simplify puppet paths ** it requires renaming selfserve-agent.py to selfserve_agent.py and adding main(). For backward compatibility done by symlinking.
Attachment #826384 - Flags: review?(catlee)
Attached patch [puppet] selfserve-agent (obsolete) — Splinter Review
No more hacky modules using a mercurial checkout.
Attachment #815894 - Attachment is obsolete: true
Attached patch [puppet] selfserve-agent (obsolete) — Splinter Review
I tested this one and managed to install selfserve-agent. I had to add a lot of dependencies, because otherwise the script refuses to run. :/ I left config::selfserve_agent_root as is to make the selfserve-agent.ini.erb more consistent and we have the same pattern for release-runner. I still need to package buildapi and requests netflows to rabbit2.build.scl1.mozilla.com from bm81
Attachment #826385 - Attachment is obsolete: true
Attachment #826790 - Flags: review?(dustin)
forgot to add and empty __init__.py
Attachment #826384 - Attachment is obsolete: true
Attachment #826384 - Flags: review?(catlee)
Attachment #826793 - Flags: review?(catlee)
Comment on attachment 826790 [details] [diff] [review] [puppet] selfserve-agent Review of attachment 826790 [details] [diff] [review]: ----------------------------------------------------------------- r+ with these minor changes ::: modules/config/manifests/base.pp @@ +76,5 @@ > + $selfserve_agent_carrot_hostname = "rabbit2.build.scl1.mozilla.com" > + $selfserve_agent_carrot_vhost = "/buildapi" > + $selfserve_agent_carrot_userid = "buildapi" > + $selfserve_agent_carrot_exchange = "buildapi.control" > + $selfserve_agent_carrot_queue = "buildapi-agent-rabbit2" These settings (aside from the directory) should be in moco-nodes.pp, not in base.pp ::: modules/selfserve_agent/manifests/init.pp @@ +55,5 @@ > + "sqlalchemy-migrate==0.7.2", > + "wsgiref==0.1.2", > + "zope.interface==4.0.2", > + ]; > + } Does it make sense to move this to `selfserve_agent::install`? ::: modules/selfserve_agent/manifests/services.pp @@ +2,5 @@ > +# License, v. 2.0. If a copy of the MPL was not distributed with this > +# file, You can obtain one at http://mozilla.org/MPL/2.0/. > +class selfserve_agent::services { > + include ::config > + include packages::mozilla::supervisor the supervisord module should be including this, so no need to do so here
Attachment #826790 - Flags: review?(dustin) → review+
* addressed comments * tested and seen a noop check * carry over r=dustin
Attachment #826790 - Attachment is obsolete: true
Attachment #826803 - Flags: review+
Attachment #826793 - Flags: review?(catlee) → review+
Attachment #826793 - Flags: checked-in+
Attached patch [puppet] bouncer nagios check (obsolete) — Splinter Review
This is the last piece of bm36 AFAIK. nagios-tools's temporarily lives here: https://github.com/rail/build-nagios-tools/compare/packaging I may change its name to something more distinguishable (names are welcome).
Attachment #826874 - Flags: feedback?(dustin)
Comment on attachment 826874 [details] [diff] [review] [puppet] bouncer nagios check The nrpe check is a new subsidiary role for this master, so it should be included in a module of its own (trivial though it is). I know that the master stuff is a mess in puppet, with lots of detail in the node definitions, but we don't need to make it worse :) Do we really need a full virtualenv just for a nagios check? If so, and if that virtualenv is something more general than a bouncer check, I think that it should be installed by a separate module -- or maybe a class in the nrpe module -- and required by nrpe::check::bouncer.
Attachment #826874 - Flags: feedback?(dustin) → feedback-
Something like this? I still would like to install this check in a separate virtualenv for varous reasons: * this is how it's installed on bm36 * it requires an external module (nagiosplugin) * virtualenv is cheap! :) * to keep the nagios script(s) isolated from other environments
Attachment #826874 - Attachment is obsolete: true
Attachment #826954 - Flags: feedback?(dustin)
Attachment #826954 - Flags: feedback?(dustin) → feedback+
Depends on: 934734
Comment on attachment 826954 [details] [diff] [review] [puppet] bouncer nagios check This has been tested and worked fine.
Attachment #826954 - Flags: review?(dustin)
Attachment #826954 - Flags: review?(dustin) → review+
Attachment #826954 - Flags: checked-in+
Depends on: 936475
Attachment #830408 - Flags: review?(dustin)
Attachment #830408 - Flags: review?(dustin) → review+
Attachment #830408 - Flags: checked-in+
I think we are done here! \o/
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: