Closed
Bug 870414
Opened 12 years ago
Closed 12 years ago
setup scheduler manifests in puppetAgain
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: hwine, Assigned: rail)
References
Details
Attachments
(5 files, 5 obsolete files)
415 bytes,
patch
|
catlee
:
review+
rail
:
checked-in+
|
Details | Diff | Splinter Review |
2.46 KB,
patch
|
catlee
:
review+
rail
:
checked-in+
|
Details | Diff | Splinter Review |
10.61 KB,
patch
|
rail
:
review+
rail
:
checked-in+
|
Details | Diff | Splinter Review |
1.98 KB,
patch
|
dustin
:
review+
dustin
:
feedback+
rail
:
checked-in+
|
Details | Diff | Splinter Review |
1.46 KB,
patch
|
dustin
:
review+
rail
:
checked-in+
|
Details | Diff | Splinter Review |
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.
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
Assignee | ||
Comment 2•12 years ago
|
||
Hal, is there anything left here? AFAIK we moved the scheduler masters to bm81.
Flags: needinfo?(hwine)
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → rail
Flags: needinfo?(hwine)
Assignee | ||
Comment 3•12 years ago
|
||
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)
Assignee | ||
Comment 4•12 years ago
|
||
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 5•12 years ago
|
||
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+
Assignee | ||
Comment 6•12 years ago
|
||
"python setup.py release sdist" creates a tarball without "dev" suffix now
Attachment #825885 -
Flags: review?(catlee)
Updated•12 years ago
|
Attachment #825885 -
Flags: review?(catlee) → review+
Assignee | ||
Comment 7•12 years ago
|
||
Comment on attachment 825885 [details] [diff] [review]
[buildapi] release alias
https://hg.mozilla.org/build/buildapi/rev/7e02b276acf4
Attachment #825885 -
Flags: checked-in+
Assignee | ||
Comment 8•12 years ago
|
||
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)
Assignee | ||
Comment 9•12 years ago
|
||
No more hacky modules using a mercurial checkout.
Attachment #815894 -
Attachment is obsolete: true
Assignee | ||
Comment 10•12 years ago
|
||
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)
Assignee | ||
Comment 11•12 years ago
|
||
forgot to add and empty __init__.py
Attachment #826384 -
Attachment is obsolete: true
Attachment #826384 -
Flags: review?(catlee)
Attachment #826793 -
Flags: review?(catlee)
Comment 12•12 years ago
|
||
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+
Assignee | ||
Comment 13•12 years ago
|
||
* addressed comments
* tested and seen a noop check
* carry over r=dustin
Attachment #826790 -
Attachment is obsolete: true
Attachment #826803 -
Flags: review+
Updated•12 years ago
|
Attachment #826793 -
Flags: review?(catlee) → review+
Assignee | ||
Comment 14•12 years ago
|
||
Comment on attachment 826793 [details] [diff] [review]
[buildapi] add console_scripts entry points
https://hg.mozilla.org/build/buildapi/rev/250614ab1b08
Attachment #826793 -
Flags: checked-in+
Assignee | ||
Comment 15•12 years ago
|
||
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 16•12 years ago
|
||
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.
Updated•12 years ago
|
Attachment #826874 -
Flags: feedback?(dustin) → feedback-
Assignee | ||
Comment 17•12 years ago
|
||
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)
Updated•12 years ago
|
Attachment #826954 -
Flags: feedback?(dustin) → feedback+
Assignee | ||
Comment 18•12 years ago
|
||
Comment on attachment 826803 [details] [diff] [review]
[puppet] selfserve-agent
https://hg.mozilla.org/build/puppet/rev/5acc6e2544b9
Attachment #826803 -
Flags: checked-in+
Assignee | ||
Comment 19•12 years ago
|
||
Comment on attachment 826954 [details] [diff] [review]
[puppet] bouncer nagios check
This has been tested and worked fine.
Attachment #826954 -
Flags: review?(dustin)
Updated•12 years ago
|
Attachment #826954 -
Flags: review?(dustin) → review+
Assignee | ||
Comment 20•12 years ago
|
||
Comment on attachment 826954 [details] [diff] [review]
[puppet] bouncer nagios check
https://hg.mozilla.org/build/puppet/rev/d340a4994244
Attachment #826954 -
Flags: checked-in+
Assignee | ||
Comment 21•12 years ago
|
||
Attachment #830408 -
Flags: review?(dustin)
Updated•12 years ago
|
Attachment #830408 -
Flags: review?(dustin) → review+
Assignee | ||
Comment 22•12 years ago
|
||
Comment on attachment 830408 [details] [diff] [review]
use $nrpe::settings::plugins_dir
https://hg.mozilla.org/build/puppet/rev/b1a992ffcc4d
Attachment #830408 -
Flags: checked-in+
Assignee | ||
Comment 23•12 years ago
|
||
I think we are done here! \o/
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•