[10:11:07] I know it's the last working day of the year, and a Friday, but: any of our puppet experts around for a consult? [no worries if not, but it seemed worth asking :) ] [10:11:20] what do you need? :P [10:15:20] I've rejigged how swift credentials are done (because I want to deploy credentials for rclone properly, rather than by hand as we do with swiftrepl), which is a bunch of moving things around, and I'd like someone to check it looks plausible (or not!) [10:15:47] [and because it involves changes to 3 different repos] [10:16:32] https://gerrit.wikimedia.org/r/c/operations/puppet/+/868721 and https://gerrit.wikimedia.org/r/c/labs/private/+/868718 move the credentials into common heira rather than per-site (and private-puppet needs a similar edit), https://gerrit.wikimedia.org/r/c/operations/puppet/+/870555 actually uses the new credentials [10:16:45] [no, I'm not deploying any of this today, fear not :) ] [10:36:50] Emperor: the change to labs/private looks somewhat problematic to me. First, you change the name of the hiera key but the actual key name (what's passed to lookup() isn't being changed). and second, only values with keys of swift:: would be looked up from hieradata/common/swift.yaml, so that one isn't going to work [10:37:50] iirc there was some work recently to make PCC support including a labs/private patch when compiling the catalogs, not sure if that's already released. would be useful here if it was [10:46:29] taavi: we already use lookup('profile::swift::replication_keys') which does pick up replication_keys: from hieradata/common/swift.yaml ; so maybe I'm not understanding what you're saying? [10:47:58] (and I do split up global_accounts_keys by site before passing that to the older templating code) [10:51:39] Emperor: no, lookup('profile::swift::replication_keys') is going to look up a key named 'profile::swift::replication_keys' and nothing else [10:58:44] taavi: OK, so why does labs/private hieradata/common/swift.yaml have just replication_keys in? [10:59:05] I see actually-private puppet has profile::swift::replication_keys: in the equivalent file [11:00:08] [FTR, happy to change to profile::swift::accounts_keys: in the labs/private change, just confused] [11:05:03] ...and if just plain replication_keys is wrong in labs/private, how has this not exploded in the past? :) [11:15:30] Emperor: that's a good question. looks like labs/private sets the correct key in two(!) files, hieradata/common/profile/swift.yaml and hieradata/labs.yaml. So hieradata/common/swift.yaml just isn't being read. [11:20:34] taavi: So I should a) delete labs/private hieradata/common/swift.yaml b) move my accounts_keys structure currently there into labs/private hieradata/common/profile/swift.yaml instead and declare it as profile::swift::accounts_keys there ? [11:21:56] (since I think labs/private hieradata/common/swift.yaml only contains replication_keys and account_keys [not accounts_keys] none of those are going to be picked up usefully? ) [11:41:13] Emperor: yeah, that sounds good. [11:41:31] looks like https://integration.wikimedia.org/ci/job/operations-puppet-catalog-compiler/build?delay=0sec supports running PCC with a labs/private change. that sounds helpful for this case! [11:46:36] Ah, cool, thanks, I'll have a go with that when I've done that rejigging [11:49:16] taavi: thanks for all that, very helpful :)