20:01:27 <redrobot> #startmeeting barbican 20:01:28 <openstack> Meeting started Mon Aug 11 20:01:27 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:31 <openstack> The meeting name has been set to 'barbican' 20:02:03 <redrobot> Sorry about that guys... almost missed the meeting time 20:02:13 <redrobot> as usual the agenda can be found here: 20:02:15 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:02:20 <redrobot> #topic Roll Call 20:02:28 <rellerreller> o/ 20:02:31 <jvrbanac> _o/ 20:02:32 <woodster_> o/ 20:02:32 <kaitlin-farr> o/ 20:02:38 <blpoulos> o/ 20:02:41 <hyakuhei> o/ 20:02:55 <SheenaG1> o/ 20:02:59 <chellygel> \o/ 20:03:05 <paul_glass> o/ 20:03:22 <redrobot> awww yeah!!! lots of barbicaneers here 20:03:34 <SheenaG1> IT'S A PARTY! 20:03:53 <redrobot> hehe indeed! 20:04:02 <redrobot> ok, let's get the ball rolling 20:04:07 <redrobot> #topic Barbican Integration 20:04:17 <redrobot> #link https://wiki.openstack.org/wiki/Barbican/Integration 20:05:05 <redrobot> So, I was asked by SheenaG1 to start looking into the integration tasks we'll be needing to meet to graduate from Incuabation 20:05:25 <redrobot> the documented requirements are listed here: 20:05:27 <redrobot> #link http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst#n79 20:05:53 <redrobot> the first link is for a wiki page that summarizes the items that I think still need work 20:06:39 <redrobot> I still have to get a hold of the TC to figure out if there are any undocumented requirements 20:07:00 <redrobot> I am expecting at least half a dozen undocumented requirements per our experience Incubating 20:07:29 <redrobot> in any case... the biggest item in the list in my opinion is integration with Horizon 20:07:52 <redrobot> I don't think anyone has looked at integration, or even blueprinted what integration might look like 20:08:21 <redrobot> Another big area is documentation, which I know SheenaG1 is starting to tackle 20:08:57 <SheenaG1> Wheeeeeee. 20:09:06 <redrobot> so I wanted to bring up the topic, to see if there are any contributors who may have free time to look into the Horizon integration piece 20:09:09 <rellerreller> I saw there is a docs gate test. What is that doing? 20:09:44 <redrobot> rellerreller so the docs gate was added by infra (we think?) some time last week 20:10:04 <rellerreller> What kind of help are you looking for with the Horizon integration? What are you hoping to see? 20:10:50 <rellerreller> redrobot what does the docs gate test do? I just noticed it today. 20:10:53 <redrobot> right now it's not doing much. it's basically just running tox -e docs, which in turn is just running setup.py build_sphinx 20:11:20 <redrobot> eventually the docs are going to end up in docs.openstack.org 20:11:40 <redrobot> oh, never mind, I think they're already being pushed 20:11:41 <redrobot> #link http://docs.openstack.org/developer/barbican/ 20:11:50 <rellerreller> OK, that's good to know. 20:12:15 <redrobot> I'm not entirely sure if this is pushed every merge, or if its only during release 20:12:37 <redrobot> but yeah... it did kind of take everyone by surprise when the gate turned on last week. 20:13:18 <redrobot> The idea is that we'll start building the Sphix based documentation, which is docs aimed at developers/contributors 20:13:24 <redrobot> *Sphinx 20:13:46 <redrobot> The docs I linked is a first pass I made at documenting things a few weeks back 20:14:02 <redrobot> I don't think there's much there, so any help would be appreciated 20:14:15 <redrobot> as far as Dashboard (Horizon) integation, I htink that's still up for debate 20:14:39 <redrobot> to be honest, I'm not sure if it's up to us, Horizon or the TC to decide what the integration would look like 20:14:56 <redrobot> jraim are you around? 20:15:23 <redrobot> the governance docs don't go into much detail as to what is required, other than "some" integration is required 20:16:01 <redrobot> Depending on what is needed, we may not be able to graduate to integrated for Kilo 20:16:46 <redrobot> so now that I'm talking about it here, maybe I need to dig deeper into this? 20:18:07 <woodster_> sounds like reaching out earlier to the TC similar to what jraim did for incubation might be needed. 20:18:19 <redrobot> I agree 20:18:37 <SheenaG1> x2 20:18:50 <redrobot> #action redrobot will reach out to TC to flesh out Integration requirements, especially Horizon integration 20:19:58 <redrobot> I think it would be awesome if we can Graduate when our review comes up at the end of Juno, but I'm starting to think it may be a long shot 20:21:14 <redrobot> Also, is there anyone interested in being part of the vulnerability disclousure process for Barbican? 20:21:28 <redrobot> I was thinking of volunteering myself, but we'll need at least one more 20:21:34 <redrobot> preferably a couple more 20:21:40 <chellygel> what does that entail? 20:21:54 <redrobot> all the details are outlined here: 20:21:56 <redrobot> #link https://wiki.openstack.org/wiki/Vulnerability_Management 20:21:58 <woodster_> sounds personal 20:22:21 * redrobot feels a little vulnerable ;) 20:22:38 <hyakuhei> redrobot: I'd like to help out - being ex VMT etc I might be able to add value. 20:22:54 <hyakuhei> might be a nice way to get more involved too. 20:23:10 <redrobot> hyakuhei woohoo! sounds good 20:23:46 <woodster_> This line is interesting: "Where a member of the team is employed by a downstream stakeholder, the member does not give their employer prior notice of any vulnerabilities." What if your employer is implementing the code themselves? 20:24:21 <hyakuhei> woodster_: It's just a best intention document - not the most presciptive of policies... 20:24:44 <woodster_> hyakuhei: ok, thanks 20:25:03 <redrobot> hyakuhei send me your contact info so I can list you as a Vulnerability contact for Barbican 20:25:14 <redrobot> hyakuhei /me douglas.mendizabal AT rackspace.com 20:25:23 <hyakuhei> Righto 20:27:07 <redrobot> I think that's all I wanted to cover for now... I'll be talking to the TC as we get closer to the end of the cycle 20:27:27 <redrobot> any questions/comments before we move on to the next agenda point? 20:28:36 <redrobot> ok, moving on. 20:28:49 <redrobot> #topic Barbican as a Keystone service 20:28:55 <redrobot> rellerreller you wanted to talk about this? 20:28:59 <rellerreller> blpoulos has been working to integrate Barbican into Nova and Cinder. She ran into an issue and is wondering if others know how to solve it. 20:29:12 <blpoulos> I am working on patches https://review.openstack.org/#/c/104001/ for nova and https://review.openstack.org/#/c/104339/ for cinder. 20:29:19 <blpoulos> These patches add a barbican keymgr wrapper, so that barbican can be used with cinder volume encryption. 20:29:25 <blpoulos> Currently, I am unable to get the barbican service URL, and provide it manually as a config parameter. 20:29:32 <blpoulos> Ideally, this would come from the service catalog. 20:29:38 <blpoulos> I would like to create a barbican client with just the nova context or cinder context. 20:29:44 <blpoulos> These context objects have the auth token and the user ID, among other values. 20:29:50 <blpoulos> Does anyone have any experience/ideas for using the context objects to create a barbican client? 20:29:58 <blpoulos> (Where this would be used would be line 70 of https://review.openstack.org/#/c/104339/10/cinder/keymgr/barbican.py) 20:31:34 <redrobot> blpoulos it is possible that barbicanclient does not support context objects 20:31:54 <redrobot> barbicanclient has not been getting all the attention it should, so it's lagging behind a bit 20:32:10 <redrobot> we were also waiting for some patches to land on keystoneclient to be able to use sessions and other goodies 20:32:19 <blpoulos> gotcha 20:32:54 <redrobot> we /should/ have an entry in Keystone catalog for the service endpoint though 20:33:27 <blpoulos> Using devstack I do have an entry in Keystone for barbican 20:33:42 <blpoulos> but I'm just having trouble accessing it, and was wondering if anyone else had any insight 20:34:03 <rellerreller> blpoulos what do you mean by accessing it 20:34:15 <blpoulos> getting it using just the context 20:34:25 <blpoulos> from keymgr/barbican.py 20:34:56 <blpoulos> I'd like to retrieve the service URL for barbican from keystone 20:35:26 <woodster_> does that endpoint in the service catalog have a 'v1' at the end? 20:35:49 <blpoulos> yes 20:36:24 <woodster_> it sounds like we might be able to discuss/troubleshoot this offline in the barbican IRC? 20:36:32 <blpoulos> sounds good 20:37:19 <redrobot> yeah... I was trying to dig up an etherpad we had with notes of changes that we need on barbicanclient, and related changes on keystoneclient 20:37:51 <redrobot> I think I remember a pending CR on keystone that would add the ability to get the endpoint from the session? ... not sure though 20:38:07 <redrobot> we can definitely look at this more offline. 20:39:14 <woodster_> #link https://etherpad.openstack.org/p/keystone-juno-hackathon 20:39:24 <woodster_> ...as an FYI anyway :) 20:39:33 <redrobot> thanks woodster_ 20:39:39 <redrobot> #link https://etherpad.openstack.org/p/barbicanclient-keystone-sessions-vs-auth 20:39:44 <redrobot> ^^ is the one I was thinking about 20:40:10 <woodster_> ah, got it 20:42:11 <redrobot> ok guys... that's all I had on the agenda for today. Any other topics/questions/concerns/comments? 20:43:53 <woodster_> do folks know if atiwari is on vacation? I was interested in two CRs he is working on... 20:44:08 <rm_work> I have a question about containers and naming restrictions for Secrets 20:44:15 <rm_work> if we could briefly touch on that 20:44:37 <redrobot> ok, one at a time... 20:44:42 <rm_work> heh 20:44:50 <redrobot> #topic Containers and Naming Restrictions for Secrets 20:44:54 <rm_work> (also, I missed all of the backlog for this meeting, JUST realized it was happening now) 20:44:59 <redrobot> rm_work go ahead 20:45:10 <rm_work> alright, so I'm working on python-barbicanclient right now 20:45:32 <rm_work> and I'm wondering if we have or see a need for naming restrictions on secrets... 20:45:43 <rm_work> it may impact the way I implement container support 20:45:55 <rm_work> for example, could a container have a secret named "name" or "type"? 20:46:18 <redrobot> afaik, names are arbitrary and we don't enforce any kind of validation 20:46:24 <rm_work> ok 20:46:28 <rm_work> I'll have to plan for that then 20:46:29 <redrobot> if a name is null we assign the UUID as a name 20:46:31 <rm_work> that's all I had :P 20:46:45 <rm_work> right, but if they had a *secret* named "name" 20:46:58 <rm_work> I was going to try to have all of the secrets be properties on the Container object based on their name 20:47:13 <woodster_> so the container to secret association can have a name, and the individual secrets can have names too. 20:47:21 <rm_work> but that doesn't work obviously if there could be a collision between the Container's name property and a secret named "Name" 20:47:22 <redrobot> fancy.... but totally not what the BP specified. :-P 20:47:31 <rm_work> redrobot: shhhh 20:47:50 <rm_work> I can always update the BP :P 20:48:17 <woodster_> there is a ContainerSecret association that holds the name you see in the Container API 20:48:22 <redrobot> hehe.... I'd rather keep properties on the container limited to only typed containers where we know what the secret restrictions are 20:48:30 <rm_work> I guess my first commit for that CR will probably get ripped to shreds for not necessarily following the BP to the letter… we'll see what comes of that 20:48:32 <paul_glass> Can two secrets in a container have the same name? 20:48:35 <rm_work> redrobot: right, ok so definitely those 20:49:03 <redrobot> paul_glass, generic container, yes 20:49:28 <woodster_> yep, a typed container just restricts what names you can associate to those secrets in the container 20:49:30 <rm_work> right, so this could only apply to RSAContainer / CertificateContainer 20:49:58 <rm_work> GenericContainer (or just… Container) would only be able to reference secrets by doing myContainer.secrets[secretName] 20:50:03 <woodster_> ...but the secrets themselves could have different names on them, or no names at all 20:50:09 <rm_work> err 20:50:19 <rm_work> oh, right actually I guess it'd have to be a list of Typles 20:50:21 <rm_work> couldn't be a dict 20:50:32 <rm_work> if a generic container can have multiple secrets that go by the same name 20:50:41 <rm_work> *Tuples 20:51:03 <rm_work> ok, I can talk offline / in #openstack-barbican if I have further questions about this 20:51:11 <rm_work> thanks for the clarification 20:52:13 <redrobot> I thought it *might* be cool if a container could be iterated 20:52:17 <redrobot> ie. 20:52:26 <woodster_> rm_work: Arvind is doing some work along these lines too...one of the CRs he is working on 20:52:29 <redrobot> for secret in my_container: # do stuff 20:52:46 <redrobot> but it might be more trouble than is worth 20:52:49 <rm_work> woodster_: is he doing "add containers to Python-barbicanclient"? if so, i need to coordinate with him :P 20:53:02 <woodster_> ha, not client side work 20:53:09 <rm_work> well right now you can do "for secret in my_container.secrets: #do stuff" 20:53:30 <tsv> redrobot, sorry, got delayed. Arvind is on vacation. he will be back tomorrow 20:53:30 <redrobot> rm_work ok, that's cool too 20:53:37 <rm_work> I can show you the kind of… framework I have in place right now, if you want to stop by sometime today redrobot 20:53:47 <rm_work> may or may not actually make it to submitting a CR today 20:54:18 <woodster_> tsv: thanks! 20:54:34 <redrobot> rm_work cool... I might swing by if I get some time. 20:54:45 <redrobot> ok, guys seems like we're at a good stopping point for today 20:55:18 <redrobot> thanks everyone for coming. See you all next week, or sooner on #openstack-barbican 20:56:47 <redrobot> #endmeeting