20:00:27 #startmeeting barbican 20:00:28 Meeting started Mon Jun 30 20:00: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:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:33 The meeting name has been set to 'barbican' 20:00:42 #topic Roll Call 20:01:32 Hi everyone, can I get a show of hands for this week's Barbican meeting? 20:01:42 o/ 20:01:42 o/ 20:01:44 o/ 20:02:16 o/ 20:02:32 I'll wait a couple of minutes for some more folks to jump on... 20:02:34 o/ 20:03:55 ok, let's get started 20:04:10 as usual the agenda can be found here: 20:04:13 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:04:18 #topic Action Items 20:04:51 is hockeynut here? I didn't see him raise his hand for roll call? 20:05:34 might be Austin bound? 20:05:44 maybe so... I'll update on his action item 20:06:23 so, hockeynut was working with the Pecan folks for a good approach for dealing with the default index function 20:06:38 which ended up in a change being made upstream to Peacn 20:06:41 *Pecan 20:07:04 redrobot, woodster, i saw an update on that CR by Ryan 20:07:04 we're going to need to update some stuff on Barbican 20:07:24 #link https://bugs.launchpad.net/barbican/+bug/1334872 20:07:25 Launchpad bug 1334872 in barbican "refactor barbican controllers to match pecan recommended approach" [Medium,Confirmed] 20:07:48 the bug was opened to track the changes that will need to be made once Pecan releases their change 20:08:11 tsv, is the stuff I mentioned accurate? 20:08:16 yes 20:08:28 ok, good. 20:08:36 redrobot, Ryan said he is planning on releasing pecan 0.6.0 this week 20:09:03 tsv great, we'll definitely need to keep an eye on that so we can update when it is released 20:09:22 the other action items were for me 20:09:43 and I think we'll touch on them on the agenda for today, so let's move along 20:09:53 #topic Mid-Cycle Meetup 20:10:21 So the mid-cycle meetup will be next week. If you haven't had a chance to RSVP, please do so 20:10:36 #link https://wiki.openstack.org/wiki/Barbican/JunoMeetup 20:10:53 the wiki entry has all the information, including venue, RSVP link, etc 20:11:16 also, we have an etherpad to start jotting down topics we want to cover during the meetup 20:11:26 #link https://etherpad.openstack.org/p/barbican-juno-meetup 20:11:43 any questions/comments on the upcoming meetup? 20:11:58 I have a question 20:12:16 rellerreller what's up? 20:12:24 The World Cup is going on, and I believe the semi-finals are that week. Are we doing anything for that :) 20:12:43 rellerreller hehe, we certainly could :) 20:12:48 * jvrbanac thinks "Gooaaaallllllll" 20:13:09 I may be MIA while the games are going on :) 20:13:09 rellerreller, good question :) 20:13:20 do they have big screens at the Geekdom? 20:13:24 they do 20:13:41 we should be able to stream it in 20:13:50 or there are plenty of bars downtown 20:14:02 I think we could put it up on the projectors... 20:14:55 rellerreller you and me both :D 20:15:13 make sure you guys not adding "Gooaaaallllllll" instead of for loop ;) 20:15:22 any other non-fĂștbol concerns? 20:15:29 I'm good 20:15:55 ok, looking forward to seeing everyone next week. 20:16:01 let's move on to the next topic 20:16:12 #topic Backwards Compatibility for removing tenant id 20:16:44 So I think we just need to get on the same page for this one 20:17:00 atiwari to answer your question in the agenda, I think we decided to go ahead without backwards compatibility 20:17:18 I left a comment on the BP with a -1 to remove the Backwards compatibility section 20:17:25 redrobot, it is not about tenant_id removal 20:17:31 redrobot, thanks. working on cleaning up the spec 20:17:44 atiwari oh, sorry... I must have confused myself. 20:17:49 it is about adding more type in order 20:17:58 resource 20:18:16 ah, yes.... hmm... that's a good question 20:18:37 tsv thanks! I'll vote it up and send an email to the dev list once you get a new patch up 20:18:40 so, the removal of tenant_id is interesting to me, as I'm *just* implementing the first real function on the admin-api, and I've just gotten it working *with* tenant_id 20:19:03 rm_work yes, I think it would be best if you plan on not including a tenant_id in the URI 20:19:17 can you summarize the timeline for this change/ 20:19:18 ? 20:19:38 rm_work so tsv is working on removing the tenant_ids 20:20:08 tsv after we get the blueprint approved, about how much effort do you think it would take to get a patch submitted? 20:20:12 ok, I suppose I will have to refactor based on his work then, once that gets reviewed and merged? 20:20:31 rm_work: removing the tenant-id shouldn't affect the resource work you do (within REST verb methods anyway) 20:20:45 rm_work, redrobot, am working on code changes side by side. should be ready in couple days - by Wednesday 20:20:46 #link https://review.openstack.org/#/c/100386/ 20:20:54 woodster__: well, the admin-api didn't HAVE any of this stuff yet, I had to make some stubs and such and it does relate 20:21:21 woodster__ yeah, rm_work is pretty much working on an empty app, since the admin side only has the version resource right now. 20:22:03 yeah I'll just have to look at the changes tsv makes and do the same thing on the admin side 20:22:12 that answered my question though, thanks! 20:22:48 ok, so now, let's move on then 20:22:57 #topic Backwards compatibility for order resource 20:23:36 my vote - just clean it ;) 20:23:43 redrobot, ^ 20:24:02 ok, so now to address atiwari's question about the order resource... is this something we can also use the "not in production yet" card and not worry about it? 20:24:15 atiwari that's certainly the easier route :) 20:24:22 heat has done some integration work 20:24:36 I assume they are using the orders resource 20:24:45 and the Johns Hopkins team 20:24:52 probably not orders resource though 20:25:37 jraim: I think they've only defined resource elements for the APIs, so could be changed without much issue I'd think, but should check with them 20:25:47 woodster__: seems reasonable 20:26:50 woodster__, please check and let me know. 20:26:50 atiwari do you want to check with the heat folks about the change? 20:27:10 redrobot, any specific person ? 20:27:15 to reach 20:27:42 atiwari that answers my question. :) I think that if we also send them a patch with the new order structure, it would be easier than to deal with the old format in Barbican 20:27:44 you can probably reach out to whoever put in the PRs 20:28:05 ok 20:28:15 I will check 20:28:23 https://review.openstack.org/#/c/98684/ 20:28:58 #action atiwari will check with Heat team about changes to the Orders resource. 20:29:13 jraim, redrobot I will do 20:30:00 ok, that's all we have in the agenda for today. Does anyone else have any questions/comments they'd like to bring up? 20:30:18 if not we can go back to watching the Germany game 20:30:41 I had a question about the spec regarding consuming keystone events 20:31:06 jvrbanac sorry about that 20:31:12 I had it in the Agenda and totally missed it 20:31:17 #topic Blueprint: Keysotne events 20:31:28 jvrbanac go ahead 20:31:33 #link https://review.openstack.org/#/c/99658/ 20:31:42 It seems like this blueprint/spec really needs to be split up into two different blueprints. One to address how're going to accept Keystone events, and one to deal handling and processing of events. 20:31:54 thoughts? 20:32:35 agreed....there could be different choices for *how* to handle such events, ranging from full deletion as proposed in the blueprint, to a 'softer' approach, such as marking the project as suspended 20:33:06 jvrbanac, are you thinking about a framework to consume and processing two separate BP 20:33:07 ? 20:33:49 woodster__, we are only talking about soft delete 20:34:51 atiwari, I think my primary concern is that it feels like we're trying to pack to much into the bp. In reality the method of capturing keystone events is a discrete chunk on it's own 20:35:04 likewise with the processing of events 20:35:20 jvrbanac, I am OK with two BPs 20:35:41 but can we have two separate CR to address this BP ? 20:35:46 jvrbanac, ^ 20:36:02 that way we can make it atomic 20:36:57 we can add multiple work items 20:37:30 atiwari, I think that works. I'm just trying to make sure that we can easily describe where we are going and what it takes to get there. 20:38:48 ok, so we're agreeing to keep the BP as is, but split implementation into two separate CRs 20:38:49 ? 20:38:59 great 20:39:22 I will update Arun as he is working on that part 20:39:28 redrobot, that should work. 20:39:47 ok, sounds good guys... 20:39:55 CAn I make comments about the restructure CR? 20:40:13 Really just to make folks aware of the change in the crypto flows 20:40:21 #topic Plugin restructure 20:40:25 woodster__ go ahead 20:40:44 This is the big restructure Ade, Nathan and I spoke of in Atl 20:41:10 So the framework was already laid last week, but this CR pulls the crypto stuff over: 20:41:13 #link https://review.openstack.org/#/c/103431/ 20:41:24 I'm working on a fix to the broken unit test shortly.... 20:41:43 Just wanted to make folks aware that it does change where the crypto related stuff lives 20:42:08 so we'll start to use the store_secret.py interface that Nathan put together as the 'outer' interface 20:42:28 If there are no questions about that, I'll work to fix that CR today for review 20:44:35 I think that ends this topic then, thanks! 20:45:03 alrighty 20:45:13 now, we're all out of agenda items 20:45:36 any more questions/comments? 20:47:11 ok then, that does it for this week. 20:47:41 We probably won't have an IRC meeting next week since we'll all be down at Geekdom for the mid-cycle meetup 20:47:47 thanks everyone! 20:47:51 #endmeeting