[11:02:18] jbond42, _joe_: i have a puppet approach question. https://phabricator.wikimedia.org/P13085 - i currently have a class with the top definition. i now realise that i need to pass in a backend-type var (`db_backend`), which makes all the previous `db_backend_.*` variables optional. is there a clean way of doing this? should i be restructuring the class completely? [11:02:41] https://github.com/wikimedia/puppet/blob/production/modules/orchestrator/manifests/server.pp is the current class in full [11:03:29] <_joe_> kormat: what parameters would change? [11:03:52] if `db_backend` == `sqlite`, none of the db_backend_.* vars matter any more [11:03:59] <_joe_> kormat: my approach usually is to use a data source name [11:04:11] <_joe_> https://en.wikipedia.org/wiki/Data_source_name [11:04:14] <_joe_> and parse it in the code [11:04:45] <_joe_> so db_backend => 'mysql://usr:pwd@host:port/dbname [11:04:49] I was about to mention the same, some services use that if more confortable- e.g. java db connectors [11:04:53] ee. hmm. is there any issue with doing that when the password is in the var? [11:05:25] <_joe_> kormat: no, given this is a module class, not a profile [11:05:38] what's the significance there? [11:05:40] <_joe_> you will compose the dsn if the backend is mysql in the profile [11:05:52] <_joe_> where you can lookup the password in the private repo :) [11:06:00] oh, heh, ok. [11:06:10] <_joe_> even the full dsn :) [11:06:15] can you point me at some example code that parses a dsn? [11:06:28] <_joe_> in puppet? I don't think we have it [11:06:45] your "usual" approach, eh. [11:06:50] on the other side, having separate parameters I don't think would be that bad [11:06:55] <_joe_> well when I write code :P [11:07:32] e.g. I think mediawiki configuration juses different variables [11:08:01] <_joe_> kormat: another approach is to do class composition [11:08:11] <_joe_> you have a base class that takes a lot of different parameters [11:08:24] <_joe_> but based on db_backend calls other classes for the individual ones [11:09:12] <_joe_> but in your case I'd just declare all parameters besides db_backend optional [11:09:20] <_joe_> and check for validity in the code [11:09:36] <_joe_> if $db_backend == 'mysql' { ...} [11:09:39] _joe_: ok, so like the comment in my original paste? [11:09:48] (in terms of what the module parameters look like) [11:09:51] <_joe_> yes [11:09:56] I think the "right way" on normal code doesn't have always a better equivalent on puppet [11:10:19] e.g. object of class BackendConfig [11:10:37] our style requiring all optional params to come after mandatory params makes things a real mess sometimes [11:12:05] <_joe_> kormat: it's part of the official puppet style guide too :P [11:12:20] <_joe_> kormat: and yes, guidelines rarely fit all use-cases [11:12:41] <_joe_> that's why i hate obsessive linting [11:12:52] _joe_: our style checker enforces it (which is how i came across it) [11:13:09] i think it comes from puppet-lint (which our rake tests use) [11:13:39] if you look at the current code, the backend + topology params are interspersed because of that style requirement [11:13:50] because each of them have some required and some optional params [11:14:31] anyway, i'll go make it all a lot less clear now :) thanks for the input _joe_/jbond42 [11:22:29] kormat: could be worse cant find it now but voxpupuli had a PR our (which got droped) to make all paramteres appear in lexicographic order [11:22:45] * kormat cringes [13:03:07] moritzm: is there a standard place to keep a `debian/` dir for our own packaging of an external package? [13:04:08] typically it all ends up under operations/debs/*, Gerrit has default ACLs for this namespace, so that anyone in cn=ops can +2 there [13:04:57] ok, cool. [13:07:01] mm. so we mirror the upstream package to operations/debs/X, and then make local packaging changes there? [13:08:51] there's multiple possible approaches, you can import the original sources or if you mostly want to experiment a bit to eventually submit debian/* upstream, you can also only commit the debian/ dir [13:11:56] mm. i don't get the impression that upstream is interested in this [13:31:58] jayme: massive 💜 for https://wikitech.wikimedia.org/wiki/Envoy#Building_envoy_for_WMF [13:32:08] this looks like a good blueprint for what i need to do for orchestrator [13:42:01] kormat: cool, but that's mostly r.zl's and h.nowlan's work [13:42:45] ah. so praise to you, and blame to them. got it! [13:43:48] exactly, yes :) [16:13:59] gonna be re-syncing eqiad's OSM data which will involve messing with replication and so on on maps*.eqiad.wmnet. Any weirdness there in the next while is related to me [16:14:45] thanks for the heads up [16:51:12] moritzm, can cfssl.sso.eqiad1.wikimedia.cloud be deleted? Looks like it depends on a puppet class that doesn't exist anymore. [16:51:26] hm, also idp [16:52:20] the cfssl one may be used by jbond42 [16:52:31] let me check the idp instance, it can probably be removed [16:54:29] andrewbogott: yes they can both go ill buyild them again from scratch when needed [16:54:41] thanks [21:05:35] resync of eqiad OSM data is still underway, taking a long time. Kartotherian performance is affected by the reduced number of servers processing but it's at an acceptable level