15:00:37 <raildo> #startmeeting oslo-config-plaintext-secrets
15:00:38 <openstack> Meeting started Tue Jun 26 15:00:37 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:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:41 <openstack> The meeting name has been set to 'oslo_config_plaintext_secrets'
15:00:43 <moguimar> #link https://etherpad.openstack.org/p/oslo-config-plaintext-secrets
15:01:22 <raildo> o/
15:01:46 <raildo> courtesy ping for dhellmann, redrobot, bnemec
15:01:52 <redrobot> o/
15:01:54 <redrobot> \o
15:01:57 <redrobot> o/
15:02:00 <redrobot> \o/
15:02:24 <moguimar> redrobot: are you trying to dance axé?
15:02:26 <dhellmann> o/
15:02:36 <redrobot> haha, something like that moguimar
15:02:46 <spilla> o/
15:03:00 <raildo> hello everyone, I think we are good to start :)
15:03:11 <raildo> #topic Issues with the separate cache for external sources
15:03:51 <raildo> ok, so I'm trying to implement the new cache for the driver that point for external sources
15:04:13 <raildo> but I'm having problems to distinguish between a value from the external source or from the ini file at the get method over cfg
15:04:44 <raildo> https://github.com/openstack/oslo.config/blob/1319cfb476ddd3c00030f088d42f4b0045f33b0a/oslo_config/cfg.py#L2940-L2952
15:05:05 <raildo> looks like we will be able to get the map between source - value over https://review.openstack.org/#/c/554316/16/oslo_config/cfg.py (line 3079)
15:05:38 <raildo> I think that the LocationInfo would help with that but I didn't get luck with that, someone can help me on this task?
15:05:50 <dhellmann> it may be easier to manage that cache in a different place
15:06:27 <dhellmann> we know that the only place we ask sources for config values is in the new _do_get() around line 3078 : https://review.openstack.org/#/c/554316/16/oslo_config/cfg.py
15:06:39 <dhellmann> so we could add values to the new cache there
15:07:10 <dhellmann> oh, sorry, that's the same line you pointed to :-)
15:07:18 <dhellmann> why do you need the location info there?
15:07:26 <raildo> dhellmann, yeah, that what I was trying to do
15:07:56 <dhellmann> we know the values are coming from a source there because that's the loop where we ask the sources for values. so we don't need the location info details, right?
15:08:05 <raildo> dhellmann, so, it will be easy just add the values in that source over the new cache, but I guess that we still need to double check that over the get?
15:08:07 <dhellmann> then up in _get() we can check the separate cache
15:08:31 <dhellmann> yeah
15:09:23 <raildo> so, we can create the new cache over the _do_get() and just check if the value is over this cache in the get() method
15:09:38 <raildo> ok, I'll do that :)
15:09:56 <raildo> thanks dhellmann
15:10:25 <raildo> #topic documentation
15:10:30 <moguimar> I'm always asking myself again why are we having this cache stuff
15:10:41 <moguimar> We have a disclaimer in the docs
15:10:51 <moguimar> can we add some 'why'?
15:11:19 <raildo> moguimar, because we are not making this values that come from the external sources mutable
15:11:40 <raildo> so, we need to make sure that we are having the proper value, if someone try to change those values later
15:11:48 <moguimar> that is now a why, that is a what we are doing
15:12:06 <moguimar> I'll dig on the meeting logs
15:12:09 <dhellmann> we want to enforce the immutable disclaimer we have documented
15:12:24 <dhellmann> otherwise users may have surprising behavior, because immutable options behave mutably
15:13:22 <raildo> moguimar, is that more clear for you?
15:13:23 <moguimar> thanks dhellmann
15:13:28 <moguimar> yup
15:13:35 <raildo> great
15:14:01 <moguimar> I made some updates to the docs today
15:14:08 <raildo> so, about the documentation, it's just an update that moguimar sent a new patch set today (thanks Moises!)
15:14:18 <raildo> #link https://review.openstack.org/#/c/576947
15:16:32 <raildo> btw, for test this, you just need to run $tox -edocs and will generate the html page over the docs/build path
15:16:33 <moguimar> I added some sessions
15:17:00 <moguimar> the html is looking nice =D
15:17:28 <raildo> so, reviews are appreciated :)
15:17:44 <moguimar> But I get what dhellmann said, we need later to separate developer/user guides
15:18:29 <raildo> agreed
15:18:55 <raildo> #topic Open discussion
15:19:13 <raildo> that all that I have for today, anything else?
15:19:28 <moguimar> dhellmann: there is one comment of yours about the driver option
15:19:56 <dhellmann> yes
15:19:56 <moguimar> #link https://review.openstack.org/#/c/575107/5/oslo_config/sources/_uri.py
15:19:58 <moguimar> this one
15:20:24 <moguimar> the option is not registered by the driver class, it is just there for sample generation with the specific value
15:20:35 <dhellmann> ideally that option would match the one ConfigOpts actually uses
15:21:00 <moguimar> I'm using choices at ConfigOpts
15:21:06 <dhellmann> although I like having the sample_default set to show the name of the driver for the group
15:21:07 <moguimar> like you suggested
15:21:32 <dhellmann> ok, good
15:21:35 <moguimar> that's what I did, the sample_default points to the required value
15:21:38 <dhellmann> ++
15:22:16 <moguimar> should we move the driver name to a variable and reuse it?
15:23:03 <dhellmann> did you move the driver_opt to list_opts()?
15:23:11 <dhellmann> if so, there's already a variable with the name there
15:23:15 <dhellmann> in the loop
15:24:30 <raildo> enjoying the remaining minutes that we have here, redrobot do you have any updates about that we discuss in the tripleo meeting? like about HA vault, or choosing between the options for the vault backend?
15:25:56 <moguimar> to my calculations, we only have the cache to be done by raildo and reviews on all the other tasks
15:26:08 <moguimar> next week I'll be on PTO/holidays
15:26:10 <raildo> moguimar, ++
15:26:25 <moguimar> are we able to close Phase 0 this week?
15:26:33 <raildo> I hope so :)
15:26:44 <dhellmann> you all may be interested in this other spec from cdent: https://review.openstack.org/#/c/576860/
15:27:14 <raildo> dhellmann, thanks for pointing that, I'll review it today
15:27:28 <raildo> #action all review the spec: https://review.openstack.org/#/c/576860/
15:28:06 <raildo> anything else folks?
15:28:31 <moguimar> not on my end, I'm only waiting for reviews now
15:29:09 <moguimar> if you're able to push some cache stuff today, I can review/test it tomorrow raildo
15:29:18 <dhellmann> I will watch for the updated version of moguimar's patch and the cache work and try to review those today/tomorrow
15:29:34 <raildo> I have a few meetings today, but I hope to have some free time to finish that today
15:29:47 <raildo> in the worst case, I'll send a WIP patch
15:29:59 <redrobot> o/
15:30:04 <redrobot> sorry yeah,
15:30:08 <raildo> redrobot, hey :)
15:30:13 <moguimar> dhellmann: fastest way to do it I think is get the latest version and try the sample generator and also see the HTML docks
15:30:15 <redrobot> not sure what we want to talk about in this meeting vs tripleo
15:30:26 <redrobot> Vault open source does have HA options
15:30:30 <dhellmann> moguimar : sure
15:30:31 <raildo> redrobot, basically the same thing :)
15:30:37 <redrobot> but they require an ha-enabled backend
15:31:20 <redrobot> HA == A single master + X hot-standby nodes
15:31:30 <raildo> redrobot, so, doesn't make sense to go for mysql, as ozz have suggested?
15:32:05 <redrobot> well, we could use mysql for storage
15:32:15 <redrobot> so you can actually define a separate storage backend from the ha-backend
15:32:18 <moguimar> vault doesn't handles storage
15:32:38 <redrobot> but we'd still need etcd to be the ha-backend
15:32:42 <raildo> got it
15:33:01 <moguimar> vault is kinda in the midle to encrypt/decrypt stuff
15:33:18 <redrobot> I took some notes:
15:33:19 <moguimar> cpu and network io only probably
15:33:21 <redrobot> #link https://etherpad.openstack.org/p/production-vault
15:33:47 <raildo> thanks redrobot, so we can dig into this notes and talk about that next week
15:34:10 <redrobot> moguimar, yup... with the option to have hot standby nodes.
15:34:27 <moguimar> exactly
15:34:28 <raildo> I don't want to take more time for all of you guys :)
15:34:40 <moguimar> I'm cool, you can end it
15:35:08 <raildo> so, have a good week everyone!
15:35:12 <moguimar> o/
15:35:14 <raildo> #endmeeting