12:05:40 <dave-mccowan> #startmeeting barbican
12:05:41 <openstack> Meeting started Tue Jul 17 12:05:40 2018 UTC and is due to finish in 60 minutes.  The chair is dave-mccowan. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:05:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:05:44 <openstack> The meeting name has been set to 'barbican'
12:05:50 <dave-mccowan> #topic roll call
12:05:53 <dave-mccowan> o/
12:05:57 <Luzi> o/
12:06:05 <mhen> o/
12:06:57 <redrobot> o/
12:07:22 <dave-mccowan> is there an agenda posted?
12:08:18 <dave-mccowan> i don't see one on the agenda page.
12:08:27 <dave-mccowan> #topic milestone 3
12:08:55 <dave-mccowan> this week is the deadline for milestone 3 for the release
12:09:15 <dave-mccowan> does anyone have status to discuss for development line item?
12:09:47 <dave-mccowan> we should be feature-complete after this deadline, and move on to testing and bug fixing for the rest of the cycle.
12:11:08 <dave-mccowan> hi namnh
12:11:47 <dave-mccowan> ok, in that case, please help out with patch reviews for the next couple of days so we can get as much as possible in for m3.
12:12:00 <namnh> alee_: :)) Hi Ade, long time no chat :)
12:12:18 <dave-mccowan> #topic barbican client
12:12:48 <dave-mccowan> m3 is also usually the release date for client libraries.  has anyone been working with the client lately?  is it good for release?
12:13:16 <redrobot> namnh, I don't think alee_ is here... probably just a bouncer.
12:13:37 <redrobot> pretty sure the client needs some TLC
12:13:48 <redrobot> not sure if anyone has picked up the UUID issue
12:13:53 <namnh> dave-mccowan: hi dave, maybe I sent wrong address ;)
12:13:55 <redrobot> but it would be awesome if we could get it done before m3
12:14:55 <dave-mccowan> redrobot yep.  people keep asking about it, but i don't think anyone is working on it.
12:15:46 <dave-mccowan> i finally got --file parameter submitted.  but, there's still a couple other things that have been hanging around for a very long time.
12:16:20 <redrobot> I'll try to get a lot of reviewing done this week
12:16:29 <dave-mccowan> redrobot thanks!
12:16:54 <namnh> redrobot: thanks !
12:17:20 <dave-mccowan> both testing and reviewing would be great from anyone who can spend some time early this week.  (especially for barbican client)
12:17:44 <dave-mccowan> #topic validation
12:18:25 <dave-mccowan> Luzi:  last week you and Ade talked about bit length validation.  do you have an update or any further questions?
12:18:49 <Luzi> no, he wanted to discuss this with more people
12:19:08 <redrobot> #link https://review.openstack.org/#/c/575800/
12:19:22 <redrobot> Luzi, I think this is the place to discuss :D
12:19:50 <dave-mccowan> redrobot excellent!
12:19:54 <dave-mccowan> #topic OVO
12:20:08 <dave-mccowan> namnh How's OVO going?
12:20:35 <namnh> yeah, I am writing unittests for OVO
12:20:39 <redrobot> I think we still need lots o' reviews too
12:20:58 <namnh> there are some patch sets which I pushed
12:21:24 <namnh> but, for now, I am an idea about this task
12:22:08 <namnh> because, the final target is that Barbican can rolling upgrade.
12:22:55 <namnh> after I review all barbican database, RPC -> there is no change in the recent cycle.
12:24:03 <namnh> and I tried to rolling upgrade with barbican, and the result is good. So I am thinking that we can create a docs to guide operators to rolling upgrade
12:24:52 <namnh> after that we can also push a patch set to get "rolling upgrade" tag from TC.
12:25:42 <namnh> then we still continue to  implement  OVO as Neutron is doing
12:25:52 <namnh> what do you think?
12:26:29 <namnh> dave-mccowan and redrobot
12:26:32 <namnh> :)
12:26:35 <redrobot> Hmm... I thought OVO was required for rolling upgrades?  Would be aewsome if it's not
12:26:59 <dave-mccowan> i see... since there is no database change in Queens to Rocky, then we can roll without OVO for that upgrade.
12:28:29 <dave-mccowan> that seems like it is cheating.  without OVO, we can't promise that R to S upgrade will be rolling.  i don't think we should request the tag until OVO is working.
12:28:32 <namnh> redrobot: OVO is a method for rolling upgrade, but it is not required. It depends on the architecture of each project.
12:29:19 <namnh> dave-mccowan: yeah, I know, as I mentioned, we still implement OVO after creating docs for rolling-upgrade
12:30:51 <namnh> dave-mccowan: because OVO take time for us. Although, Barbican for now can be upgraded without downtime.
12:32:05 <namnh> and I believe that Barbican can rolling upgrade from Pike
12:32:42 <dave-mccowan> we can wait for Ade to return to discuss more.  but, i'm not totally comfortable claiming support without OVO, since we don't know release S will contain.
12:33:57 <namnh> dave-mccowan: Yeah, I understood, that is just my idea to discuss :)
12:34:48 <dave-mccowan> namnh Thanks for suggesting it.  Maybe we can document it for operators with a warning?  We should make it a goal to merge OVO before we merge a patch that changes the database.
12:35:10 <dave-mccowan> #topic Anything else?
12:35:35 <Luzi> yeah
12:36:10 <Luzi> well, I would at least like to hear, what you all think about https://review.openstack.org/#/c/577096/
12:36:12 <namnh> dave-mccowan: btw, can you review the OVO patch set that got +2 from Ade
12:36:41 <dave-mccowan> namnh yes, i'll do that today.
12:36:53 <namnh> dave-mccowan: thanks :)
12:37:07 <Luzi> should there be still a validation for bit-lengths, which would need to allow 512 bits for aes-xts
12:37:35 <Luzi> or should barbican be able to generate keys of any bit length?
12:40:43 <dave-mccowan> simple sounds good to me.  seems like we'll always be chasing the future if we try to maintain a list of supported bit lengths for each new thing.
12:40:59 <dave-mccowan> anyone else?  redrobot namnh?
12:41:23 <namnh> dave-mccowan: that's all from me.
12:41:33 <namnh> :)
12:41:50 <redrobot> I may be the only dissenting opinion about bit lengths.  I'm on the explicitly supported in some crypto algorithm camp.
12:42:17 <dave-mccowan> redrobot cool.  let's discuss in the review:  https://review.openstack.org/#/c/577096/
12:42:18 <Luzi> redrobot, that's something i also consider.
12:42:50 <redrobot> I've been deep diving into Vault.  I think the Vault plugin for both Barbican and Castellan will need some improvements.
12:43:01 <redrobot> right now they depend on a ROOT TOKEN to work
12:43:14 <redrobot> but no one in their right mind should be using root tokens that way
12:43:26 <redrobot> Vault docs say: "the Vault team recommends that root tokens are only used for just enough initial setup (usually, setting up auth methods and policies necessary to allow administrators to acquire more limited tokens) or in emergencies, and are revoked immediately after they are no longer needed."
12:43:55 <redrobot> so, I'm digging into Vault Policy and hope to come up with a better scheme for using non-root tokens
12:44:39 <dave-mccowan> redrobot thanks!
12:45:11 <redrobot> That's all I got...
12:45:50 <dave-mccowan> Thanks everyone!  See ya later...
12:46:29 <dave-mccowan> #endmeeting