20:00:07 <redrobot> #startmeeting barbican
20:00:07 <openstack> Meeting started Mon May  9 20:00:07 2016 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:10 <openstack> The meeting name has been set to 'barbican'
20:00:17 <redrobot> #topic Roll Call
20:00:19 <redrobot> o/
20:00:26 <diazjf1> o/
20:01:13 <kfarr> o/
20:01:44 <arunkant> o/
20:01:59 <redrobot> not a whole lot of barbicaneers here today
20:02:59 <redrobot> as usual the agenda can be found here:
20:03:11 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:03:38 <redrobot> #topic Action Items from last meeting
20:03:54 <redrobot> actually, we didn't have any action items last meeting
20:03:56 <redrobot> moving on
20:04:07 <redrobot> #topic Secret User Metadata Quota
20:04:10 <redrobot> diazjf1
20:04:22 <woodster_> o/
20:04:30 <diazjf1> redrobot, so I added a patch that sets a quota for barbican user metadata
20:05:16 <panatl> o/
20:05:20 <diazjf1> Now I was just thinking if it should just use the Project Quotas or should I make an new API for secret quotas. I'm thinking just to configure projects quotas
20:05:23 <diazjf1> See https://review.openstack.org/#/c/313788/5/barbican/common/quota.py
20:05:46 <diazjf1> I would need to change QuotaDriver and the Quota controller
20:06:06 <diazjf1> but the enforce is working based on config values
20:06:22 <diazjf1> just need the API to work and was planning on doing that in a dependant patch
20:06:27 <diazjf1> dependent*
20:06:28 <redrobot> diazjf1 so the question is if you should add a new quota value on the per-project quotas?  Like metadata_quota or something?
20:06:51 <dave-mccowan> o/
20:07:11 <diazjf1> redrobot, add a secret-based quota using the project-based quota model
20:07:15 <diazjf1> just configuring it
20:07:44 <redrobot> diazjf1 why do we need a per-secret quota?
20:07:57 <diazjf1> for the secret metadata
20:08:39 <alee> o/
20:08:42 <diazjf1> redrobot, we decided a few weeks ago that secretmetadata should be quoted by secret
20:08:46 <maxabidi> o/
20:09:12 <redrobot> diazjf1 well, I think we need to have a quota for sure, but I don't think we need a new api ?
20:09:34 <diazjf1> redrobot, so what I will do then in update the QuotaDriver
20:09:59 <redrobot> would it work if we just added a new quota type to the existing quotas api?
20:10:25 <diazjf1> redrobot thats what I was thinking
20:10:25 <redrobot> ie, now we have secrets, orders, containers, consumers, cas. as the different types
20:10:38 <redrobot> I think it would be similar to how we're handling the consumers quota
20:11:35 <diazjf1> redrobot see https://review.openstack.org/#/c/313788/5/barbican/common/quota.py
20:12:20 <diazjf1> I'm thinking change "set_project_quotas", "get_project_quotas", etc. to allow for secrets as well
20:12:40 <redrobot> diazjf1 yeah, something like that
20:12:53 * redrobot needs to catch up on upstream reviews
20:13:12 <diazjf1> right now https://review.openstack.org/#/c/313788/5 is ready for review, I will make a dependent patch adjusting the API
20:13:15 <redrobot> diazjf1 I still don't understand why we need a new api?
20:13:35 <diazjf1> redrobot, I wont do a new API was just wondering on your thoughts
20:13:48 <diazjf1> since Secret-based is different than Project-based
20:14:17 <redrobot> diazjf1 I say look into whatever the consumers is doing, since consumers are applied at the per-container level
20:14:56 <diazjf1> redrobot, awesome thanks:). I didn't realize that.
20:15:40 <redrobot> diazjf1 cool
20:15:54 <redrobot> #topic Blueprint: Deployer Secret Metadata
20:15:55 <redrobot> diazjf1 also yours?
20:16:02 <redrobot> #link https://review.openstack.org/#/c/301310/
20:16:18 <diazjf1> redrobot, yup its ready to review and merge :)
20:16:29 <redrobot> diazjf1 looks like it's already got 2x +2
20:16:50 * redrobot merges it based on +2s
20:16:55 <diazjf1> redrobot, yup waiting on the +A before I work on it
20:17:15 <redrobot> diazjf1 done
20:17:22 <diazjf1> redrobot, perfecto
20:17:38 <redrobot> ok, moving on
20:17:48 <redrobot> #topic Blueprint:  HSM fail-safe
20:18:13 <redrobot> diazjf1 has a monopoly on topics today ;)
20:18:21 <diazjf1> redrobot, also me. Sorry to hog all the meeting time :/
20:18:36 <redrobot> diazjf1 no worries, nobody else added topics
20:18:49 <diazjf1> redrobot, haha
20:19:23 <diazjf1> So my plan is to rewrite the blueprints so that we have 1) for HSM retry and and 2.) Pool of failsafe HSMs
20:19:30 <diazjf1> my plan is to just to HSM retry
20:19:51 <diazjf1> and leave failsafe for O in case HA mode doesn't get better performance
20:19:57 <diazjf1> just wanted everyones thoughts
20:20:02 <redrobot> diazjf1 sounds good to me
20:20:13 <diazjf1> redrobot, awesome
20:20:37 <redrobot> diazjf1 just fyi jmckind (John McKenzie) is working on some changes to the pkcs#11 plugin so it can restart the connection when the client times out
20:21:04 <redrobot> I think he's close to pushing those changes... just keep an eye out so you can rebase on top of his stuff
20:21:18 <arunkant> diazjf1 : Is this HSM retry expected to be plugin agnostic or will be applicable to pkcs11 and/or kmip ?
20:21:41 <redrobot> arunkant seems like something that is implementation specific for each plugin
20:22:02 <diazjf1> redrobot, great news. arunkant, I was thinking just PKCS-11
20:22:32 <diazjf1> jmckind, if you have any time to chat this week lmk
20:22:38 <arunkant> diazjf1 : Okay...
20:24:08 <diazjf1> redrobot, seems like jmckind is on the right track. I may not need a new spec depending on his change. I'll make sure to talk to him next time I see him online
20:24:27 <redrobot> diazjf1 cool
20:25:09 <redrobot> #topic Blueprint Reviews
20:25:12 <redrobot> #link https://review.openstack.org/#/q/project:openstack/barbican-specs+status:open
20:25:19 <redrobot> we still have a few other blueprints in review
20:25:40 <redrobot> arunkant I'm halfway through reviewing the multiple backend bp... I should be done today or tomorrow
20:26:15 <redrobot> I updated the generic container blueprint as discussed during the summit
20:26:16 <arunkant> redrobot: okay..will look forward to your comments..
20:26:18 <redrobot> #link https://review.openstack.org/#/c/286318/
20:27:50 <redrobot> any questions/comments regarding the blueprints in review?
20:28:48 <diazjf1> redrobot, I'll review the container-put one. Just want to know who the assignee's will be since its TBD
20:29:29 <redrobot> diazjf1 I'll probably end up working on it ... there's been a WIP patch for a long time for this feature
20:29:53 <diazjf1> redrobot, awesome, alright I'll take a closer look at it tonight
20:30:47 <redrobot> diazjf1 https://review.openstack.org/#/c/207249/ ... but it will need to be rewritten for the updated spec
20:31:36 <diazjf1> redrobot cool. I'll keep both in mind when I'm reviewing
20:31:48 <jmckind> o/
20:32:02 <diazjf1> jmckind, just the person I wanted to see
20:32:26 <jmckind> yessir!
20:32:28 <diazjf1> jmckind, wanted to know about the PKCS-11 patch for retrying a session
20:33:01 <jmckind> I am doing the last bit of testing on it in our environment toddauy
20:33:19 <jmckind> I feel like I should have it up this week
20:34:16 <redrobot> awesome
20:34:40 <redrobot> that's all we have on the agenda for today
20:34:42 <diazjf1> jmckind, cool add me as a reviewer when its up. I'd be happy to test it out
20:34:45 <redrobot> #topic Open Discussion
20:34:57 <redrobot> anything else we should talk about today?
20:35:42 <jmckind> diazjf1, will do...
20:36:12 <redrobot> going once ...
20:36:18 <alee> redrobot, have you set up those docs?
20:36:25 <redrobot> alee I have not :(
20:36:36 <redrobot> alee I'll try to get it done this week
20:36:50 <redrobot> #action redrobot to work on install doc skeleton
20:36:52 <alee> redrobot, ok - I'm waiting on that to add centos/rhel specific instructions
20:42:48 <redrobot> alrighty y'all
20:42:55 <redrobot> looks like we get 20 min of our Monday back
20:42:59 <redrobot> thanks for coming, everyone!
20:43:01 <redrobot> #endmeeting