19:59:58 <redrobot> #startmeeting barbican
19:59:59 <openstack> Meeting started Mon Jul 14 19:59:58 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:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:03 <openstack> The meeting name has been set to 'barbican'
20:00:13 <redrobot> #topic Roll Call
20:00:25 <redrobot> hi everyone,
20:00:31 <rellerreller> hello
20:00:34 <redrobot> can I get a show of hands for the Barbican weekly meeting?
20:00:39 <atiwari> o/
20:00:45 <jraim> o/
20:00:47 <rellerreller> o/
20:01:23 <blpoulos> o/
20:01:38 <redrobot> I see a few more people who are probably here for barbican...  paul_glass I'm looking at you.
20:01:49 <paul_glass> o/
20:02:41 <redrobot> as usual the meeting agenda is available here: https://wiki.openstack.org/wiki/Meetings/Barbican
20:03:07 <hockeynu_> o/
20:03:18 <jvrbanac> o/
20:03:46 <kaitlin-farr> o/
20:04:10 <redrobot> Ok, cool, looks like there's plenty of us here.
20:04:20 <redrobot> #topic barbican-core nominations
20:05:03 <redrobot> First up in the agenda, in case you missed it, I nominated Ade Lee and Nate Reller ( rellerreller ) for barbican-cre
20:05:09 <redrobot> *barbican-core
20:05:36 <redrobot> I checked this morning and they've both gotten 6x +1 votes from the rest of the team
20:06:04 <redrobot> since there were no negative votes, and we're on day 5 I think we're good to add them to the team
20:06:07 <atiwari> redrobot, great nomination +1 from me too
20:06:09 <redrobot> which I will do shortly
20:06:28 <redrobot> #action redrobot will add alee and rellerreller to barbican-core
20:07:03 <redrobot> with great power comes great responsibility, so please be sure to take time to review patches as they come in :)
20:07:08 <hockeynu_> congrats 2 u both
20:07:17 <rellerreller> Thank you! :)
20:07:20 <atiwari> rellerreller, alee congratulations
20:07:36 <bubbva> o/
20:07:43 <redrobot> bubbva yes?
20:07:50 <bubbva> yes, late, but here :-)
20:08:03 <redrobot> bubbva oh, ok. :)  I thought you had a question
20:08:26 <redrobot> ok, moving on to the next topic
20:08:39 <redrobot> #topic Better planning for large patches
20:08:47 <redrobot> #link https://review.openstack.org/#/c/103431
20:09:14 <redrobot> I think that in general we do want to strive for smaller patches
20:09:43 * jvrbanac agrees!
20:10:00 <redrobot> For this change in particular, the tradeoff was to either do one large patch, or small patches that would break HEAD
20:10:01 <atiwari> redrobot, yes that topic was added by me and I appreciate if we make better planning for such changes
20:10:11 <atiwari> seems we did hurry on this one
20:10:17 <redrobot> atiwari what do you mean by better planning?
20:10:35 <redrobot> I think we did a good job of planning for the refactor during the Atlanta summit
20:10:50 <atiwari> smaller change
20:10:55 <hockeynu_> maybe as part of a bp we could add a section for "phase-in" where we discuss how to break up implementation into smaller units
20:11:13 <atiwari> redrobot, in deed you guys did good job
20:11:15 <atiwari> :)
20:11:35 <atiwari> hockeynu_, +1
20:11:41 <redrobot> atiwari I just want to make sure we address your concern, if you think that planning was not adequate.
20:12:03 <atiwari> yes, we should have plan for smaller change
20:12:25 <redrobot> atiwari ok, so your concern is just smaller changes in general?
20:12:31 <atiwari> due to this one I think I need to start CR 87405 almost from scratch
20:13:09 <atiwari> redrobot, and better understanding for the change
20:13:36 <redrobot> atiwari yeah, this was a major change.   I'm hopeful that the number of fundamental framework changes will be minimal.
20:13:45 <atiwari> seems with this one Secret store BP is not well documented and seems it is implemented in this CR
20:14:22 <redrobot> I think this change pre-dates the specs repo
20:14:40 <redrobot> I think that moving forward we'll have less issues with big changes like this thanks to the specs repo
20:15:39 <atiwari> redrobot, there was not enough time give to review this change. Seems there was some hurry
20:15:48 <atiwari> just mu opinion
20:15:52 <atiwari> my
20:16:15 <redrobot> June 29 - July 8 is when the patch was in review... do you think that was not enough time?
20:16:31 <atiwari> it wd be great if we make smaller change, specially if that change is affecting everyone
20:17:02 <atiwari> based on the size, I think not
20:17:18 <atiwari> anyway lets not worry about this
20:17:58 <redrobot> Actually, we did have a SPEC for this
20:18:00 <redrobot> #link https://review.openstack.org/#/c/98286/
20:18:10 <redrobot> June 5 is when the SPEC was first proposed
20:18:45 <atiwari> this core reorg spec
20:19:04 <atiwari> I think for secret store there is no detailed specs
20:19:20 <atiwari> hope I am not missing something
20:19:45 <redrobot> atiwari SecretStore is part of the spec I linked above
20:20:13 <redrobot> atiwari but I do agree we need better documentation around that
20:20:39 <redrobot> I have it on my TODO list to write a detailed guide for using SecretStore plugins, so stay tuned :)
20:20:52 <atiwari> redrobot, thanks
20:21:11 <redrobot> any more questions/comments about CR sizes?
20:21:57 <redrobot> #agreed we want to strive for smaller patch sets, especially when they affect a lot of concurrent work
20:22:01 <atiwari> redrobot, I wd prefer smaller change targeting to just one BP
20:22:18 <redrobot> atiwari I think this change did target just the one BP
20:22:56 <atiwari> redrobot, OK
20:23:09 <redrobot> ok then, moving on
20:23:35 <redrobot> #topic python-barbicanclient release schedule
20:23:48 <rellerreller> I added this one
20:23:52 <rellerreller> We are creating a Barbican plugin in Nova to retrieve the keys for disk encryption from Barbican
20:24:03 <rellerreller> We put in CR to add python-barbicanclient to global requirements, https://review.openstack.org/#/c/106411/
20:24:16 <rellerreller> +1 ^ would help :)
20:24:28 <rellerreller> Our issue is that requirements pull the latest release of python-barbicanclient, and the latest release has a bug in it. The log for error is here, http://logs.openstack.org/01/104001/4/check/gate-nova-pep8/fdeaf4d/console.html.gz
20:24:45 <rellerreller> The latest code in master does not have the error but has not been released. We need a new release to finish our integration.
20:25:14 <rellerreller> So the question is when is the next release?
20:25:20 <redrobot> Yeah...  the client needs a lot of TLC.
20:25:42 <redrobot> So we do have a lot of work in the pipeline for the client... but I think a lot of it is going to require a  3.x.x release
20:25:55 <rellerreller> Do you think there can be another release before code freeze? If not then our unit tests will not pass, and we will not be able to integrate with Nova.
20:26:18 <jraim> the clients aren't released on the same schedule
20:26:24 <jraim> we can release it anytime we want
20:26:36 <redrobot> I'm ok with releasing a new 2.x, but keep in mind there may be some breaking changes for 3.x
20:26:46 <rellerreller> A new release would help us at least get something into Nova
20:27:28 <rellerreller> We should not need much functionality, probably just create and retrieve key and delete
20:27:32 <redrobot> does anyone have any issues with releasing a new 2.x barbicanclient ahead of the Keystone sessions refactor?
20:27:39 <jraim> I'm okay with it
20:28:04 <atiwari> redrobot, tsv is pushing a change for tenant_id removal from api
20:28:42 <atiwari> which is on review, once that will be merged we have to immediately release one
20:29:02 <atiwari> wondering if it is good to wait for that cr?
20:29:07 <redrobot> atiwari I don't think we need to release clients immediately after merge, but it would be good to release alongside milestones
20:29:34 <atiwari> ok
20:29:51 <redrobot> atiwari would you be ok with a release now to unblock rellerreller and then another release once tsv's work is merged and released on a milestone?
20:30:09 <atiwari> redrobot, yes
20:30:25 <redrobot> ok, let's plan for that then.
20:30:40 <redrobot> #action redrobot will make a new barbicanclient 2.x release
20:30:47 <rellerreller> Excellent!
20:31:16 <redrobot> rellerreller does current HEAD work for you?
20:31:31 <rellerreller> blpoulos, can you answer that?
20:31:40 <blpoulos> yes, it does
20:32:44 <redrobot> ok, good, I'll try to get that released today.
20:32:52 <blpoulos> wonderful, thank you
20:33:34 <redrobot> ok, guys that's it for our agenda today.  Does anyone have any other issues/questions they'd like to bring up right now?
20:34:15 <atiwari> yes I have some basic question regarding secret store plugin
20:34:25 <redrobot> #topic SecretStore
20:34:30 <redrobot> atiwari go ahead
20:34:40 <atiwari> ok
20:35:19 <atiwari> I have to store my secret in Barbican system, same way it is stored with crypto plugin
20:35:39 <atiwari> I am suppose to write separate secret store plugin ?
20:35:54 <atiwari> like StoreCryptoAdapterPlugin?
20:36:40 <redrobot> atiwari not necessarily, unless StoreCryptoAdapterPlugin does not work for you
20:37:18 <redrobot> the idea is that StoreCryptoAdapterPlugin is a generic way to store secrets in the Barbican db
20:37:29 <atiwari> as I mentioned I have a req to store one (or more) master KEK in HSM to encrypt the KEK
20:37:57 <redrobot> that implementation of SecretStore uses a CryptoPlugin.  so it's a sort of plugin-within-plugin
20:38:20 <atiwari> yes
20:38:46 <redrobot> we at Rackspace are planning on using a CryptoPlugin that talks to an HSM via PKCS11... reaperhulk is currently exploring tiered keys to deal with the HSM storage limit, but I'm not sure what his progress is
20:39:19 <atiwari> ok
20:39:42 <redrobot> it sounds to me like your use case is similar to ours
20:39:51 <atiwari> I think so
20:40:13 <redrobot> but if the PKCS11 plugin we're using does not work with the HSM you may need to write your own CryptoPlugin
20:40:29 <atiwari> sure
20:40:35 <atiwari> redrobot, jraim  another question around CryptoPlugin
20:40:39 <redrobot> but it sounds like you may be able to reuse the StoreCryptoAdapterPlugin
20:41:00 <atiwari> StoreCryptoAdapterPlugin >> MyNewPlugin ?
20:41:53 <redrobot> I'm not sure I undestand the question?  >> ?
20:42:00 <atiwari> 
20:42:03 <atiwari> sorry
20:42:40 <atiwari> I will write my new CryptoPlugin (MyNewPlugin) which will be called from StoreCryptoAdapterPlugin
20:42:54 <atiwari> correct
20:43:08 <redrobot> yes, that may be a good approach for you if StoreCryptoAdapterPlugin does work for your storage needs.
20:43:17 <atiwari> ok
20:44:34 <redrobot> any more questions/comments about this or any other topic?
20:45:12 <atiwari> redrobot, one last from me :)
20:45:18 <redrobot> ok
20:45:24 <atiwari> may I ask what is holding https://review.openstack.org/#/c/104599/?
20:46:57 <redrobot> atiwari looks like it's just a case of the Mondays...  I know the team here has been in meetings all day.
20:47:11 <atiwari> np
20:47:36 <atiwari> I was blocked due to this one. that is why raised
20:47:54 <redrobot> ok, I'll see if I can poke some people to go look at it
20:48:03 <atiwari> thanks
20:49:11 <redrobot> ok guys, looks like we may be able to call it a day a bit early today
20:50:21 <redrobot> see y'all back here next week.
20:50:29 <redrobot> #endmeeting