14:59:47 <raildo> #startmeeting oslo-config-plaintext-secrets
14:59:48 <openstack> Meeting started Tue Apr 17 14:59:47 2018 UTC and is due to finish in 60 minutes.  The chair is raildo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:51 <openstack> The meeting name has been set to 'oslo_config_plaintext_secrets'
15:00:04 <raildo> #link https://etherpad.openstack.org/p/oslo-config-plaintext-secrets
15:00:15 <dhellmann> o/
15:00:53 <moguimar> o/
15:01:10 <raildo> just wait a few minutes to see if spilla will join us today
15:01:56 <gagehugo> o/
15:01:59 <raildo> ok, so let's start it
15:02:03 <spilla> o/
15:02:12 <raildo> #topic new member
15:02:37 <raildo> moguimar, it's part of my team here on Red Hat and he will start helping us to develop this feature
15:02:45 <raildo> welcome moguimar :)
15:02:51 <moguimar> hi guys o/
15:02:53 <gagehugo> hey moguimar o/
15:02:55 <spilla> hello and welcome maguimar!!
15:03:13 <dhellmann> hi, moguimar!
15:03:26 <raildo> #topic Status Check
15:04:26 <spilla> getting back to my spec after last weeks training, tanks raildo for updating per dhellmanns comments :)
15:04:53 <raildo> no problem
15:05:02 <dhellmann> those 2 patches with the base classes look good, and I think we're ready for the next step
15:05:29 <raildo> dhellmann, ++ I jsut rebased and applied dhellmann's comment on that
15:05:34 <dhellmann> looking at http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html#work-items I think we can actually change the order a bit
15:05:52 <dhellmann> some of this will be more clear if we skip ahead one step to "Define a new driver for loading configuration from simple URLs to be used as a test case"
15:05:56 <raildo> I didn't have time this last week to go to implement the next steps, but I hope to start and have moguimar's help on that soon :)
15:06:18 <dhellmann> we can then combine "Set up the namespace for entry points for drivers" with "Extend ConfigOpts to load and use the drivers, as described above. This will add URL handling without changing the way file loading works"
15:06:35 * dhellmann wishes those steps were numbered in the spec :-)
15:07:01 <raildo> dhellmann, so, let's update the etherpad, and we can track that better on it
15:07:06 <dhellmann> ++
15:08:09 <raildo> so, what are you saying is that after implement those classes defined in our current patches, we should go to the simple URL test case, right?
15:08:18 <raildo> if yes, sounds a good plan for me
15:08:36 <dhellmann> ok, I reordered the items in the etherpad
15:08:48 <dhellmann> so the new step 3 is the next thing to do
15:08:57 <raildo> ack
15:09:38 <dhellmann> we can keep it simple at this stage by just writing the driver with unit tests
15:09:54 <dhellmann> don't worry about how it will interact with ConfigOpts, until we get to the next stage
15:10:21 <raildo> dhellmann, ok, that makes our life easier at this point :)
15:10:38 <moguimar> will we have drivers for config-file and config-dir?
15:11:07 <dhellmann> moguimar : making those work as drivers is going to be pretty complicated, so I don't think we need to prioritize those
15:11:28 <dhellmann> we need to solve the bootstrapping issue when we convert those
15:11:43 <dhellmann> as in, how do we know where our config is if we don't have the drivers reading config data?
15:11:58 <dhellmann> so let's keep things simple by waiting to address that problem
15:12:10 <moguimar> I mean like this
15:12:12 <moguimar> [DEFAULT]
15:12:14 <moguimar> config_sources = otherconfig
15:12:16 <moguimar> [otherconfig]
15:12:18 <moguimar> driver = file
15:12:20 <moguimar> mapping_file = /path/to/mapping.ini
15:12:22 <dhellmann> oh, I see
15:12:29 <moguimar> would be very easy to test
15:12:48 <dhellmann> we already have an option we can put in a config file to point to other config files, so I'm not sure what benefit we get from doing that
15:13:48 <dhellmann> so it's possible to do it, but I'm not sure it helps us reach the goal of having the castellan driver
15:14:59 <moguimar> the goal here is to test if the ConfigurationSource and the base driver class are ok
15:15:07 <dhellmann> right, that's what the URL driver is for
15:15:42 <moguimar> like this?
15:15:44 <moguimar> [DEFAULT]
15:15:46 <moguimar> config_sources = otherconfig
15:15:48 <moguimar> [otherconfig]
15:15:50 <moguimar> driver = url
15:15:52 <moguimar> mapping_file = http://foo.bar/extra.conf
15:16:12 <dhellmann> yes, except the "mapping_file" parameter would probably be called something like "url"
15:16:19 <dhellmann> "mapping_file" is something castellan needs
15:16:56 <moguimar> yep, in my understanding, the only reserved name so far is the "driver"
15:17:11 <moguimar> the others are driver dependant
15:17:13 <dhellmann> that's right, that one is defined by the ConfigOpts class that is going to load the drivers
15:17:14 <dhellmann> exactly
15:17:56 <dhellmann> the driver class will register those options when open_source_from_opt_group() is called
15:19:30 <raildo> moguimar, I believe that what dhellmann is trying to say is that, for now, we'll be pointing to and URL since we don't have a proper driver implementation yet, just for test purpose
15:19:58 <dhellmann> sort of. I'm suggesting that it should be straightforward to write a driver that reads data from a URL to use as an example.
15:20:04 <raildo> so, we kind of supposing that URL someday will be a proper castellan_reference, that we can add some real tests for this scenario when we have that done
15:20:20 <dhellmann> we could have done files, but that might end up touching more of the file reading code, and I want to leave that alone as long as possible
15:20:34 <dhellmann> and doing URLs gives us another small feature that people have asked for :-)
15:20:56 <dhellmann> this driver would probably use requests to fetch the data and then parse it as an INI file
15:21:07 <raildo> dhellmann, got it, sounds reasonable :)
15:21:13 <dhellmann> that would at least let someone set up a container to pull config from somewhere else
15:21:33 <dhellmann> it's a little hacky, since you probably don't want to do it that way, but it's a very simple driver so it's good as a first case
15:21:35 <moguimar> but it sounds more like an ini-file driver
15:21:47 <dhellmann> yes
15:21:55 <moguimar> where you could have "path" or "url"
15:21:59 <dhellmann> I'm trying to work through this implementation with you in very small steps.
15:22:06 <moguimar> and have flexible locations for the file to exist
15:22:17 <dhellmann> we can do all of that, yes
15:22:43 <dhellmann> but until you're familiar with the currently complex file loading stuff, I don't want to change it, because *everything* would break if that breaks.
15:23:06 <dhellmann> so a small driver that does something different but reuses just the INI parser seems like a good compromise
15:23:17 <dhellmann> let's walk before we try to run
15:23:57 <dhellmann> where "run" means "have a castellan driver" :-)
15:23:59 <moguimar> I wasn't thinking to use more than the INI parser
15:25:34 <dhellmann> ok, I guess I'm not sure I understand why that's more appealing than the plan we already have that moves us towards the real goal.
15:26:47 <moguimar> writing a simple driver that uses the INI parser can get us some testable driver
15:27:00 <dhellmann> that is exactly what the plan calls for us to do.
15:27:47 <dhellmann> but it does that in a way that does not add a second way to read files and gives us a tiny feature that someone has asked for
15:28:06 <moguimar> got it
15:28:54 <raildo> I believe that the topics are more clear now :)
15:28:58 <raildo> we only have 2 minutes to end the meeting,
15:29:07 <raildo> #topic open discussion
15:29:12 <raildo> anything else?
15:29:38 <dhellmann> nothing from me
15:29:52 <spilla> nothing from me
15:30:09 <moguimar> nothing from me
15:30:11 <raildo> so, thank you guys, have a good week!
15:30:16 <raildo> #endmeeting