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