15:00:16 #startmeeting oslo-config-plaintext-secrets 15:00:17 Meeting started Tue Jun 19 15:00:16 2018 UTC and is due to finish in 60 minutes. The chair is raildo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:21 The meeting name has been set to 'oslo_config_plaintext_secrets' 15:00:27 #link https://etherpad.openstack.org/p/oslo-config-plaintext-secrets 15:00:50 o/ 15:01:04 o/ 15:02:07 courtesy ping for dhellmann, redrobot 15:02:14 o/ 15:02:32 o/ 15:02:32 hello everyone :) 15:02:48 #topic Code review 15:03:04 so we have this remaining patches for review 15:03:11 #link https://review.openstack.org/#/c/575107/ 15:03:17 #link https://review.openstack.org/#/c/474304/ 15:03:39 so any thoughts on that will be appreciated :) 15:04:09 I was on PTO since last friday, got back today =) 15:04:23 the first one it's about the sample generator emits an example group for Ini driver 15:04:40 and the second one it's the spec with the more generic details about this feature 15:04:56 moguimar, welcome back :) hope you have enjoyed your PTO 15:05:25 #topic Separate cache for external sources 15:05:44 raildo, you have some plans for this task, don't you? 15:05:52 separate cache 15:06:25 o/ 15:06:26 so, I tried to implement this separate cache, but I stopped in some questions during the implementation 15:06:28 Should be inside the INIConfigurationSource only caching values in the get method? Should be over cfg.py caching values when using the Ini driver? 15:07:25 I mean, it was not clear to me, if it should be just caching values for the ini driver, or if it will be dealing with multiple caches like to create, clear cache and so on 15:08:11 like, it needs to change the clear_cache function as well, to add this new cache: https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2434-L2444 15:08:19 if we implement that at cfg level, it will cover all future drivers 15:09:14 my concern it's to be over changing the cfg file with a change that will be removed later 15:09:27 we can also cover all sources implementing the cache in the base class 15:10:02 and then trying to fetch from the cache inside the get 15:10:18 so future drivers can adopt it or not 15:10:36 we wanted 1 central cache because we want the drive API to be very simple 15:10:52 when something calls the driver, the driver shouldn't have to decide whether to fetch data -- it should do that 15:11:35 we have a cache in the ConfigOpts class already, but because of mutable options we have to be careful what we put there 15:12:03 since we said we weren't going to support mutability in the drivers for now, we need to separate the values we cache that come from drivers so that when we reset the cache for file data we do not discard the driver data 15:12:35 dhellmann, so, since this will not be mutable at this point, we don't need to worry about be cleaning this new cache layer, just adding the new values from the external source on that 15:12:35 that way ConfigOpts will always return the first value given to it by a driver, and the option will act like it is immutable 15:12:59 otherwise when we flush the cache we might get a modified value from a driver, and then we have to keep track of the differences 15:13:06 that's right 15:13:20 that's the reason for making it separate, so it is *not* flushed when we flush the other cache 15:13:38 ok, I'll send a patch implementation this idea today 15:13:40 it's a little hacky, and it will go away when we support mutability in the drivers 15:13:49 so basically a second cache, fetching values from it before pooling the sources and setting values to it after successfully getting a value from a source 15:14:18 with a different clear behaviour 15:14:56 * gagehugo lurks 15:15:51 ok, move on 15:16:05 #topic start thinking on the castellan driver 15:16:40 I was talking with redrobot about the new driver, that we will be implementation, and would be nice writing any necessary detail that will be need for that 15:16:58 so we can start writing a POC for the castellan driver, based in what we have until now 15:17:28 I haven't had a look at castellan yet =( 15:18:01 so, if guys have in mind any details that will be necessary for implement that, just start adding topic in the etherpad, item 3 in the future work section 15:18:07 I didn't have a chance to look at the current spec. Have you had good review feedback there? 15:18:26 moguimar, I've been taking a deep dive into Castellan the last couple of weeks 15:18:44 dhellmann, kind of, we have discussed a few items, but I still have a feeling that we need more details on how to implement it 15:18:51 ok 15:18:57 I will put that on my list for later this week 15:19:52 dhellmann, from the TripleO perspective, looks like we still need define more details on how we gonna support that, like which backend we will be using on castellan, how we gonna do deploy/build this backend... 15:20:16 so, at this point, I think that it's more some specific for castellan than for the oslo.config side 15:20:35 but would be nice add all those details over there, if possible 15:21:23 raildo : ok, that will be a tripleo spec, not an oslo spec 15:22:06 it may make sense to work all of that out before starting the driver, so it is clear what sort of configuration options will be needed 15:22:31 dhellmann, yeah, sure but I'm trying to say is that I would like to have all the details related to the castellan driver done, so the tripleo folks can be free to start thinking about write this tripleo spec 15:22:48 ok. I'm suggesting that would be doing it backwards. :-) 15:22:55 dhellmann, agreed 15:23:03 Without knowing what tripleo needs, we don't know what features to put into the driver. 15:23:21 this is a case where we need to design "top down" instead of "bottom up" 15:24:18 dhellmann, we will have a meeting with the tripleo security squad tomorrow about this, would be awesome if you could join us, to share some of your thoughts on that 15:24:38 I can try. When and where is that meeting? 15:24:50 #tripleo 15:24:54 freenode 15:24:57 it's in the #tripleo at 13:00 UTC 15:25:24 ok 15:25:45 you're sure raildo 15:25:52 for me it is 14:00 15:25:53 or it's 12:00 UTC? I'll confirm and ping you 15:25:57 I'm at +2 15:26:01 it's 1200 UTC 15:26:42 * dhellmann mumbles about getting up early 15:26:48 ok, I should be able to do that :-) 15:26:51 dhellmann, sorry about that, it's 1200 UTC http://eavesdrop.openstack.org/meetings/tripleo_security_squad/2018/tripleo_security_squad.2018-06-13-12.01.log.html 15:27:05 no worries, I'm just being cranky today 15:27:22 anyway, dhellmann if you want, we can talk with the tripleo folks later on the day 15:27:29 don't need to be necessary during that meeting 15:27:39 nah, I'll try to join the meeting 15:27:51 dhellmann, great :) 15:28:00 #topic open discussion 15:28:13 ok, I need to rush here, gotta leave in a sec... I'm trying to get the financial approval for EuroPython from my manager, also I got an invitation to submit a talk to PyterPy in St Petersburg, 2-3 November 15:28:36 I'll talk to my manager tomorrow and submit the protecting plaintext secrets talk 15:28:43 for PiterPy 15:29:19 and I'm probably going to talk about it at Python Brasil in october as well 15:29:31 thats all I have for now 15:29:31 oh, nice 15:29:55 that would be awesome 15:30:03 g2g, I'll read any feedback tomorrow o/ 15:30:08 ttyl, moguimar 15:31:09 ok, so have a good week everyone, thanks for your time! 15:31:13 #endmeeting