| *** TuanLA has joined #openstack-chef | 01:54 | |
| shoffmann | Hi, | 09:17 |
|---|---|---|
| shoffmann | I would like to see a feature at the openstack-identity cookbook. Is this the right channel to discuss about it? | 09:17 |
| shoffmann | At the recipe _fernet_token the keystone vault name is hard coded. I think it is better to make it variable like other vaults. | 09:34 |
| frickler | shoffmann: welcome, you have come to the right location indeed, though it is usually very quiet here | 09:37 |
| frickler | shoffmann: I also did see your bug report, but for me it is a difficult decision between flexibility and complexity, so I've been hoping others would take it up and give you feedback. best wait until about 14 utc when people in the US tend to wake up | 09:40 |
| shoffmann | Thanks. | 09:40 |
| *** s-mutin has quit IRC | 09:46 | |
| *** TuanLA has quit IRC | 12:09 | |
| sc` | indeed it is usually very quiet here | 13:04 |
| sc` | <- one of the US folks woke up | 13:05 |
| sc` | i see the point in abstracting such things out to a node attribute. we pull secrets in different recipes, and not everyone names their databases the same | 13:11 |
| sc` | s/databases/databags/ | 13:11 |
| sc` | E_NOCAFFEINE | 13:11 |
| sc` | i don't fully grok the scope at this time of morning, but it's suggesting to me that this would touch multiple cookbooks/recipes | 13:13 |
| sc` | such changes usually need a blueprint with slightly more context | 13:13 |
| sc` | frickler: looking at the murano changes from way back. i think the common change needs more work before it can be reviewed/merged. it touches client.rb which undergoes a massive simplification in pike | 13:16 |
| sc` | haven't tested it, but the cookbook looks good | 13:19 |
| sc` | i wanted to put more recent eyes on it before i completely forgot about that one | 13:19 |
| sc` | shoffmann: before i get too ahead of myself, hi and welcome. i'm the one who responded to your bugs | 13:20 |
| shoffmann | If we change only the string at _fernet_token.rb this would be the only change. But the secret function puts an vault_ befor the 'keyston'. | 14:04 |
| shoffmann | If we touch the secret function at openstack-common, this will touch multiple cookbooks. | 14:04 |
| sc` | indeed. touching common can have far-reaching consequences | 14:07 |
| sc` | for a bit of history, we went through a little of this some months ago, where another contributor proposed adding hooks for db migration. it received some feedback from the core team but ultimately stalled. if you're willing to drive the change, we can provide feedback based on our experiences on the coal face | 14:10 |
| sc` | our focus has been on the stabilization of pike, to try and get a release out sooner than later | 14:11 |
| shoffmann | I think it is enough to replace the 'keystone' string with an attribute. This looks like the way passwords are used for example at server-apache.rb | 14:54 |
| sc` | are you familiar with the openstack review process? | 14:55 |
| shoffmann | No. | 14:55 |
| sc` | you already have the login portion set up. https://docs.openstack.org/infra/manual/developers.html details how to get the rest of the way, including gerrit | 14:56 |
| shoffmann | Thank you | 14:57 |
| sc` | technically, it's my day off, but it's early and i'm awake as it is :) | 14:57 |
| sc` | i'll probably submerge once you're all offline for the evening | 14:57 |
| *** lbragstad has joined #openstack-chef | 20:51 | |
| lbragstad | hello folks! i'm working on status updates for one of the queens community goals https://governance.openstack.org/tc/goals/queens/policy-in-code.html | 20:51 |
| lbragstad | i'm double checking here, but openstack chef being a deployment project should be affected by that, should they? | 20:52 |
| lbragstad | if that the case, I be sure to propose a patch to governance that marks openstack chef as not applicable | 20:52 |
| lbragstad | if that's the case, I'll be sure * | 20:53 |
| sc` | lbragstad: ohai. we consume what packagers produce. for the most part, our docs already live in the repos, in whatever level of freshness exists | 23:09 |
| sc` | if the ask is to simplify the gnarly configs and push them to etcd, that's a tall order, as nobody on the core team really has that level of exposure with it | 23:10 |
| lbragstad | sc`: thanks for the info | 23:12 |
| lbragstad | sc`: to clarify a bit more, openstack chef doesn't expose any apis that are protected by openstack's policy.json pattern does it? | 23:12 |
| lbragstad | the community goal i referenced is specific to simplifying that pattern | 23:12 |
| sc` | to my knowledge, we don't directly manage policy.json, though i'm searching my exobrain | 23:13 |
| lbragstad | ok | 23:13 |
| lbragstad | the goal is specific to projects that have apis that are exposed to end users and managed via policy.json files | 23:15 |
| lbragstad | if that's not the case, then chances are you're exempt from the goal | 23:16 |
| lbragstad | but it might make consuming or managing policy easier for your project | 23:16 |
| sc` | looks like we manage policy.json in two places: cinder and neutron | 23:19 |
| sc` | i misspoke. we don't directly manage the contents | 23:21 |
| sc` | the resources called are for dropping a remote file, unmodified | 23:21 |
| sc` | by default, for neutron, that attribute is nil, so nothing happens | 23:21 |
| sc` | same for cinder, looks like | 23:22 |
| sc` | so i rephrase: we have the option to do so, but do nothing | 23:22 |
| sc` | if anything, simplifying managing policy.json is a code pruning session for us | 23:23 |
| sc` | we can just rip out the remote_file resources if they will no longer be needed | 23:24 |
| sc` | that may be the only action item, if there is any, to reduce tech debt ever so slightly | 23:25 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!