Page MenuHomePhabricator

Cannot remove all Puppet classes from a Labs instance
Closed, ResolvedPublic

Description

I want to disable this puppet agent at this instace (there are no other roles currently running), but every time I unchecked the role at Special:NovaInstance, and confirm, nothing happens. When I go back, the tick is set, so the role is not disabled. Can you try to disable it for me? Thanks!


Project: rcm
Instance: rcm-3.rcm.eqiad.wmflabs

Event Timeline

Luke081515 raised the priority of this task from to Needs Triage.
Luke081515 updated the task description. (Show Details)
Luke081515 added a subscriber: Luke081515.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 1 2016, 11:51 PM
Luke081515 updated the task description. (Show Details)Jan 1 2016, 11:53 PM
Luke081515 set Security to None.
scfc added a subscriber: scfc.EditedJan 2 2016, 1:24 AM

What do you mean by "nothing happens"? Do you get a confirmation "Successfully did X", but the configuration stays the same? Do you get a blank page?

Does role::phabricator::labs appear more than once on the configuration page as a checkbox?

I took some screenshots:
At first, I use configure:


and uncheck this role:
(This are all roles I have, and only this one is enabled)
After that I press submit, this message arrives:

But after I'm back at Special:NovaInstance, and I click configure again, nothing changed:

I can confirm this for toolsbeta-webproxy-01 and trying to uncheck all Puppet classes; unchecking individual ones work (except for the last one).

Maybe this is related to the change of the LDAP server and tightening (?) of the schema. So there are two parts to this bug:

  1. It's impossible to remove all Puppet classes.
  2. Despite 1., wikitech claims that it has "successfully modified" the instance when it hasn't.
scfc renamed this task from Could not remove role::phabricator::labs from rcm-3 to Cannot remove all Puppet classes from a Labs instance.Jan 2 2016, 3:27 AM

wikitech claims that it has "successfully modified" the instance when it hasn't.

As far as I can tell from looking at the OSM and LdapAuthentication code, this should only happen if ldap_modify (the PHP function) is returning true.

Ah, no, actually, after playing around with the code live on silver, I think I see what's going wrong here.

Change 261906 had a related patch set uploaded (by Alex Monk):
NovaPrivateHost: Ensure puppetclass/puppetvar LDAP attributes get modified

https://gerrit.wikimedia.org/r/261906

Krenair claimed this task.Jan 2 2016, 6:07 AM
scfc added a comment.Jan 2 2016, 6:30 AM

So looking at the code you mean that the bug always existed, but noone encountered it? (Which would be possible because removing all Puppet classes is very rare.)

Yeah, and removing all puppet classes is also only very recently possible since we used to include role::labs::instance this way in the past (and do not anymore)

scfc added a comment.Jan 2 2016, 6:36 AM

Ah, yes, that was in LDAP. Makes sense.

I've manually removed this class from LDAP to unblock Luke.

Change 261906 merged by jenkins-bot:
NovaPrivateHost: Ensure puppetclass/puppetvar LDAP attributes get modified

https://gerrit.wikimedia.org/r/261906

This should go live on wikitech tomorrow with the MW deployment train

Krenair closed this task as Resolved.Jan 13 2016, 8:56 PM