20:00:30 <redrobot> #startmeeting barbican
20:00:31 <openstack> Meeting started Mon Aug  3 20:00:30 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:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:35 <openstack> The meeting name has been set to 'barbican'
20:00:49 <redrobot> #topic Roll Call
20:00:56 <redrobot> As usual the meeting agenda can be found here:
20:00:56 <rellerreller> o/
20:00:59 <jaosorior> o/
20:00:59 <silos> o/
20:01:01 <arunkant> o/
20:01:03 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:02:02 <kfarr> o/
20:02:12 <diazjf> o/
20:02:15 <alee> o/
20:02:17 <redrobot> I doubt most of the rackspace crew will show
20:02:30 <redrobot> they're walking around DC today
20:02:54 <alee> redrobot, ah everyone went up early?
20:03:19 <redrobot> alee yup! most left yesterday... I'm not flying out til tomorrow though
20:03:42 <jaosorior> bummer I'm missing this mid-cycle :/
20:03:46 <alee> redrobot, ditto
20:03:46 <redrobot> so this may be all of us today
20:03:46 <redrobot> let's get started
20:04:02 <redrobot> I'll be sure to get extra drunk in your honor jaosorior
20:04:13 <jaosorior> hahaha excellent!
20:04:28 <redrobot> #topic Action Items from last week
20:04:49 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-07-27-20.00.html
20:05:05 <redrobot> first redrobot to do some Launchpad grooming for Liberty-2
20:05:40 <redrobot> So liberty-2 was released last Tuesday
20:05:42 <redrobot> #link https://launchpad.net/barbican/+milestone/liberty-2
20:05:55 <redrobot> And I did do some cleaning of LP
20:06:25 <redrobot> I think I just have some bug priorities left to sort out
20:06:56 <redrobot> #action redrobot to finish prioritizing liberty-2 bugs, and also check them for kilo status
20:07:11 <redrobot> next redrobot and jaosorior to fix the stable/kilo gate failures
20:07:27 <redrobot> Aaaand I totally didn't have time to pitch in, jaosorior
20:07:35 <redrobot> any updates on your part?
20:07:50 <jaosorior> I haven't been able to figure it out. Today I tried asking help from the guys from infra. But had no response
20:07:55 <jaosorior> tomorrow I'll try to ping them again
20:08:06 <jaosorior> on the other hand, tomorrow I go on vacations
20:08:10 <jaosorior> for 2 weeks
20:08:22 <jaosorior> well, on wednesday
20:08:45 <jaosorior> so it'll be a bit hard for me to continue this
20:09:08 <redrobot> jaosorior I'll pick it up at the mid-cycle then... I'm hoping we'll have at least a day or two of just hacking
20:09:21 <redrobot> #action redrobot to fix the stable/kilo gate failures during mid-cycle
20:09:22 <jaosorior> so, someone has to take over this commit and the subsequent ones if we want this fixed soon: https://review.openstack.org/#/c/205059/
20:09:46 <alee> jaosorior, I'll take it over if we dont get it resolved this week
20:09:47 <redrobot> jaosorior hehe, fun
20:10:11 <jaosorior> well, you two can pair it in the mid-cycle :D
20:10:23 <redrobot> and last one was jaosorior to backport the DogTag gate fixes into stable/kilo
20:10:31 <redrobot> which I assume is blocked on the gate failures
20:10:37 <jaosorior> yes
20:10:41 <jaosorior> those commits are there already for review
20:10:48 <alee> jaosorior, oh I fully expect redrobot to fix it. I'll just stand right behind him and make sure he does it.
20:10:52 <jaosorior> and they depend on the commit I linked you to, above
20:11:02 <redrobot> #action redrobot and alee to backport the DogTag gate fixes into stable/kilo after redrobot fixes the gate
20:11:09 <redrobot> alee lol, I believe it!
20:11:18 <alee> jaosorior, I will take over the dogtag one
20:11:20 <jaosorior> alee: haha at least provide him with beers to motivate him
20:11:26 <redrobot> ok, that's it for action items
20:11:34 <redrobot> on to the agenda itmes
20:11:39 <redrobot> items even
20:12:31 <redrobot> #topic Multiple-KMIP Device Support blueprint
20:12:33 <redrobot> #link https://review.openstack.org/#/c/194298/
20:13:05 <redrobot> silos did you want to talk about this?
20:13:11 <silos> yes.
20:13:49 <silos> I just wanted to get everyone's opinion and concerns on this.
20:14:23 <silos> speficially If it's okay to alter some of the KMIP Secret Store code to enact this BP.
20:14:34 <redrobot> I was reading through it earlier...  one thing I'm concerned about is adding new routes to the API that are very specific to a particular backend.
20:14:52 <silos> redrobot: ah
20:14:54 <redrobot> I'm currently looking into the way other projects handle extensions
20:14:55 <rellerreller> redrobot I had the same concern
20:15:37 <elmiko> o/ sorry
20:15:43 <rellerreller> I think the spec raises an interesting question. Should we allow a mapping from a project to a secret store?
20:16:02 <rellerreller> In the past we said we would only have one secret store to make things simpler.
20:16:33 <rellerreller> This removes complexities from doing things like get transport key and then send back a wrapped key. The wrapped key could go to the wrong secret store.
20:17:00 <rellerreller> However, if a project only has one secret store then a lot of the complexity may be able to be eliminated.
20:17:31 <rellerreller> And the interface is simple to user because they still do not know about multiple secret stores.
20:17:49 <redrobot> Yeah... previously we've recommended that a new Barbican be spun up for different backends...  But it does seem a little weird to spin up multiple nodes for the same kind of backend.
20:18:12 <redrobot> silos I'd like to understand the use case a little more...
20:18:22 <rellerreller> I think it is an interesting idea, and there are some really good use cases.
20:18:43 <silos> The main use case derives from separating KMIP servers on a public cloud.
20:19:00 <silos> Some tenants would prefer their secrets stored in an isolated KMIP device.
20:19:29 <redrobot> It seems a little counter intuitive... arguably the purpose of a cloud service is to pool resources together...
20:20:09 <rellerreller> The nice part about it is that a user can provide their own KMIP server and monitor it.
20:20:18 <silos> yea. I think it's more of a security concern than a resources concern. The fact that everyone's keys are in the same pool.
20:20:27 <redrobot> so a tenant would rent a device?  kind of like Amazon's HSM offering?
20:20:45 <rellerreller> So if I want my keys to be actually deleted then I smash my KMIP server :)
20:20:45 <redrobot> I tend to think of this as a private-cloud use case
20:21:17 <silos> I think it's more along the lines of what rellerreller said. I could bring my own KMIP device.
20:21:21 <redrobot> seems like this is a better fit for private cloud federation...
20:21:42 <rellerreller> It's a hybrid cloud where most everyhting is public but KMIP server
20:21:47 <redrobot> ie, I have my own device, set up my own barbican, and federate secrets that are needed in public cloud.
20:22:37 <silos> So in a federated barbican scenario the KMIP device is attached on the customer side not mgmt side?
20:23:09 <redrobot> silos yeah... a customer keeps their kmip (or other secret store) on their own premise.
20:23:20 <redrobot> silos and then puts a private barbican in front of it
20:23:28 <alee> rellerreller, silos , redrobot - I can see the possible use case, but I agree with the concern about adding routes specific to a type of backend.  rellerreller idea of tying a project to a specific backend sounds like something to consider.
20:23:31 <redrobot> silos then secrets are federated out to the public barbican when needed.
20:23:43 <alee> we do the same thing on the cert side.
20:24:01 <alee> ie. allow you to associate a CA with a project/tenant
20:24:11 <rellerreller> alee right.
20:24:44 <rellerreller> Then you can do things like this project paid for HSM, so we give them that. Or this project did not want that and get software based HSM.
20:24:50 <silos> alee, rellerreller, redrobot, diazjf and myself have actually already pushed code that ties a kmip device to a single project. So I don't believe it would be that hard to implement.
20:25:18 <silos> https://review.openstack.org/#/c/207192/
20:25:24 <diazjf> https://review.openstack.org/#/c/207202/
20:25:39 <redrobot> I still don't see the benefit of putting this all in the same instance of barbican
20:26:11 <redrobot> in the past, we've talked about providing one instance per backend ... which led to https://review.openstack.org/#/c/135779/
20:26:43 <redrobot> you could give a user who wants an hsm the endpoint https://hsm.barbican.mycloud.com:9311
20:27:24 <redrobot> and someone who has a software based barbican https://hillcountry-fare.barbican.mycloud.com:9311
20:27:29 <rellerreller> redrobot you are suggesting that registering the specific barbican service with keystone, so only that one is used?
20:28:14 <rellerreller> That is definitely another option, and most of the support is there for that.
20:28:15 <redrobot> yeah... Keystone already has separate endpoints for different regions
20:29:02 <rellerreller> I guess the downside is that customer who wants specific KMIP device has to spin up another Barbican instance.
20:29:54 <redrobot> yeah... but if they're already racking their own HSM in their own data center, I don't think putting barbican in front of it would be much of a stretch
20:30:13 <redrobot> otherwise, I have my hsm in my prem, but have to hand over the credentials to my cloud provider
20:30:59 <redrobot> federation would make that a little nicer, rather than just giving the cloud provider unlimited read/write access to my hsm.
20:31:16 <silos> Wouldn't spinning up instances become very costly? Instead of 20 barbicans hooked up to 20 KMIP's it sounds more efficient attaching the 20 KMIP devices to a single barbican.
20:31:31 <redrobot> silos depends on where the servers are...
20:32:06 <silos> redrobot: true
20:32:20 <redrobot> with the right config management tooling, spinning up new instances should be reatlively cheap
20:32:41 <alee> rellerreller, redrobot sorry - need to drop -- but if could you guys specify any other info we might need to get to the midcycle?   I'll check the transcript later.  Right now all I know is the address.
20:33:01 <redrobot> alee there's more detail in the etherpad
20:33:02 <rellerreller> The security part is interesting as well. Managing my own Barbican with own backend sounds more secure than giving credentials to remote Barbican.
20:33:14 <alee> redrobot, link?
20:33:27 <kfarr> alee https://etherpad.openstack.org/p/barbican-liberty-midcycle
20:33:41 <rellerreller> alee have you looked at the mid-cycle etherpad page?
20:34:02 <rellerreller> alee you can always email or call me.
20:34:21 <alee> rellerreller, cool thanks. looking at it now.
20:34:27 <silos> This has been a great discussion but I don't wanna hog all the time if we want to move on redrobot.
20:34:46 <kfarr> alee there's a link on the etherpad page to a Visitor's Guide, it has some pretty thorough maps.  The building we'll be in is the Kossiakoff Center
20:34:49 <rellerreller> I have to drop off in a minute as well.
20:35:24 <alee> kfarr, rellerreller cool  thanks -- I think that should be enough to get me there.
20:35:30 <redrobot> silos will you be joining us in MD?
20:35:51 <silos> yup :-D diazjf who has been helping me will be there as well.
20:36:07 <rellerreller> excellent
20:36:14 <redrobot> silos awesome, let's add a bullet point to that mid-cycle etherpad to continue this conversation
20:36:31 <silos> redrobot sounds good
20:36:45 <redrobot> ok, moving on
20:36:49 <redrobot> #topic Castellan merge requests
20:36:55 <redrobot> kfarr do you want to talk about this one?
20:37:24 <kfarr> I just wanted to make a note that there's a few Castellan merge requests out there
20:37:51 <redrobot> kfarr I had a question about the formatting of the different secrets...
20:37:53 <kfarr> I figured we'd get through them all at the mid-cycle, just thought I'd bring it up early just in case
20:38:07 <redrobot> I'll just add to the review then
20:38:07 <kfarr> redrobot, what's your question?
20:38:14 <kfarr> oh got it
20:38:30 <redrobot> I was wondering why password was a byte-array instead of a string...
20:38:41 <redrobot> also a few questions about the actual format of other types
20:39:04 <redrobot> adn whether castellan should be able to do format conversions
20:39:13 <redrobot> DER -> PEM and back for example
20:39:46 <kfarr> Right now, the assumption that everything was going to be passed in as a bytearray and in DER format, to keep things simple and consistent
20:39:53 <rellerreller> signing off
20:40:21 <redrobot> ok, I'll keep that in mind for the airplane reviews tomorrow
20:40:35 <redrobot> I think it would be interesting to consider other formats for v2 and beyond
20:40:49 <kfarr> Ok thanks redrobot!  Yes, that's a good point
20:41:08 <redrobot> ok, that's all we have on the agenda
20:41:36 <redrobot> last topic I guess should be
20:41:41 <redrobot> #topic Mid-Cycle Sprint
20:41:55 <redrobot> #link https://wiki.openstack.org/wiki/Sprints/BarbicanLibertySprint
20:42:02 <redrobot> #link https://etherpad.openstack.org/p/barbican-liberty-midcycle
20:42:22 <redrobot> hopefully everyone who is going has travel figured out already
20:42:35 <redrobot> kfarr we're scheduled to start Wed at 9am, yes?
20:43:06 <kfarr> Yes!  I think rellerreller and I plan to be there at 8:30 just to make sure everything's all good to go, expecting people to show up at 9
20:43:45 <redrobot> kfarr awesome!  excited to go eat crab with y'all :)
20:44:02 <kfarr> It'll be a good time :)
20:44:31 <kfarr> I mentioned this earlier, but since last week's meeting, I put a link to a Visitor's Guide on the etherpad page
20:44:43 <kfarr> It's got some really useful maps and info
20:45:29 <redrobot> sounds good!
20:45:37 <redrobot> any other questions/comments about the mid-cycle?
20:45:55 <kfarr> That's all from me!
20:46:37 <redrobot> #topic Open Discussion
20:46:45 <redrobot> That's all I had on the agenda for today.
20:47:06 <redrobot> Any other topics we should discuss?
20:47:16 <arunkant> Will appreciate if ACL support changes in barbican client can be reviewed (3 reviews) . Especially docs related to changes (https://review.openstack.org/#/c/208343/)
20:48:14 <redrobot> arunkant sounds good... I'm going to see about getting one of those wifi passes for my flight tomorrow and catch up on castellan and client reviews
20:48:40 <arunkant> redrobot and others, will be useful to get feedback if new commands and api looks okay.
20:48:50 <arunkant> redrobot, okay. thanks
20:49:50 <redrobot> Alrighty then, sounds like we're done a little early for today
20:50:05 <redrobot> Thanks everyone for joining.  Se y'all in MD!
20:50:23 <redrobot> #endmeeting