15:00:12 <raildo> #startmeeting oslo-config-plaintext-secrets
15:00:13 <openstack> Meeting started Tue Sep 25 15:00:12 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:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:18 <openstack> The meeting name has been set to 'oslo_config_plaintext_secrets'
15:00:22 <raildo> #link https://etherpad.openstack.org/p/oslo-config-plaintext-secrets
15:00:34 <moguimar> waaa
15:00:46 <moguimar> raildo was faster than me this time with the link xD
15:01:01 <raildo> :)
15:01:20 <redrobot> o/
15:02:58 <raildo> I think we can getting it started
15:03:07 <raildo> #topic PTG feedback
15:03:24 <raildo> bnemec, dhellmann how was the PTG for you guys?
15:03:46 <bnemec> Good. I think we had some useful discussions.
15:03:48 <raildo> any discussion/updates about this topic on Denver?
15:04:50 <bnemec> Yes, although I think it mostly consisted of "this is happening, next step is implementation of the castellan driver".
15:05:03 <bnemec> Oh, we did decide to continue deferring the issue of mutability too.
15:05:13 <bnemec> Basically we're going to ignore it until someone complains. :-)
15:05:43 <raildo> bnemec, yeah, that makes sense for now :) let's keep that in mind to add a note for that in the castellan driver docs later
15:05:44 <moguimar> sounds like a plan
15:06:52 <raildo> in the tripleO side, I was remotely in the meeting, tripleo folks liked the idea of having that as a driver for castellan, but they think that we still a bit raw with the implementation details
15:07:08 <raildo> and I kinda agree with that :)
15:07:39 <raildo> for example, we should avoid duplicating the secrets in other places (like heat or ansible) where it could end up unencrypted, even using the castellan driver
15:08:21 <raildo> to fix that one of the ideas was to bring up a temporary instance of Vault where we would store all the sensitive data, and eventually copy the encrypted database to the overcloud
15:09:28 <raildo> but it's something that we'll need to spend more time during this release, and start writing some PoC for TripleO, so we can understand more how it will works
15:10:30 <raildo> anything else on this topic?
15:10:49 <moguimar> sounds good to me
15:11:17 <raildo> #topic (moguimar) Castellan driver
15:11:47 <moguimar> the driver works
15:11:57 <moguimar> I'm trying to write some unit tests to it
15:12:27 <moguimar> to make sure it keeps working and to have a notion of code coverage
15:12:42 <bnemec> +1000
15:12:52 <moguimar> I'm confident with the vault part of castellan
15:13:08 <moguimar> still reading the barbican bits
15:13:20 <raildo> so... one of the ideas that we had was to write a gate job with some functional tests for it. how feasible it will be to write some functional tests for it?
15:14:00 <moguimar> idk, haven't write any functional tests at all so far
15:14:09 <moguimar> so I can't estimate
15:14:17 <raildo> are we able to create a simple vault server using tempest stuff or having barbican running on tempest?
15:14:52 <moguimar> castellan has a vault functional test
15:15:33 <moguimar> and it uses pifpaf to run the vault server
15:16:01 <raildo> I would love to have an idea on how we can test this driver over tempest before merge it, since we can set some next steps for a gate job for castellan during this release
15:16:03 <redrobot> so Castellan doesn't have any functional gates at the moment
15:16:23 <redrobot> the Barbican team agreed to set one up during the PTG
15:16:28 <raildo> redrobot, is there any specific reason?
15:16:30 <raildo> ah, great
15:16:31 <redrobot> so I'll be helping make that happen
15:16:48 <redrobot> I think for sure we'll want a Vault gate
15:17:04 <redrobot> and probably a Barbican gate as well
15:17:08 <redrobot> for Castellan->Barbican
15:17:17 <moguimar> I'm also planning on adding a new param for a prefix in the secret id
15:17:42 <moguimar> will I need a spec for that?
15:17:52 <raildo> redrobot, yeah, that will bring more confidence to justify the driver work when we start working in the tripleo side of this feature
15:17:59 <moguimar> right now, the secret_id is generated by uuid
15:18:14 <redrobot> moguimar, seems like the kind of change that would be good to flesh out on a spec
15:18:38 <moguimar> I just need some more reading on the barbican bits of castellan
15:18:45 <moguimar> it is feasible on vault
15:18:45 <raildo> moguimar, yeah, that's like the pattern across generation of ids across the openstack services
15:18:53 <moguimar> if it is feasible as well in barbican I will write it
15:19:42 <raildo> what reason this prefix will be needed for?
15:19:42 <moguimar> so the key_manager.store() returns the secret_id
15:20:08 <moguimar> and the idiea is to have key_manager.store(prefix="node_xyz_")
15:20:30 <moguimar> to get a secret_id like "node_xyz_891273123"
15:21:26 <raildo> so... shouldn't we create a resource node over secret and collect that date over there? usually I'm against to have any kind of useful data over the ids
15:21:48 <raildo> that why we use uuid, so it'll be a totally random number
15:22:30 <moguimar> the prefix could also be the node id
15:22:47 <raildo> but, let's write some spec about it, and we can keep the discussion over there :) sounds like something useful
15:23:37 <moguimar> it would reduce the policy files size having a single policy for all secrets from one node
15:23:54 <moguimar> instead of a policy for each secret of that node
15:24:29 <moguimar> that's all on my end
15:24:55 <moguimar> for this topic
15:25:14 <raildo> #action moguimar will write up a spec about adding a new param for a prefix in the secret id for castellan
15:25:38 <raildo> #topic Getting back to our weekly meeting or should we keep as a bi-weekly meeting?
15:25:41 <moguimar> if feasible in the barbican side as well
15:25:45 <moguimar> +1 weekly
15:25:54 <raildo> the topic already say everything
15:27:21 <raildo> any other thoughts?
15:28:03 <raildo> I'd rather the weekly meetings as well, just trying to have the everyone's opinion on it :)
15:28:20 <moguimar> redrobot bnemec dhellmann
15:28:37 <moguimar> +1 weekly or +1 biweekly
15:28:54 <bnemec> I don't have a strong preference. If you think it would be helpful to meet every week that's fine with me.
15:30:01 <raildo> let's come back to the weekly meetings, if we notice that we don't have enough topics to be discussing in 30 min, we can push it for bi-weekly again
15:30:01 <redrobot> Weekly seems like a good cadence to stay on the same page. 🤷
15:30:12 <moguimar> same feelings redrobot
15:30:31 <moguimar> or we can just skip one week
15:30:39 <moguimar> we've done that once
15:31:07 <raildo> also, I already updated our meeting's invite to be weekly, so you guys should receive the notification every week :)
15:31:09 <moguimar> then if we keep skipping, we talk about going biweekly again
15:31:32 <raildo> #topic Open Discussion
15:31:38 <moguimar> none on my end
15:31:40 <raildo> anything else?
15:32:36 <raildo> ok, so thank you all for you time, have an amazing week everyone!
15:32:39 <raildo> #endmeeting