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