Page MenuHomePhabricator

should we make privatewiki list available to puppet without maintaining two lists?
Open, MediumPublic

Description

Sanitarium needs access to the list of private wikis so it can refuse to pass them on. The straightforward way is ot maintain a copy of private.dblist in a puppet manifest, i.e. https://gerrit.wikimedia.org/r/#/c/324201/

Can/should we do this without maintaining two copies of the list?

Event Timeline

Well, I think the right place is mediawiki-config, we just need to find a way to sync it properly to puppet. Sync to puppetmaster?

I've added Chad as a sometime maintainer of these lists on the MW side (please remove self/add other as appropriate).

Initial attempt was here: https://gerrit.wikimedia.org/r/324482 but has issues, see comments on patchset.

Possible approaches I can think of:

  1. We could use a custom facter fact. This would be available on all nodes whether or not we defined it only in one module.
    • 'confine' only works with non-puppet facts i.e. kernel: linux etc, There's no other way to restrict it, leading to this fact having unpredictable contents elsewhere
    • We could instead grab the mw list from a repo and put in a particular place, /srv/sanitarium/something. clone? rsync? other? Is this sufficient, too complicated?
  1. We could put a copy of the file (again, rsync? git clone? other?) on the puppetmaster and use a custom function to read it.
    • This function would just read a specified file and return the contents as members of a list. There is already load_yaml (name may not be exact) which reads a yaml file and returns variables.
  1. We could store the original list in puppet, and make it responsible for maintaining the file everywhere.
    • If we went this route, I'd want to have all the dblists in here and have puppet maintain the directory.
    • Puppet doesnt run across the cluster all at once; otoh neither does a sync, it can (or used to) take up to 40 minutes, Is that a problem?
  1. Last option: maintain two lists, one in puppet and one in mediawiki -- well, it's easy, and it's done.
  1. Something I forgot?

I am starting to like option #2 more because we could do more than just this, more things like "do not alert if X is depooled" until etcd is introduced, but I bet other ops won't like it.

As discussed on IRC another option could be to run an exec on Puppet code that generates a .cnf file with only that list and have all the existing options in the main my.cnf remain in the Puppet ERB template and just add a line to include the generated .cnf.
Ideally the exec should have a proper onlyif/unless to make it run only when the list changes.

Basically anything that isn't "duplicate" or "maintain in puppet exclusively" would work for me. Etcd, puppet magic, all sound fine.

Another option: move the dblists to a separate git repo (submodule of mw-config), then this repo would be available to anything needing them.

@demon, as much as I hate submodules, that might be a good idea anyways. I don't know if it makes a huge amount of difference whether we have the entire mw-config repo or just the dblists available on the hosts that need them.

Change 325765 had a related patch set uploaded (by ArielGlenn):
generate separate mysql config with list of private wikis

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

Change 325766 had a related patch set uploaded (by ArielGlenn):
for sanitarium hosts, include a separate mysql cnf with private wikis

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

Change 325765 abandoned by ArielGlenn:
generate separate mysql config with list of private wikis

Reason:
this never got any traction

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

Change 325766 abandoned by ArielGlenn:
for sanitarium hosts, include a separate mysql cnf with private wikis

Reason:
this never got any traction

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

s anyone able to comment weather this task is still valid and if anymore context is needed. further what is the best team to route this too if it is still valid. thanks