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