20:01:18 <redrobot> #startmeeting barbican
20:01:19 <openstack> Meeting started Mon Aug 17 20:01:18 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:22 <openstack> The meeting name has been set to 'barbican'
20:01:37 <elmiko> heyo/
20:01:41 <chellygel> ( ՞ਊ ՞)☞
20:01:44 <hockeynut> o/
20:01:47 <apmelton> o/
20:01:49 <jvrbanac> o/
20:01:50 <peter-hamilton> o/
20:01:57 <rellerreller> o/
20:01:57 <silos1> o/
20:02:02 <arunkant> o/
20:02:08 <elmiko> very nice chellygel
20:02:08 <pkazmir> o/
20:02:13 <kfarr> o/
20:02:24 <dave-mccowan> \o/
20:02:29 <chellygel> elmiko, perhaps is hould put that on my resume, no? japanese emoticon usage.
20:02:39 <elmiko> chellygel++
20:02:53 <elmiko> you have demonstrated a clear proficiency for it ;)
20:03:00 <igueths> o/
20:03:21 <redrobot> #topic Action Items from last meeting
20:03:23 <rm_work> o/
20:03:36 <redrobot> ... and I'm just going to kick the can down the road on these
20:03:43 <elmiko> hehe, fair
20:03:49 <redrobot> I am actively looking at the stable/kilo gate failures though
20:03:58 <redrobot> #action redrobot to finish prioritizing liberty-2 bugs, and also check them for kilo status
20:04:08 <redrobot> #action redrobot to fix the stable/kilo gate failures during mid-cycle (in-progress)
20:04:15 <redrobot> #action redrobot and alee to backport the DogTag gate fixes into stable/kilo after redrobot fixes the gate
20:04:30 <redrobot> also
20:04:37 <woodster_> o/
20:04:41 <redrobot> #action redrobot to submit a patch for a new python-barbicanclient release
20:04:54 <redrobot> client releases are done via Gerrit now
20:05:07 <redrobot> kfarr I'll add you to the review... I know you're waiting on that release
20:05:26 <kfarr> Thanks redrobot!  I'm curious to see what the process is, I couldn't find much online
20:05:50 <redrobot> kfarr there was a message in the dev ML about it... don't have the link handy right now, but I can get it to you after the meeting.
20:06:18 <redrobot> ok, moving on to the agenda for today
20:06:21 <redrobot> which can be found here:
20:06:22 <redrobot> #link redrobot and alee to backport the DogTag gate fixes into stable/kilo after redrobot fixes the gate
20:06:29 <redrobot> derp
20:06:37 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:06:55 <redrobot> #topic Adding certificate manager namespace to Castellan
20:07:00 <rm_work> abandoned
20:07:04 <rm_work> topic over
20:07:07 <rm_work> thanks for playing :P
20:07:39 <rm_work> (shortest Castellan discussion ever to take place)
20:07:42 <elmiko> rm_work: did this just end up not making sense, or too much resistance, or?
20:07:46 <woodster_> This rivaled content-types for bike shed supremacy!
20:07:50 <redrobot> #link https://review.openstack.org/#/c/156623/
20:08:03 <rm_work> elmiko: redrobot found the gaping flaw i missed
20:08:24 <elmiko> redrobot, rm_work, ack thanks /me reads
20:08:40 <rm_work> I'll just say I was too distracted by the random invalid arguments everyone was throwing at me :P
20:08:54 <elmiko> haha, nice
20:09:00 <rm_work> but yeah, essentially it's impossible to expose any HSM without ... Barbican or a barbican-clone
20:09:21 <rm_work> because by definition, "a service to expose a HSM" would ... BE a barbican clone
20:09:30 <elmiko> right, makes sense
20:09:30 <rm_work> and if the issue is that people can't use barbican...
20:09:32 <rm_work> we're toast
20:09:44 <rm_work> yep
20:09:56 <rm_work> donezo
20:09:58 <rm_work> finished
20:10:10 <elmiko> thanks for indulging my curiosity =)
20:10:15 <rm_work> heh
20:10:31 <redrobot> #agreed cert manager is out of scope for Castellan
20:10:47 <rm_work> redrobot: you pretty much killed CertManager *everywhere*
20:11:00 <rm_work> I'll probably go rip it out of LBaaS now >_>
20:11:03 <redrobot> yeah...  the alternative is to use Barbican directly
20:11:07 <rm_work> yep
20:11:26 <rm_work> or Castellan and take individual refs, like rellerreller was saying
20:11:46 <rm_work> which is shittier from a user perspective but it'd be the only way to be generic enough to support other use-cases
20:12:14 <rm_work> and even then, the same problem exists, which is that a user can't get data into any other service easily
20:12:39 <rm_work> which makes me wonder about Castellan in general -- i guess it's ONLY useful for M2M stuff
20:12:49 <redrobot> m2m?
20:12:53 <rm_work> anything involving an end-user and castellan is sunk
20:13:01 <rm_work> Machine to Machine
20:13:20 <redrobot> ah... yeah... or tiny clouds where users are allowed to use the key manager device
20:13:21 <rellerreller> Why can't end user use Castellan?
20:13:40 <rm_work> rellerreller: because no one in their right mind exposes an HSM directly
20:13:45 * peter-hamilton settles in
20:13:51 <rm_work> rellerreller: remember I tend to think in the "public cloud" mindset
20:13:58 <rellerreller> What about bring your own key use cases?
20:14:18 <rm_work> rellerreller: how do I store my key using Castellan unless I have credentials for the HSM?
20:14:31 <rm_work> and what cloud provider is going to give users direct credentials for an HSM
20:14:42 <rm_work> that's the point of Barbican <_<
20:14:45 <rellerreller> If you own the HSM then you would have credentials for it.
20:15:01 <rm_work> so end-users, in order to use your cloud, would have to own and operate their own HSM
20:15:12 <redrobot> rellerreller yeah.... a small cloud deployment where users have credentials for the HSM would still work.
20:15:13 <rellerreller> I can store keys with my credentials and let Neutron or whatever have read access to certain keys.
20:15:15 <rm_work> and they'd have to open up THEIR HSM to your cloud services
20:15:39 <rm_work> yeah that's not a reasonable use-case for public cloud at scale
20:15:43 <rm_work> I don't think
20:15:44 <rellerreller> Yes, that is the bring your own key model.
20:16:07 <rellerreller> silos or someone else brought this up.
20:16:19 <rm_work> i don't think any major cloud provider would ever do that
20:16:43 <rm_work> could be wrong i guess? but not a use-case we're planning for
20:16:51 <redrobot> yeah... it's interesting that Castellan gives you a non-barbican choice, but there's definitely caveats that come with non-barbican solutions.
20:17:39 <rm_work> and we're way off topic
20:17:53 <redrobot> yup
20:17:55 <redrobot> moving on
20:18:16 <redrobot> thanks for playing rm_work ... your name will always be remembered in Castellan discussions ;)
20:18:32 <redrobot> silos around?
20:18:38 <silos1> \o/
20:18:55 <redrobot> #topic Federated Barbican
20:19:00 <silos1> I created a wiki for fed barbican
20:19:03 <silos1> https://wiki.openstack.org/wiki/Barbican/Discussion-Federated-Barbican
20:19:13 <silos1> The picture is so wrong. I need to change it ASAP.
20:19:37 <redrobot> #link https://wiki.openstack.org/wiki/Barbican/Discussion-Federated-Barbican
20:19:39 <redrobot> silos1 nice!
20:19:58 <rellerreller> http://googlecloudplatform.blogspot.com/2015/07/Bring-Your-Own-Encryption-Keys-to-Google-Cloud-Platform.html
20:20:02 <redrobot> I'll ping Joe Savak on our end to pitch into that...  will definitely come in handy if our federation talk gets picked up.
20:20:16 <silos1> thanks.
20:20:31 <silos1> I was hoping we could schedule a meeting sometime to talk and get his help with this.
20:21:25 <redrobot> silos1 I have a meeting with Joe on Sept 2 to talk about Federation.  I should have more info after that.
20:21:36 <silos1> redrobot: awesome!
20:21:42 <pkazmir> (Yeah, Joe's on vacay this week)
20:21:46 <pkazmir> (slacker)
20:21:51 <silos1> haha
20:22:03 <silos1> anyone is free to comment on the wiki. The more the better.
20:23:04 <silos1> That's pretty much it for me. Just wanted to put the wiki out there.
20:23:13 <redrobot> silos1 ok sounds good
20:23:16 <redrobot> moving on
20:23:37 <redrobot> #topic Defect/issue template
20:23:44 <woodster_> silos1: API call examples would be nice to add to that wiki
20:23:58 <redrobot> hockeynut did you add this topic?
20:24:04 * silos1 writes down to add API calls
20:24:30 <hockeynut> redrobot yessir
20:24:39 <redrobot> hockeynut go ahead!
20:25:14 <hockeynut> would like to get more detail, and useful info into our launchpad issues.  Suggesting this template as a way to get there: https://etherpad.openstack.org/p/barbican-bug-report-template
20:25:28 <redrobot> #link https://etherpad.openstack.org/p/barbican-bug-report-template
20:25:48 <hockeynut> if there are other datum that folks would like to see added then certainly lets add it.
20:26:17 <pkazmir> +1 looks great
20:26:34 <pkazmir> Like how you were clear on priority and severity.
20:26:55 <hockeynut> this helps in the immediate time if the fixer <> the reporter and also helps us memorialize information about a bug so it makes sense when "future us" looks at it
20:27:31 <hockeynut> pkazmir I unabashadly stole^H^H^H^H^H borrowed it
20:27:34 <redrobot> not sure that we want to track status outside of the launchpad provided ones...
20:27:41 <woodster_> I think reporter is handled by LP automatically.
20:27:46 <pkazmir> heh
20:28:09 <redrobot> I do agree we need to get better at triaging bugs
20:28:21 <woodster_> redrobot: +1  So 'Importance' could map to your severity
20:28:31 <hockeynut> dont want to duplicate info, so certainly those don't need to be in the defect BODY.  But they do need to be considered when writing up a bug.
20:28:35 <redrobot> eg, the OpenStack way is to move bugs from New->Confirmed->Triaged and encouraging people to pick up Triaged bugs.
20:28:57 <hockeynut> is triaging a formal activity?
20:29:20 <redrobot> hockeynut it should be...
20:29:29 <redrobot> but historacally we've been really bad at it
20:29:42 <dave-mccowan> is the barbican policy for changing bug state that the PTL does that, any core, or any interested party?
20:29:48 <woodster_> FWIW: https://github.com/cloudkeep/barbican/wiki/Testing-Process
20:30:05 <woodster_> ...see the 'workflow for defects' section
20:30:12 <elmiko> hockeynut: sahara team has been triaging all day, so i'd say yes =)
20:30:19 <jvrbanac> woodster_, uh oh. not the old wiki
20:30:22 <jvrbanac> ;)
20:30:26 <redrobot> dave-mccowan permissions are granted in launchpad specific fields...  I would say anyone who is not the reporter should be able to move bugs to "Confirmed"
20:30:34 <woodster_> jvrbanac: it's still alive!!!!
20:30:42 <redrobot> launchpad specific groups even...
20:31:01 <redrobot> not sure how the permissions actually break down though...
20:31:03 <woodster_> jvrbanac: Barbican's genesis is that wiki
20:31:11 <hockeynut> sounds like we need to add some more rigor beyond just some standardized text in the bug body
20:31:38 * redrobot didn't know we had a cloudkeep page for that
20:31:40 <woodster_> hockeynut: that's for sure. Is there sphinx info on that already?
20:32:30 <hockeynut> redrobot I'd be more than happy to take a look at the process, docs, etc and give some recommendations
20:32:39 <redrobot> hockeynut sounds good to me!
20:32:53 <redrobot> #action hockeynut to review bug tracking policies and give feedback
20:33:45 <redrobot> ok, moving on to the next topic
20:33:57 <redrobot> #topic super-user rule in policy.json
20:34:01 <redrobot> dave-mccowan go ahead
20:34:16 <dave-mccowan> working on the quotas blueprint, the need for a new permissions level became apparent.
20:34:22 <redrobot> #link https://review.openstack.org/#/c/213570/
20:34:36 <dave-mccowan> now we have 3 roles: admin, creator, observer, audit... each role is scope to it's own project
20:35:04 <dave-mccowan> to set a quotas, you really want a cloud-admin (or service-admin, or super-admin) not just a project-admin to change those.
20:35:33 <dave-mccowan> in the review  linked above, i proposed one way to do this with the default policy file (no code change to barbican)
20:35:40 <pkazmir> That makes sense, I would call it a service-admin.
20:35:53 <redrobot> dave-mccowan yep...  I do believe this is the first cloud-admin type of operation
20:35:57 <redrobot> pkazmir +1 service-admin
20:36:09 <dave-mccowan> is there anyone here who is wise in the ways of oslo policy that can point us to the "right" way to do this?
20:36:46 <hockeynut> and do other projects have a similiar concept?
20:36:50 <redrobot> dave-mccowan as far as DevStack is concerned... you'll want to add a new user, and then grant the "admin" role on the "service" tenant
20:37:26 <redrobot> the oslo.policy piece would have to check that the admin role is present AND that the tenant the toke is scoped to is the "service" tenant.
20:37:29 <arunkant> dave-mccowan: I think you just need to assign that role to a pre-defined admin 'project' e.g. 'service' project.
20:37:31 <dave-mccowan> i found this in an example keystone V3 policy file:  "cloud_admin": "rule:admin_required and domain_id:admin_domain_id",
20:37:55 <dave-mccowan> i don't see a standard (oslo) way to get the service tenant id into barbican
20:37:58 <woodster_> yeah, I noticed that arunkant pointed out that this role should be associated to a special project to quality as a valid cloud admin user
20:38:18 <woodster_> arunkant: yep!
20:39:09 <arunkant> dave-mccowan: And keystone middleware provides header for project name..so it can be checked in policy
20:39:14 <redrobot> dave-mccowan http://git.openstack.org/cgit/openstack/barbican/tree/bin/keystone_data.sh#n64 should do it
20:39:17 <elmiko> a general observation about barbican policy files, we should probably prefix all these policies with "key-management:"
20:39:28 <elmiko> to allow for aggregated policy files
20:39:33 <redrobot> elmiko s/key-management/key-manager/ and I agree
20:39:50 <elmiko> yea, key-manager, whatevet the official service type is
20:39:53 <woodster_> dave-mccowan: so managing domains would be required if using that rule it seems...does keystone v2 support domains though?
20:40:27 <redrobot> dave-mccowan service tenant ID would likely be a config option
20:41:26 <redrobot> woodster_ correct, v2 keystone does not have a concept of domain.  All entities created via v2 api belong to the "default" domain in v3.  This is how keystone is able to run v2 and v3 in parallel.
20:41:30 <arunkant> woodster_, so far I have seen service policy configuration tend to avoid domain information. Uses project boundary to enforce rules.
20:41:38 <elmiko> dave-mccowan: might be worth pinging ayoung on the keystone team, he had some great suggestions about implementing policy features that can bridge the gap into the policy authorization code.
20:41:55 <dave-mccowan> redrobot... that seems kind of icky.  putting the UUID into  a config file?  tricky to build the gate job to that on the fly too.
20:42:38 <redrobot> dave-mccowan service tenant name in devstack is known to be "service" http://git.openstack.org/cgit/openstack/barbican/tree/bin/keystone_data.sh#n44
20:43:12 <dave-mccowan> redrobot can we key on tenant name only?  everything else goes by the tenant id.
20:43:23 <elmiko> i *think* there is a way to specify a function in the policy file that maps to a function in the acl code, that would allow you to control it programatically without the need for embedding special values in the config
20:43:37 <arunkant> dave-mccowan: You can use 'service' project name instead of ID and populate that as service boostrap data
20:44:00 <dave-mccowan> i'm not sure if tenant name is guaranteed to be unique.  anyone know?
20:44:20 <redrobot> dave-mccowan it is in v2.  only guaranteed unique within a domain in v3
20:45:27 <arunkant> yes, will need both service and domain name in that case.
20:45:36 <arunkant> s/service/project
20:46:01 <redrobot> would be worth pinging the keystone folks about this
20:46:07 <elmiko> +1
20:46:23 <elmiko> also, check out ayoung's talk from vancouver about dynamic policy
20:46:32 <redrobot> elmiko agreed
20:47:02 <redrobot> dynamic policy would include namespaced roles... which I looked into briefly
20:47:03 <redrobot> https://review.openstack.org/#/c/187638/
20:47:05 <dave-mccowan> redrobot +1 i'd really like to see another project that has done this to follow as an example.  no new wheel needed here.
20:47:39 <redrobot> cool, sounds like we can move on to the next topic?
20:47:48 <elmiko> redrobot: i did the namespace conversion to sahara's policy, it went pretty smoothly
20:48:20 <redrobot> elmiko I'll have to look into that and see if I can fix my patch
20:48:29 <elmiko> i'll make a comment too
20:48:53 <dave-mccowan> ok to move on
20:48:59 <redrobot> #topic quotas blueprint update
20:49:03 <redrobot> another one for dave-mccowan
20:49:07 <elmiko> hehe
20:49:38 <dave-mccowan> i wanted to point out 3 deviations from the current spec as approved.
20:50:13 <dave-mccowan> 1) the super-admin role, we just discussed.  2) the spec calls for transport-keys to be managed under a quota, but it turns out the are not project resources.
20:50:34 <dave-mccowan> the are per plugin, not per project.  so i will delete them from the spec/code/doc etc.
20:50:59 <dave-mccowan> (btw... maybe their API should also be controlled by rule:service-admin)
20:51:31 <dave-mccowan> and 3) a nit: the details of the paging for list of project-quotas was missing from the spec.
20:51:41 <redrobot> Anyone is allowed to ask for the Transport Key
20:51:49 <redrobot> haven't looked into the api recently
20:51:56 <dave-mccowan> i'll update the spec with these 3 points.  i assume all of these are ok?
20:51:57 <redrobot> but any add/edit actions need to be service-admin calls
20:52:26 <redrobot> all 3 seem reasonable to me
20:53:03 <woodster_> agreed
20:53:33 <dave-mccowan> and finally, i'd like to ask for reviews on the CRs I have out on the blueprint.  pretty please. :-)
20:53:33 <redrobot> awesome... sounds like we're done for today
20:53:47 <redrobot> with a couple of minutes to spare
20:54:07 <dave-mccowan> i'll be stuck soon, if these don't start landing.  there are four out there.  we can split them up if we need to.
20:54:23 <redrobot> dave-mccowan I'll look at them ...  soon ... :)
20:55:03 <arunkant> will appreciate if people can comment on barbican client ACL changes as well.
20:55:16 <redrobot> #topic Review Requests
20:55:30 <redrobot> ok, y'all got 5 minutes to spam the channel with CR links :)
20:56:02 <dave-mccowan> #link https://review.openstack.org/205894
20:56:24 <dave-mccowan> #link https://review.openstack.org/212876
20:56:38 <dave-mccowan> #link https://review.openstack.org/212967
20:56:46 <arunkant> As i said above, 3 linked changes for ACL on barbican client side. (1 # link https://review.openstack.org/#/c/206699/ )
20:56:56 * hockeynut is hoping that trojan to disable CTRL-V is working
20:57:01 <dave-mccowan> the first one is first priority, but is larger.  the second two are more bite-sized.
20:59:24 <redrobot> alrighty y'all, thanks for coming!
20:59:26 <redrobot> #endmeeting