20:02:56 #startmeeting barbican 20:02:57 Meeting started Mon Sep 8 20:02:56 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:00 The meeting name has been set to 'barbican' 20:03:24 back to back meetings... gotta love mondays :) 20:03:51 As usual the agenda can be found here: 20:03:54 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:04:34 hi! o/ 20:04:38 #topic Roll Call 20:04:41 \( ^___^ )/ 20:04:44 hi bubbva! 20:04:47 o/ 20:04:50 o/ 20:04:51 \o 20:04:51 o-- 20:05:01 oops, was premature o/ 20:05:02 \\o o// 20:05:05 o/ 20:05:13 o/ 20:05:14 reaperhulk: I'm pretty sure it's not supposed to do that 20:05:14 o/ 20:05:15 o/ 20:05:18 reaperhulk: you should see a doctor 20:05:27 Maybe I'm Goro 20:05:37 you mean Groot? 20:05:39 reaperhulk Goro only had one head :-P 20:05:59 Some MK aficionados here 20:06:16 Lol 20:06:29 ok, looks like we got the whole crew here 20:06:40 much better than just jvrbanac SheenaG1 and I last week. :) 20:06:51 o/ 20:06:53 :D 20:07:03 we have lots of stuff on the agenda today, so let's get started 20:07:06 o/ 20:07:09 #topic Kilo Design Sessions 20:07:52 do we have an etherpad somewhere with suggested design sessions? 20:07:55 So, with the Kilo summit just under two months away, we should start thinking about what our design sessions should be 20:08:07 alee not yet, but that's an excellent idea 20:08:13 let me make one real quick 20:08:35 #link https://etherpad.openstack.org/p/barbican-kilo-design-sessions 20:09:01 redrobot, there is also the usual website where folks suggest design sessions .. not sure if thats up yet .. 20:09:20 in case anyone misses the etherpad 20:09:26 alee there was a huge discussion about changing the format for the design sessions in the openstack-dev list 20:09:36 but I still haven't read the whole thing 20:09:42 alee, not up yet 20:10:05 atiwari, thanks - ok etherpad for now then prhaps. 20:10:11 oops, almost missed this o/ 20:10:48 yes, let's collaborate on the etherpad 20:11:07 One thing I'd like to see for the summit is a review of the plugin architecture 20:11:27 What was the subject line for the discussion on etherpad? I have been too busy to read the mailing list lately. 20:11:48 rellerreller possible design sessions for the Kilo summit 20:12:15 I'd also like to talk about 3rd party testing during the Kilo summit 20:12:17 redrobot thanks! 20:13:14 I'll make a note to revisit the etherpad for next week's meeting 20:13:29 redrobot, perhaps you can add the etherpad link to the wiki - seeing as its something that we're going to use for a little while 20:13:31 in the meantime, we can start putting ideas there 20:14:23 alee sounds good, I'll add it to the main Barbican wiki page 20:14:46 #action redrobot to add Kilo Design Sessions etherpad to wiki 20:15:02 it'll be good to revisit the wiki page 20:15:31 anything else we want to talk about for kilo design sessions? or is everyone good with etherpading until next week? 20:15:51 how much time or how many slots do we have? 20:16:08 We should have at least 3 but redrobot may know more :) 20:16:11 rellerreller that's a good question... I need to catch up on the design summit thread on poenstack-dev 20:16:29 Last I saw, we were only going to get two slots on the first day :-\ 20:16:43 #action redrobot to figure out how many slots we'll be having 20:16:53 Is the design summit first and then the user session? 20:17:08 I think design summit is Tuesday-Friday 20:17:27 rellerreller, even if we don't have enough slots - the remainder could form the basis of discussions in the informal designs sessions .. 20:17:41 I assume we're going to get a table like the last time, right? 20:18:08 alee yes, I would think so 20:18:23 the table was definitely helpful last summit 20:18:44 rellerreller https://www.openstack.org/summit/openstack-paris-summit-2014/format-and-passes/ 20:18:44 redrobot, ok - can we "table" till next week then? 20:18:55 alee lol, sure 20:18:57 moving on 20:19:22 #topic Juno Roadmap Discussions 20:19:43 who added this topic? For some reason I didn't get any emails about wiki edits today 20:20:01 #link https://etherpad.openstack.org/p/barbican-juno-final-roadmap 20:20:12 my guess is woodster_ 20:20:13 that was me 20:20:28 just an attempt to fine tune what we wanted to get in for Juno release 20:20:55 ...but if we just have to Sept 25 to be in release candidate mode, might really need to chop that list down 20:21:29 well - thats the question then -- when is our deadline? 20:21:52 #link https://wiki.openstack.org/wiki/Juno_Release_Schedule 20:22:01 J3 was released last week 20:22:13 so Barbican is now considered "feature complete" for Juno 20:22:19 or should be anyway 20:22:42 there were two blueprints that were pushed to milestone one 20:22:46 err RC1 20:22:53 which should be out on Sept 25th 20:23:00 Does anyone know if we can make a Kilo branch to hold Kilo-facing work before the final Juno release in October? 20:23:11 redrobot, right - so what does "release Candidates" mean? code freeze except for absolute exceptions? 20:23:46 alee Yes, I would think we want to code freeze, except for bugfixes 20:24:08 I thought you could only get in code now if you filed a Feature Freeze Exception. 20:24:10 basically RC1 should have all the functionality we need, so we can iterate on polish for the remainder RCs 20:24:23 rellerreller new feature code, yes 20:24:23 redrobot, wondering why https://blueprints.launchpad.net/barbican/+spec/api-orders-add-more-types was not part of J3? 20:24:55 atiwari because you said there was one more CR that was needed. Since your CR did not merge for the deadline I had to push it back to RC1 20:25:24 RC1 will be part of J3? 20:25:37 atiwari no, J3 was Juno release Milestone 3 20:25:38 It will be part of Juno final. Juno 3 is already released. 20:25:51 atiwari RC1 is Juno release candidate 1 20:25:58 ok 20:26:31 woodster_, redrobot, rellerreller - the definitions are still a little fuzzy to me. Looking at https://etherpad.openstack.org/p/barbican-juno-final-roadmap, is there anything that should not be in there for juno-final? 20:27:07 I think we want it all to be in juno final 20:27:21 of course we do :) 20:27:26 I think woodster_ is concerned that it may be too ambitious, and we'll have some half baked stuff 20:27:31 Well, there are a lot of '?' items in there...work not yet started 20:28:03 if that has to be code complete by Sept 25th, I think that will be difficult. 20:28:13 woodster_, right - so it might be a good idea to assign/ prioritize 20:28:56 Python client is not strictly tied to Juno release dates, although we do want to realease pretty soon after juno-final 20:29:08 so I would consider Client work low priority 20:29:28 (which explains the state the client was in before rm_work started working on it ;) 20:29:35 redrobot, good to know - that will help 20:29:43 redrobot: T_T 20:30:01 you're not *wrong*... :P 20:30:05 woodster_, I'd like to see the items with ** first to unblock dogtag work .. 20:30:20 woodster_, they'll also affect symantec and kmip 20:31:43 I'd like to have the certificate related tasks done by then, at least demoable (ok, thinking of that barbican plugin talk in Paris. :) But 3-d and 5-b of the unstarted work is probably higher priority 20:32:34 4-d would be nice as well :) 20:33:13 woodster_, I'm ok with that -- 3-d, 5-b and 2-a 20:33:34 5-b sounds ambitious. We do not even have a design for that yet. 20:33:36 woodster_, 4-d is nice, but seems like an ongoing goal 20:34:25 rellerreller, maybe - but I think that could be reduced for this release to simply taking out the checks we dont want. 20:34:25 rellerreller: 5-b should just be calling the supports() method during the API validators phase 20:34:37 alee: agreed 20:34:56 woodster_, rellerreller - ie. the checks to make sure we're only generating AES .. 20:35:07 the code already calls the supports() method 20:35:42 woodster_, calling supports() while API validation ? 20:35:42 woodster_ alee you mean just adding another supports_* method? 20:35:55 alee: not for validation though...just returns true/false. Needs to (eventually) raise exception saying what is invalid so we can report it back to the client 20:36:40 that's the combined supports() method that we discussed in this eitherpad: 20:36:42 #link https://etherpad.openstack.org/p/barbican-validation-options 20:36:48 Another supports method that simply returns a boolean sounds doable. 20:37:42 The decision in that etherpad was to leave the single supports() method for now, rather than have a separate method for validation. 20:38:06 ...so that method would be called as part of the validation phase. 20:38:20 That sounds good to me. I think the type of validation we eventually want should be discussed more. 20:38:21 I agree with alee thought that this is ambitious for Juno 20:38:31 ...so maybe a Kilo design session? 20:38:44 yup - add to etherpad :) 20:39:03 ...and for now just remove gating checks as alee suggests? 20:39:06 +1 20:39:43 My +1 was for adding design summit talk on validation. I don't know about the gating suggestion. 20:39:47 alee: adding as we speak :) 20:40:30 rellerreller: so there is hardcoded logic that restricts the secrets (from orders) that can be generated 20:40:37 rellerreller, +1 from me, I have to break the validators per controller 20:41:08 rellerreller: so we'd remove that logic. But if things bomb out, that will be on the asynch side, so the orders record will have the error info 20:42:18 woodster_, it shouldn't be too hard to iterate through the plugins and call supports() 20:42:38 alee: on the API side? 20:42:42 yeah 20:43:31 might as tell the client ahead of time if no plugins will support their request .. 20:43:37 it does tweak the supports() contract a little...to raise exceptions if the plugin can handle the input data, *and* that data is invalid 20:44:09 well, we could note plugin validation as a stretch Juno goal then? 20:44:31 at this point I'd be more comfortable calling it a Kilo feature 20:45:03 even if it's easy, it seems we have higher priority stuff to worry about 20:45:16 sounds good to me 20:45:30 woodster_, what benefit we are getting with eager supports() call on plugin ? 20:46:11 atiwari, the client finds out ahead of time whether there are any plugins that support his request. 20:46:39 instead of seeing an error later 20:46:52 after the async process goes through 20:47:03 alee, why not adding some kind of discovery mechanism ? 20:47:35 ok - I think I'm coming around to the idea that this is a kilo feature 20:47:46 lots of possible ideas 20:47:50 +1 20:48:04 do we want to remove the gating checks? 20:48:08 for juno? 20:48:56 I'd say yes 20:49:00 (the benefit is that if someone wants something other than an AES key - and they have dogtag or kmip behind it - they can get it 20:49:02 +1 20:49:10 I've added that as an option to the juno3-roadmap eitherpad 20:49:25 any dissenters though? 20:50:12 going once .. 20:50:28 sold! 20:50:32 btw, I'm highlighting lines in that eitherpad in bold that are must haves for Juno final, italics that are would-be-nices 20:51:03 we have about 10 min left in this room 20:51:13 woodster_, can we have a name behind some of these? 20:51:18 woodster_: BTW going back a bit, 1-d is part of the CR in 1-a 20:52:02 rm_work: oh sorry, updating.... 20:52:12 rm_work I think client work all needs to happen, but we don't have the same deadlines as barbican proper 20:52:23 all of 1) is low priority for me 20:52:31 redrobot: right, just saying it's not separate :P 20:52:59 well, I do think having sync to the server features for the client by Juno final is important for folks wishing to integrate with Barbican 20:53:43 ...so I think we are saying Oct 16 is our drop dead date, but should have stable release before that I'd expect? 20:54:30 woodster_ I would hope that our stable release is RC1 20:54:45 we'll be in pretty bad shape if it's not 20:54:49 redrobot: it's good to be optimistic :) 20:55:06 woodster_, well lets try to get most of the server stuff in by RC1 20:55:09 rm_work Positivity is my #1 strength :-P 20:55:10 RC1 == Sept 25th? 20:55:25 5 minutes left 20:55:37 so, to summarize, we want to focus on (**) items first 20:55:42 then bold items 20:55:44 Sept 25th < 2 weeks away? Avg CR review time is ~ 2 weeks :P 20:55:48 then the client 20:56:33 woodster_, most of these are smaller changes -- review time should be a lot shorter 20:57:02 challenge accepted :) 20:58:02 woodster_, can we get names next to all the bold items at least? ie. the ones without a CR. 20:58:28 given that we dont have a lot of time - we dont want something to fall through the cracks 20:59:14 redrobot, for RC1 do you have compiled list of items? 21:00:25 atiwari Not sure I understand your question. We're out of time here though. Let's jump over to #openstack-barbican 21:00:33 ok 21:00:43 thanks everyone, we'll revisit the pending agenda items next week 21:00:45 #endmeeting