20:00:00 <redrobot> #startmeeting barbican
20:00:01 <openstack> Meeting started Mon Apr 27 20:00:00 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:05 <openstack> The meeting name has been set to 'barbican'
20:00:14 <redrobot> #topic Roll Call
20:00:23 <dave-mccowan> o/
20:00:25 <x3k> o/
20:00:26 <kfarr> o/
20:00:32 <rellerreller> woot woot I finally get to make a meeting!
20:00:41 <redrobot> rellerreller \o/
20:00:59 <woodster_> o/
20:01:04 <arunkant> o/
20:01:05 <pkazmir> o/
20:01:12 <pkazmir> My first time :)
20:01:37 <rellerreller> redrobot I'm arranging things, so I can attend at least the first 30 minutes of the meetings.
20:01:38 <redrobot> welcome pkazmir
20:01:50 <alee> o/
20:01:52 <jvrbanac> o/
20:02:00 <redrobot> rellerreller good to know, so I can schedule topics relevant to you at the beginning
20:02:08 <redrobot> lots of barbicaneers here today!
20:02:17 <redrobot> as usual the agenda can be found here:
20:02:22 <hockeynut> o/
20:02:25 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:02:25 <chellygel> o/
20:02:39 <redrobot> #topic Action Items
20:03:14 <redrobot> So I've been really busy with Kilo release stuff, and I didn't get a chance to work on the action items from last week
20:03:23 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-04-20-20.00.html
20:03:30 <redrobot> #action redrobot to talk to Greg Swift about DB being used in Fedora
20:03:32 <tkelsey> o/
20:03:38 <redrobot> #action redrobot to clean up the barbican-specs repo
20:03:39 <tkelsey> sorry im late
20:03:53 <redrobot> tkelsey no worries, you didn't miss much
20:04:08 <redrobot> and since there's no agenda today, I'm just going to wing it. :)
20:04:12 <redrobot> #topic Kilo RC-2
20:04:16 <tkelsey> :)
20:04:22 <redrobot> #link https://launchpad.net/barbican/+milestone/kilo-rc2
20:04:38 <redrobot> Thierry should be releasing the Kilo Release Candidate #2 today.
20:04:59 <redrobot> it includes 4 bugfixes, as listed on the link above
20:05:39 <redrobot> I think we've done a pretty good job of pointing out bugs that need to be backported to kilo
20:05:59 <redrobot> many thanks to dave-mccowan and arunkant for the extra testing that found these bugs.
20:06:28 <rellerreller> redrobot When is the official cutoff date for submitting code for Kilo final RC?
20:06:51 <redrobot> rellerreller good question
20:06:58 <redrobot> according to the Kilo release schedule
20:06:59 <redrobot> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
20:07:01 <igueths> o/
20:07:06 <redrobot> we should have a final release on the 30th
20:07:11 <redrobot> which is this Thursday
20:07:51 <rellerreller> redrobot I have been running KMIP tests. I have found one bug. It's an easy one line fix.
20:08:09 <dave-mccowan> redrobot have you decided on https://review.openstack.org/#/c/177454/ as a kilo candidate?
20:08:41 <redrobot> rellerreller https://bugs.launchpad.net/barbican/+bug/1449234 ?
20:08:41 <openstack> Launchpad bug 1449234 in Barbican "KMIP secret store cannot store keys" [Undecided,New] - Assigned to Nathan Reller (rellerreller)
20:08:55 <redrobot> dave-mccowan I'll include it if we need to cut a Kilo-3
20:09:04 <rellerreller> redrobot That is it.
20:09:11 <redrobot> dave-mccowan which seems likely to include rellerreller's bugfix
20:09:19 <redrobot> rellerreller I'll mark it as also affecting Kilo
20:09:52 <rellerreller> redrobot What branch contains the kilo code?
20:10:05 <rellerreller> I know the answer is probably obvious but want to make sure I test on the right branch.
20:10:12 <redrobot> rellerreller it'll be the "stable/kilo" branch
20:10:33 <redrobot> rellerreller you just need to fix it in master, and I'll take care of cherry-picking it into the kilo branch
20:10:52 <rellerreller> redrobot Excellent!
20:11:42 <redrobot> any other questions/concerns/comments regarding the Kilo release?
20:13:13 <alee> redrobot, so is this the last build then?
20:13:29 <redrobot> alee looks like we'll have an RC-3 to fix the KMIP issue.
20:13:46 <redrobot> alee after that, RC-3 will probably be the final release
20:14:13 <redrobot> at which point we'll only be fixing security bugs....   well, and anything else that is broken that prevents normal operation.
20:15:28 <redrobot> ok, moving on
20:15:38 <redrobot> #topic Vancouver Design Summit
20:15:40 <redrobot> #link https://etherpad.openstack.org/p/barbican-L-design-sessions
20:16:03 <redrobot> So we have two fishbowl sessions during the Summit.
20:16:38 <redrobot> Looks like Castellan got a ton of votes
20:16:49 <redrobot> so I think we should make one of the fishbowls be about Castellan.
20:17:30 <redrobot> I think it'll be good to get a chance to talk about it in front  of a wide community audience.
20:18:07 <redrobot> There wasn't anything else that was an obvious candidate for the second fishbowl
20:18:11 <redrobot> so I'm open to suggestions.
20:19:52 <redrobot> Bueller?
20:20:03 <hockeynut> functional tests?
20:20:08 <redrobot> I was thinking maybe auditing would warrant a fishbowl session?
20:20:38 <redrobot> hockeynut I don't know that it would be a good fit for a fishbowl.  ie.  I don't think we need wide community audience to talk about our functional tests.
20:21:08 <hockeynut> redrobot ah ok, thanks.  Wasn't sure of the definition of "fishbowl"
20:21:08 <redrobot> hockeynut but I could be convinced otherwise...   do you think it's something that we need community input on?
20:21:16 <redrobot> hehe, sorry
20:21:43 <redrobot> "Fishbowl" is the new term used to describe the sessions that were previously part of the "design summit schedule"
20:21:43 <rellerreller> What stuff is outward facing besides content types? ACLs?
20:21:47 <alee> redrobot, certificates and cert related specs might be a good fishbowl session.  to get people familiar with what has been done and get feedback on what is still needed.
20:21:51 <hockeynut> I think jaosorior wanted to talk about naming/etc so we could probably just do something ad-hoc
20:22:18 <rellerreller> alee +1
20:22:45 <alee> of course we've had those in the past, but a lot of progress has been made since then.
20:23:08 <arunkant> redrobot, auditing +1, alee + 1
20:23:09 <redrobot> alee +1 I agree, SSL/TLS would be a good fishbowl session.
20:23:43 <redrobot> Castellan + SSL/TLS, and then Auditing if we have time?
20:24:02 <rellerreller> What's the SSL/TLS part of Castellan?
20:24:04 <redrobot> both of our Fishbowl sessions are scheduled back-to-back, so we could try to cover all 3 topics during that time.
20:24:20 <redrobot> rellerreller sorry, I meant to say one fishbowl for Castellan, and one for SSL/TLS
20:25:00 <redrobot> although the topic of SSL/TLS in Castellan might come up.
20:25:18 <woodster_> is there interest in discussing/design longer range features like federation? Maybe better for the M summit? :)
20:26:02 <redrobot> woodster_ I would be interested in spending some time with the Keystone folks to understand their take on federation.  But I don't think we'll be ready to tackle that in L
20:26:30 <arunkant> woodster_, is there impact of keystone federation on barbican side?
20:28:21 <redrobot> #link https://libertydesignsummit.sched.org/
20:28:26 <redrobot> ^^ is the schedule btw
20:28:36 <woodster_> arunkant: probably so, but I agree we could handle that directly with Keystone folks at the summit
20:29:20 <redrobot> oh, also before I forget
20:29:40 <redrobot> Sheena Gregson proposed a Barbican topic for the cross-project sessions on Tuesday.
20:30:00 <redrobot> I'll be there to help answer community questions on how to integrate with Barbican.
20:30:14 <arunkant> woodster_, okay. Don't know much about federation, was thinking that Barbican just needs token, regardless of how its generated. Agree, we can learn more about this summit.
20:30:20 <redrobot> anyone else who will be in Vancouver is welcomed to join.
20:30:40 <redrobot> well, if our topic gets picked anyway
20:30:52 <redrobot> I'm still not clear on how the cross-project day is going to work.
20:31:15 <redrobot> also, our work session for Friday is the afternoon. :-\
20:31:32 <redrobot> hopefully some of y'all will stick around for it...
20:32:11 <alee> redrobot, woodster_ another interesting topic that might have cross project interest is v1/v2, although I'm not sure we're ready to do a fishbowl session on it yet
20:32:49 <alee> redrobot, we'd need to figure out if we need to actually v2 first.
20:33:01 <redrobot> alee I was thinking we can start working session discussions on what a v2 would look like... but I think we shouldn't have a v2 until maybe M.
20:33:13 <alee> ok
20:33:18 <redrobot> alee I want to have the L cycle to figure out what is or isn't working in the TLS/SSL apis.
20:33:29 <alee> yup
20:35:18 <woodster_> alee, redrobot yeah probably so. I think the only things that could force v2 sooner are ay changes needed to default secret RBAC policy or a common API standard for APIs perhaps
20:35:56 <woodster_> maybe we'll have all docs for these new features in place by M :)
20:36:21 <redrobot> woodster_ lol
20:36:35 <redrobot> woodster_ our code is "self-documenting" ;)
20:36:50 <woodster_> redrobot: ha! Of course!
20:37:20 <pkazmir> Maybe in Vancouver we can have a discussion about the CLI output? There was some discussion on Friday here about perhaps suggesting alternate output formats for Cliff (like maybe JSON)? Seems like our output into tables doesn't print so well.
20:37:33 <redrobot> pkazmir +1
20:37:59 <redrobot> yeah, I promised chellygel I would hunt down the Cliff folks and talk to them about adding alternative output formats to the CLIs
20:38:15 <redrobot> ascii text tables, while pretty, are not very functional
20:40:18 <redrobot> pkazmir it would be good to add that topic to the design-sessions etherpad if it's not already there.
20:40:35 <redrobot> any other questions/comments about the design summit?
20:41:09 <pkazmir> redrobot: ok
20:42:08 <redrobot> #topic Open Discussion
20:42:14 <redrobot> That's all I have on the agenda for today
20:42:14 <x3k> I want to mention my blueprint https://blueprints.launchpad.net/barbican/+spec/versioned-objects
20:42:14 <woodster_> redrobot, do you think we have time to discuss adding a read-only ACL role to Barbican policy? This is for ACL-based secret and container reads.
20:42:18 <redrobot> anything else we need to talk about?
20:42:55 <x3k> right now only object's id's are passed via RPC, f.ex. an order id
20:43:21 <redrobot> #topic Versioned Objects
20:43:33 <redrobot> woodster_ I'll try to get to it after x3k's topic.
20:43:33 <x3k> implementing oslo.versionedobject would change this behaviour to pass thewhole objects instead, together with information about their versions
20:43:45 <woodster_> redrobot: no worries
20:45:14 <x3k> I can get the versioned-objects spec ready for reviews this week and we can discuss it there
20:45:26 <redrobot> x3k I'm not opposed to the idea.  It would be good to get a spec CR up though, so we can get input from the rest of the core team
20:45:38 <redrobot> #link https://wiki.openstack.org/wiki/Barbican/Blueprints
20:46:07 <redrobot> x3k also, welcome! :)
20:46:34 <x3k> there will also	be oslo sessions about versionedobjects at the summit
20:46:49 <x3k> redrobot, ok :)
20:46:53 * redrobot makes a note.
20:47:10 <redrobot> I'm the oslo liaison for the project, so I'll definitely be interested in those sessions
20:47:43 <woodster_> x3k good to know
20:48:18 <redrobot> #action x3k to submit CR to barbican-specs for Versioned Objects
20:48:33 <redrobot> x3k any other questions/comments on this topic?
20:48:58 <x3k> redrobot, no thats it, thanks!
20:49:18 <redrobot> #topic Additional role to enable per-secret ACL
20:49:25 <redrobot> woodster_ do you want to talk about this?
20:49:40 <woodster_> For sure. In short, we don't currently require a role for ACL-listed users to access/decrypt a secret
20:49:58 <woodster_> It would be good to introduce a role for that purpose.
20:50:26 <redrobot> just so we're all in the same page.  This change would only affect the sample policy file that is shipped with Barbican out of the box
20:50:29 <woodster_> This would enable a cloud/identity admin to revoke access to Barbican, while still retaining access to other projects
20:50:58 <woodster_> redrobot: that's correct. So if folks don't think this is a generic issue, then we could just leave the policy as is
20:51:26 <redrobot> woodster_ I like the additional role since it does allow an operator to cut off access to barbican only.
20:51:37 <woodster_> redrobot: We could then add info to the deployers guide to enable this further restriction if needed
20:51:46 <redrobot> I think it's a sensible thing to include in the default policy.
20:52:12 <woodster_> If we do add that to policy, then the question is what to call that role...bike shed time!
20:52:29 <redrobot> woodster_ wooo!  my favorite part!
20:52:38 <arunkant> woodster_, so to be clear, that role just need to be assigned to any openstack project..right..does not have to be on secret or container project..
20:52:46 <alee> woodster_, so the use case here is user X has been granted access to hundreds of secrets through acls, and now an admin wants to drop all his access?
20:52:47 <woodster_> we could reuse an existing role (like observer), but that would grant access to the projects secrets, not just the whitelisted ones
20:53:16 <woodster_> alee, that's correct
20:53:42 <alee> woodster_, all access or access to only acl-allowed secrets?
20:54:03 <alee> ie. could he access his own or his projects secrets?
20:54:11 <redrobot> alee so this would be a role that is needed by someone in addition to being in the acl-whitelist.
20:54:31 <redrobot> alee the policy would check for the new role + acl list.
20:54:44 <woodster_> alee, redrobot that's all correct
20:55:23 <redrobot> presumably an admin would first have to grant the role on the project to the user prior to being allowed to retrieve secrets in a whitelist.
20:55:52 <alee> redrobot, woodster_ so the user would still have access to non-acl-granted secrets .. ie. his own or his projects .  Ok just checking that I understand the proposed chande
20:55:55 <alee> change
20:56:20 <woodster_> alee: for non ACL secrets, the other roles apply
20:56:32 <alee> gotcha
20:57:07 <rm_work> I see the typical deployment giving out this new role alongside the other default barbican roles
20:57:26 <rm_work> but really, that's totally up to the deployer
20:58:14 <redrobot> rm_work yup.  up to the deployer.  I think it would be a nice example to give in the default policy to show what is possible.
20:58:21 <rm_work> otherwise full agreement with redrobot / woodster_ ^^
20:58:32 <arunkant> woodster_, so if you have a project where you have ACL and non-ACL secrets, then does it mean user needs to have 'new role' on that project ?
20:59:07 <woodster_> arunkant: for the ACL based ones yes.
20:59:10 <redrobot> arunkant yes, but only to read ACL secrets.
20:59:15 <rm_work> err, the new role would be gra
20:59:18 <woodster_> any good names out there then? granted-observer maybe?
20:59:26 <redrobot> woodster_ I think we can bikeshed the name in the CR
20:59:30 <woodster_> oh no, out of time I think!
20:59:33 <redrobot> also we're just about out of time.
20:59:48 <rm_work> *err, the new role would be granted just once to any project, because we'd just be checking the "read_other" role for the user's own project, not every other project, right?
20:59:48 <redrobot> Thanks for coming everyone!
21:00:01 <rm_work> kk, can take to chnnel
21:00:06 <rm_work> *main channel
21:00:08 <redrobot> #endmeeting