Last modified: 2014-05-28 19:54:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T67549, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65549 - Trebuchet doesn't like when a deployer server is also a minion, a edge case for scap
Trebuchet doesn't like when a deployer server is also a minion, a edge case f...
Status: NEW
Product: Wikimedia
Classification: Unclassified
Deployment systems (Other open bugs)
wmf-deployment
All All
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-20 20:08 UTC by Greg Grossmeier
Modified: 2014-05-28 19:54 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Greg Grossmeier 2014-05-20 20:08:29 UTC
From bug 65542:
> Directory permissions were probably broken initially because in the current
> setup tin is acting as both the deploy server and a minion for the scap deploy.
> When the minion gets the fetch/checkout commands from salt it runs as root. I
> sort of wondered if this would cause problems and I think now I have my answer.
> 
> We can either try to rearrange the way that classes are defined in
> operations/puppet.git to eliminate this problem or figure out how to make
> trebuchet aware of the edge case and avoid updating the deployment server if it
> is also in the minions list.
Comment 1 Bryan Davis 2014-05-20 20:22:49 UTC
[13:15]  <    bd808>	 Tin gets the deployment::target define for scap via mediawiki::sync which is how all of the other nodes get it too.
[13:16] Ryan_Lane	 nods
[13:19]  <    bd808>	 Off the top of my head I can't think of a clean way to keep Deployment::Target['scap'] from applying on tin.
[13:19]  <    bd808>	 How horrible would it be to handle this edge case in trebuchet itself?
[13:20]  <Ryan_Lane>	 hm. it's not a simple edge case to workaround
[13:20]  <Ryan_Lane>	 it's doable using compound matching for targeting
[13:20]  <Ryan_Lane>	 you could use "scap and not deployment server" I believe
[13:21]  <    bd808>	 Ryan_Lane: Where would that go?
[13:22]  <Ryan_Lane>	 inside of the runner code
[13:22]  <Ryan_Lane>	 the runner code looks up the grain, then does a salt call via the salt client api
[13:23]  <    bd808>	 Ryan_Lane: Ok. `grain = "deployment_target:" + grain` .... in deploy.py
[13:24]  <Ryan_Lane>	 yep
[13:24]  <Ryan_Lane>	 and client.cmd(grain, cmd, expr_form='grain', arg=arg, ...
[13:24]  <Ryan_Lane>	 http://docs.saltstack.com/en/latest/ref/clients/index.html#salt.client.LocalClient.cmd
[13:25]  <Ryan_Lane>	 expr_form= <-- that would need to be changed to compound
[13:25]  <    bd808>	 yup.
[13:25]  <Ryan_Lane>	 http://docs.saltstack.com/en/latest/topics/targeting/compound.html
Comment 2 Bryan Davis 2014-05-20 20:23:59 UTC
The runner being discussed in comment #1 is modules/deployment/files/runners/deploy.py in the operations/puppet.git repo.
Comment 3 Bryan Davis 2014-05-28 19:54:56 UTC
This caused problems for /srv/deployment/scap/scap on tin again today. There seems to be really bad corruption of the file permissions on the .git directory whenever  `git deploy` is run.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links