20:00:11 <redrobot> #startmeeting barbican 20:00:12 <openstack> Meeting started Mon Oct 13 20:00:11 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:16 <openstack> The meeting name has been set to 'barbican' 20:01:07 <redrobot> Hi everyone, welcome to the Barbican weekly meeting 20:01:13 <redrobot> as usual the agenda can be found here: 20:01:14 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:01:18 <redrobot> #topic RollCall 20:01:23 <jvrbanac> o/ 20:01:29 <atiwari> o/ 20:01:31 <rellerreller> \o 20:01:57 <mattvryan> o/ 20:02:51 <redrobot> not a whole lot of barbicaneers here today... 20:02:56 <redrobot> this should be a pretty quick meeting 20:03:09 <redrobot> #topic Kilo Development is now Open 20:03:42 <redrobot> The release team has released RC1 20:03:57 <redrobot> which means that the master branch is now tracking Kilo development 20:04:44 <redrobot> I saw there's a few blueprints up for review for the Kilo cycle as well, so it seems Killo is underway 20:04:50 <redrobot> any questions/comments about that? 20:05:24 <redrobot> in case anyone is interested, this CR marks the beginning of Kilo 20:05:27 <redrobot> #link https://review.openstack.org/#/c/125678/ 20:06:06 <redrobot> ... 20:06:09 <redrobot> quiet group today 20:06:20 <tsv> redrobot, i am working on pushing a spec for the quota implementation. will do that before tomorrow 20:08:24 <redrobot> tsv awesome, will try to take a look as soon as I can 20:08:32 <redrobot> got a backlog of stuff to read already >_> 20:09:06 <atiwari> redrobot, I have also move two of my spec to K branch 20:09:29 <redrobot> yep, I've seen that there's quite a few specs up 20:09:41 <redrobot> we'll definitely have plenty to talk about in Paris 20:09:49 <redrobot> atiwari and tsv are you guys going to Paris? 20:10:00 <atiwari> I am coming 20:10:19 <redrobot> atiwari awesome... I think I asked you that already now that I think of it. 20:10:32 <atiwari> :) 20:10:38 <tsv> redrobot, am not. hopefully next time 20:11:09 <redrobot> Ok, any other topics we want to discuss today? 20:11:17 <atiwari> redrobot, are we finalize the summit design sessions ? 20:11:33 <redrobot> #topic Kilo Design Summit 20:11:44 <redrobot> #link https://etherpad.openstack.org/p/barbican-kilo-design-sessions 20:12:09 <redrobot> Per the link above, I think the following will be official Design Sessions on the schedule: 20:12:18 <redrobot> How to deal with multiple plugins over a system's lifetime? 20:12:31 <redrobot> Common Certificate Issuance API 20:13:02 <redrobot> Integration discussion with other OpenStack projects 20:13:13 <redrobot> and we'll save the 4th desing session for Kite 20:13:32 <rellerreller> I'm really interested in "Integration discussion with other OpenStack projects" 20:13:40 <atiwari> rellerreller, +1 20:13:45 <redrobot> not set in stone yet, but I'm pretty sure that'll end up being the sessions. 20:14:05 <redrobot> rellerreller me too... I'll try to get that one in early in the day so we have plenty of energy :) 20:14:07 <rellerreller> I saw the patch for Neutron. It does not follow the same pattern as Cinder and Nova. 20:14:45 <rellerreller> I think Swift will be same as Cinder and Nova. I think it is critical to get all of them integrating in the same way. 20:15:04 <rellerreller> Are there any special procedures or anything for getting stuff into oslo? 20:15:20 <atiwari> redrobot, for "Common Certificate Issuance API" do we have any spec rolling ? 20:15:56 <atiwari> we have stared on "https://review.openstack.org/#/c/108429/" sometime back 20:16:02 <redrobot> rellerreller I think stuff goes into incubator, and then we can iterate on it until it's polished and released as its own library. 20:16:02 <atiwari> on/one 20:16:25 <redrobot> atiwari I expect a blueprint to be the result of the Design Session 20:16:33 <atiwari> ok 20:16:59 <redrobot> atiwari the idea is to agree on a common set of data that can be used to provision Certificates acorss all plugins 20:17:15 <atiwari> redrobot, make sense 20:17:18 <rellerreller> redrobot ? I think there is common code for integrating Barbican. I think oslo would be a good place for it. 20:17:50 <redrobot> rellerreller possibly... what do you have in mind? Is this the extra Key Manager façade on top of barbicanclient? 20:18:07 <rellerreller> redrobot yes 20:19:04 <rellerreller> I like that, so that it provides a plugin capability for any type of key manager. For instance if a hardware vendor creates a key manager that can support authenticating Keystone tokens. 20:19:18 <redrobot> rellerreller it's an interesting pattern. I'm actually a bit puzzled by it. I thought we envisioned Barbican to be the abstraction on top of the various keystores 20:19:37 <redrobot> so that integration would be done with barbicanclient directly. 20:19:52 <atiwari> redrobot, any plans on " User-level access to resources, such as secrets/containers" we are getting lots of interests now? 20:20:33 <redrobot> atiwari we'll definitely talk about it in Paris. It will be an ad-hoc discussion, since we don't have any more official design session slots. 20:20:43 <rellerreller> redrobot It's for the use case where talking directly to hardware key store. 20:20:58 <atiwari> redrobot, ok 20:21:58 <redrobot> rellerreller it will be interesting to talk about in Paris for sure. I would argue that Barbican is similar to Keystone in that it should be THE openstack way of handling the problem domain 20:22:13 <redrobot> you wouldn't run your Service against a non-keystone auth layer directly 20:24:22 <rellerreller> redrobot With the key management I can see differences. Some organizations have requirements for how keys are managed and stored. Having a non-certified entity like Barbican manage the access control may not be good enough. 20:25:17 <redrobot> hmm... I see your point rellerreller 20:25:27 <rellerreller> I'm not sure yet. I feel like adding the Key Manager level on top does not add that much overhead and opens up more possibilities while supporting Barbican as the key management service. 20:26:39 <redrobot> I think we can table the discussion for now? It's definitely something to keep in mind, but I don't think we have enough interested parties today to fully flesh that out. 20:27:53 <rellerreller> redrobot for sure. But I think this would be great to discuss in Paris. 20:28:21 <redrobot> rellerreller absoultely. I think it'll be one of the first points we touch on during the Integration Design Session 20:28:23 <rellerreller> The difficult part with key management is that it cuts across most, if not all, of the services. 20:29:15 <rellerreller> It's tough to get everyone on board. I don't know how we are going to do that. 20:30:58 <atiwari> redrobot, on KMIP implementation. what is the status? 20:31:06 <redrobot> I think as long as we get a majority agreement, we'll be in good shape. 20:31:24 <redrobot> atiwari KMIP is rellerreller's area 20:31:40 <rellerreller> atiwari The KMIP secret store can generate and store symmetric keys 20:31:41 <bubbva> we have some interest in KMIP area, too. 20:31:43 <redrobot> I think we're close to getting pykmip into global requirements 20:32:09 <rellerreller> We are looking to add asymmetric key support in Kilo 20:33:04 <atiwari> rellerreller, when we will be ready to integrate a KMIP complaint HSM. Any road map ? 20:33:06 <rellerreller> We are also continuing to work on PyKMIP 20:34:12 <rellerreller> atiwari So we are integrating KMIP using the secret store interface. That is working, and we can do Cinder volume encryption with a hardware KMIP device. 20:34:50 <rellerreller> atiwari I think there is another CR for KMIP as a Barbican HSM plugin. It was under review, but I do not know the current status. 20:35:19 <atiwari> rellerreller, thanks I will check on that one 20:35:33 <atiwari> redrobot, one more question 20:35:37 <rellerreller> atiwari https://review.openstack.org/#/c/116878/ -- this is the HSM plugin CR for KMIP 20:35:59 <atiwari> rellerreller, thanks 20:36:45 <atiwari> rellerreller, this is not KMIP 20:37:11 <atiwari> this our proprietary impl 20:37:37 * redrobot has not had time to review the Atalla patch 20:38:06 <rellerreller> I thought Atalla ESKM was a KMIP device. Sorry, I was mistaken. 20:39:15 <atiwari> I will start on then 20:39:28 <atiwari> it is KMIP but this plugin is not 20:39:48 <rellerreller> atiwari Just read this "ESKM 4.0 KMIP meets the highest standards for all KMIP versions and supports all your HP Storage KMIP enabled solutions." 20:40:33 <rellerreller> OK, thanks for clearing that up. I was wondering how they were talking to the device. 20:41:05 <redrobot> ok, so ... do we have any more questions/comments for today? 20:42:30 <redrobot> bubbva and mattvryan do you have any questions we could answer now? 20:42:31 <atiwari> redrobot, yes 20:42:39 <redrobot> atiwari what's up? 20:42:55 <bubbva> redrobot: not really, just curious where we could learn more about KMIP integration (for me and hachao) 20:42:55 <atiwari> what is going on with FreeIPA 20:42:59 <atiwari> redrobot, 20:43:09 <bubbva> and any prep we need to do for Paris 20:43:30 <atiwari> redrobot, any plans to integrate with FreeIPA 20:44:05 <redrobot> bubbva we've currently got 3 plugins for the backend: PCKS11, KMIP, and DogTag, all with various levels of completeness. 20:44:14 <bubbva> great 20:44:23 <mattvryan> redrobot one question - will webex be available for the design sessions? 20:44:29 <redrobot> bubbva the KMIP plugin development is led by rellerreller, so you can probably bug him with specific questions ;) 20:44:39 <bubbva> wil do! 20:45:01 <rellerreller> bubbva I would be happy to discuss KMIP. 20:45:05 <redrobot> mattvryan I'm not sure. That's a good question though. I'll ask the TC and have an answer for you next week. 20:45:25 <redrobot> #action redrobot to find out if the desing sessions will be broadast 20:45:33 <redrobot> #action redrobot to find out if the desing sessions will be broadcast 20:45:36 <bubbva> rellerreller: thank you. Is there a good "starting point" for me to look to see what our plans are around KMIP? 20:45:37 <mattvryan> redrobot ok - it looks like previous design sessions did but I couldn't find any info for this one. 20:45:49 <bubbva> or is it best to just work with you directly, rellerreller 20:46:42 <rellerreller> bubbva That is a good question. Probably work directly for now. We have not posted much documentation online about KMIP and OpenStack. 20:46:45 * mattvryan admittedly didn't look very hard 20:47:50 <redrobot> yeah, documentation is going to be one of the areas we'll have to focus on for Kilo 20:50:40 <redrobot> atiwari no plans on our end for FreeIPA. I would not be opposed to a new plugin though. 20:51:28 <redrobot> atiwari, actually, I'm not sure we'd need a new plugin... 20:51:33 * redrobot brushes up on FreeIPA real quick 20:51:59 <atiwari> redrobot, OK 20:52:25 <redrobot> atiwari seems like FreeIPA is more of an Identity management tool than a key store? 20:52:39 <atiwari> it has dogtag 20:52:49 <redrobot> atiwari we talk directly to dogtag 20:52:56 <atiwari> redrobot, correct 20:53:13 <redrobot> atiwari what kind of use cases are you envisioning with FreeIPA? 20:53:39 <atiwari> for certificate provisioning 20:53:54 <redrobot> we can provision certificates directly from DogTag 20:53:55 <rm_work> o/ 20:54:03 <redrobot> rm_work what's up? 20:54:18 <atiwari> I am taking about certmonger use case 20:54:38 <atiwari> which deals with provisioning target 20:54:39 <rm_work> just arrived, saying i'm here in case you had anything you wanted to discuss re: anything I was on 20:54:54 <rm_work> nothing specific 20:55:05 <redrobot> rm_work in the nick of time... 20:55:26 * rm_work is technically on ETO today 20:55:43 <redrobot> atiwari I don't understand how FreeIPA fits into the big picutre... but I don't think we have time to discuss that today, since we only have 5 minutes left. 20:55:54 <atiwari> np 20:55:56 <redrobot> atiwari maybe we can bring it up again next week 20:56:00 <atiwari> lets take it later 20:56:30 <redrobot> Ok, guys. Please fell free to add Agenda topics in advance of the meeting 20:56:43 <rm_work> oh, <rellerreller> I saw the patch for Neutron. It does not follow the same pattern as Cinder and Nova. 20:56:46 <redrobot> it definitely helps move the meeting along. 20:56:51 <rm_work> which is also different that LBaaS 20:56:56 <rm_work> need to do some coordinating 20:57:15 <rm_work> (sorry, trying to skim the backlog as fast as possible) 20:57:29 <rm_work> *different than LBaaS 20:57:41 <rm_work> re: my comment here: https://review.openstack.org/#/c/127823/ 20:58:05 <rm_work> integrating other Openstack projects is great, but we need to coordinate them all 20:58:09 <rm_work> or we're going to end up with a mess 20:58:58 <rm_work> that was my only important comment for now, I think :) 20:59:02 <mattvryan> what about inviting a rep from each of the other interested projects to get involved in Barbican? go the other way around 20:59:10 <rm_work> that would be good 20:59:12 <mattvryan> (too late to discuss :) ) 20:59:14 * rm_work is the rep from LBaaS 20:59:27 <mattvryan> that's how we do it in the IETF 20:59:38 <rm_work> yeah, and I've been trying to be quite involved 20:59:47 <rm_work> but i haven't actually met anyone from Cinder/Nova yet 20:59:51 <redrobot> yep, I have it in my to-do list to reach out to all the PTLs to make sure they send someone to this design session 20:59:53 <rm_work> anywho, meeting end I think 20:59:57 <rm_work> erk 20:59:59 <rm_work> damnit 21:00:00 <redrobot> yep, thanks for coming everyone 21:00:06 <redrobot> #endmeeting