[10:24:49] FYI I'm about to upgrade spicerack on cumin2001 and double check everything works fine. If you're planning to run delicate operations just in case use cumin1001 for the next ~30/60 minutes [10:26:27] I check anyway that there are no running cookbooks before starting [11:00:41] https://github.com/harporoeder/ebpfsnitch looks intresting but read the disclaimer [11:01:01] upgrade completed, both cumin hosts are on the latest spicerack version [12:34:48] hnowlan: hey [12:35:06] I just merged this patch: `Hugh Nowlan: passwords::cassandra: add aqs password entry (19582b3)` that was sitting puppet-merge [12:35:27] let me know if that's OK, or I will revert it [12:35:39] (sorry, overlook and typed yes) [12:36:28] arturo: thanks! should be fine [12:36:46] hnowlan: excellent, cheers, sorry for the noise [14:53:38] when does puppet evaluate variables that are stored in hieradata? in this change classes are seeing the `profile::aqs::cassandra_password` value as populated but `application_password` as empty and it's kinda stumping me https://gerrit.wikimedia.org/r/c/operations/puppet/+/672366/8/hieradata/role/common/aqs.yaml [14:57:43] This is slightly complicated by the fact the classes that use these variables previously came from a role that had a now-discouraged `require ::passwords::aqs` in it which I assume prevented potential scoping issues [15:00:04] hnowlan: i wonder if the issue is ::profile::cassandra is now before ::profile::aqs [15:02:42] hnowlan: the password lookup in profile::cassandra happens in the args, which is before `include ::passwords::cassandra` happens [15:02:46] that looks dubious [15:05:11] and previously this worked because the cassandra hieradata depended on passwords:aqs, which was loaded first by the role [15:05:17] agh, that seems likely. so the templating of the vars is done on use [15:06:50] hnowlan: i would probably move the `include ::profile::cassandra` into profile::aqs [15:07:08] that way profile::aqs can set up the prereqs [15:10:44] hnowlan: this is an itesting pattern i had not seen hiere using iterporlation to map to global values from the passwords file. I would be tempted to just move those values under hiera in the private repo and not use the passwords module. [15:11:35] i suspect kormat is right in that the problem is triggered as the include happens after the parameter look up which is likley why the require passwords was explicitly done in the role previously to ensure that the where indeed loaded before the profile is called [15:14:43] hnowlan: commented on the CR [15:15:25] kormat, jbond42: thanks! [15:15:44] hnowlan: np :) [15:17:45] np [15:24:22] Hi SRE folks. Would someone mind giving https://gerrit.wikimedia.org/r/c/operations/puppet/+/670568 a +2 ? [15:27:10] * jbond42 looking dancy [15:27:16] Gracias [15:31:54] dancy: as that script runs as root i think we would need to have a more formal config file instead of allowin users to source anything. in the current form a user could source FOO=$(do_evil) and do_evil will be run as root [15:32:15] That script does not run as root. [15:32:22] at least, I've never run it as root. [15:32:52] oh your right end of the day ignore that comment :) and let me look again :) [15:35:05] Thanks! [15:35:53] dancy: merged and deploed to mwloag1001 [15:36:12] Confirmed. Much appreciated [15:36:34] np