20:01:31 <redrobot> #startmeeting barbican
20:01:32 <openstack> Meeting started Mon Aug 18 20:01:31 2014 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:35 <openstack> The meeting name has been set to 'barbican'
20:02:14 <redrobot> Hi everyone, welcome to the Barbican weekly meeting
20:02:24 <redrobot> as usual the agenda can be found here:
20:02:25 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:02:29 <redrobot> #topic Roll Call
20:02:33 <woodster_> o/
20:02:34 <jvrbanac> \o_
20:02:36 <rellerreller> o/
20:02:36 <chellygel> \o/ _o_ \o/ _o_
20:02:42 <SheenaG1> o/
20:03:10 <lisaclark1> o/
20:03:23 <redrobot> I wonder if alee is here?
20:03:32 <alee> o/
20:03:42 <redrobot> woohoo!
20:03:46 <rm_work> o/
20:03:50 <redrobot> lots of barbicanneeers
20:04:05 <redrobot> ok, let's get the meeting started.
20:04:12 <redrobot> #topic Juno Home Stretch
20:04:30 <redrobot> woodster_ I saw your email to the dev list earlier and saved this spot to talk abou tit
20:04:44 <woodster_> rellerreller actually got the ball rolling there
20:04:58 <woodster_> basically what we are planning to get ready for M3
20:05:35 <woodster_> Seems like secret-store features are in good shape (KMIP, Dogtag, HSM)
20:05:37 <redrobot> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/043360.html
20:05:55 <alee> M3 deadline is September 4th, right?
20:06:03 <alee> or is it sometime before then?
20:06:17 <rellerreller> I think September 4
20:06:22 <jvrbanac> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
20:06:27 <redrobot> alee correct, Sept 4 is Juno-3 release
20:06:43 <redrobot> jvrbanac thanks!
20:06:58 <redrobot> Also, Sept 4 is feature code freeze
20:07:06 <redrobot> and String freeze
20:07:12 <redrobot> basically, a very cold day :)
20:07:13 <woodster_> I believe that applies to the openstack/barbican repo
20:07:18 <rm_work> brrrrrr
20:07:37 <rm_work> yeah, that doesn't apply to python-barbicanclient, right?
20:07:45 <woodster_> openstack/python-barbicanclient is still slushy on that date,and can be modified
20:07:50 <rm_work> kk thanks
20:08:00 <woodster_> we think so
20:08:09 <redrobot> rm_work correct, the release scheduled that jvrbanac linked above applies only to the Service API
20:08:28 <alee> what are the deadlines on the client side?
20:08:32 <woodster_> rm_work: but still get that stuff done by sept 4th just in case :)
20:08:33 <redrobot> python-barbicanclient does not have a release schedule.
20:08:39 <rm_work> woodster_: aye aye cap'n
20:08:48 <redrobot> alee we can release python-barbicanclient on demand
20:09:25 <woodster_> I think it would be good to have the client synced with the service before the final release of course
20:09:27 <alee> redrobot, thats good - because its highly unlikely that I will even really start the key wrapping features in barbican client by the 4th.
20:09:49 <alee> but betwen then and release may be doable.
20:10:11 <alee> 5 weeks -- quite doable in fact
20:12:27 <redrobot> Ok, so any questions/comments regarding woodster_'s email?
20:12:33 <redrobot> I think he put a good summary together
20:13:09 <rellerreller> I thought it was a good summary and thought it was good to post
20:13:18 <alee> woodster_, so I'm ok with pushing out some of the cert stuff ..
20:13:28 <woodster_> alee: nice!
20:13:42 <alee> that is - pushing out the advertising of what ca's are available.
20:14:02 <alee> and the addition of an interface for sub ca's
20:14:11 <redrobot> Feature Proposal Freeze is this Thursday, so if there are any yet-unsubmitted-blueprints, now would be the time to submit those.
20:14:12 <woodster_> I'm working on a CR to have some of the certificate event modules for consideration
20:14:21 <alee> which wont be around till K timeframe in any case.
20:14:47 <rm_work> redrobot: proposed but not yet merged BPs have longer, right?
20:14:58 <alee> redrobot, for K? or for J?
20:15:01 <woodster_> I think that is just for Juno
20:15:11 <alee> good :/
20:15:16 <redrobot> alee proposal freeze is for J release
20:15:38 <redrobot> rm_work yes, but we should try to get those BPs merged if possible
20:15:38 <alee> woodster_, but we will need some way to differentiate between ca's
20:15:48 <rm_work> redrobot: just thinking of yours :)
20:16:03 <rm_work> redrobot: which you still need to update
20:16:14 <alee> woodster_, specifically a client will need to be able to specify which ca it wants to use for its cert requests
20:16:16 <rm_work> or I guess I could take it over...
20:16:33 <alee> and then we'll need server side code to make that happen.
20:16:35 <woodster_> alee: that would be great if we could do it
20:16:35 <rm_work> redrobot: would you rather I just took it over?
20:17:01 <alee> woodster_,  well - we need to if we want to be able to test cert issuance
20:17:09 <redrobot> rm_work you can if you want to...
20:17:12 <redrobot> rm_work sounds like you want to
20:17:25 <rm_work> :P might speed things up
20:17:33 <alee> woodster_,  I'm going to suggest we use the subject key identifier for the ca signing cert
20:17:56 <alee> woodster_, thats a 20 byte string that is supposed to be unique for a ca
20:18:24 <alee> woodster_,  we'll need to handle it in any case when we start servicing revocation requests
20:19:03 <woodster_> alee: that sounds good. So maybe we;d have two work efforts, one to add a supports() method to the cert plugin that pays attention to that field, and one to add the service to discover what plugins are available and return the schema?
20:19:56 <alee> woodster_, yes - the first one should go in before J
20:20:04 <alee> the second can be deferred to K
20:20:12 <woodster_> alee: that sounds cool to me
20:20:53 <alee> ok
20:21:13 <atiwari__> woodster_, alee are we talking about improving the support method to use meta (key-spec) to check support?
20:21:15 <woodster_> other maybe-in-K items were: Keystone eventing, the json-home version resource, adding plugin validation method in our validators.py module?
20:21:18 <alee> of course, all this needs to land on top of arvind's patches
20:21:51 <alee> atiwari__, we're talking about a supports method that cert plugins need to implement
20:21:59 <atiwari__> ok
20:22:04 <rellerreller> Which CR is arvind's?
20:22:16 <woodster_> ha, yes! https://review.openstack.org/#/c/87405/
20:22:20 <alee> there are two ..
20:22:24 <woodster_> #link https://review.openstack.org/#/c/87405/
20:22:51 <atiwari__> rellerreller, I have just pushed another patch with fix for your comment
20:23:06 <alee> #link https://review.openstack.org/#/c/111412/
20:23:07 <rellerreller> atiwari__ thanks
20:23:10 <woodster_> That CR would be very good to land soon
20:23:32 <woodster_> The asymmetric CR would be nice thereafter
20:23:35 <woodster_> #link https://review.openstack.org/#/c/111412/
20:24:09 <alee> woodster_, I put in a comments in the asymm CR at the end -- let me know what you think
20:24:17 <woodster_> alee: will do
20:24:55 <redrobot> awesome, sounds like we're in pretty good shape for J3.
20:24:57 <atiwari__> alee, I think I have addressed all of your comments
20:25:03 <alee> woodster_, is the plan to try to get in logic to do both cert issuance and cert generation?
20:25:11 <redrobot> I've also been trying to stay on top of the bugfixes for J3
20:25:12 <alee> atiwari__, you might have missed the last one?
20:25:22 <atiwari__> alee hmm
20:25:37 <alee> atiwari__, oh I'll take that back ..
20:25:45 <alee> new patch since I looked last
20:25:54 <atiwari__> alee :)
20:26:07 <woodster_> alee: that would be nice, at least from the framework/api definition perspective.
20:26:26 <redrobot> atiwari__ I see 3 bugs listed as In-Progress for you
20:26:35 <redrobot> #link https://launchpad.net/barbican/+milestone/juno-3
20:26:45 <atiwari__> let me take a look
20:27:24 <redrobot> we also have 4 confirmed bugs that are unassigned
20:27:33 <alee> incidentally, there is a WIP CR for an extension to the dogtag plugin to do cert generation .. please take a look.
20:27:44 <atiwari__> redrobot, woodster_ wondering why add more type bp is not listed for J3?
20:29:23 <alee> woodster_, who is doing the certificate generation and issuance CR?  me, you, chellygel ?
20:29:49 <redrobot> atiwari__ it was listead for juno-1 for some reason, just changed it to target juno-3
20:30:07 <atiwari__> redrobot, thanks
20:30:21 <woodster_> alee: we can talk about that off this meeting if you'd like...we just have to coordinate that work. If you are doing Dogtag exclusively, that isn't as much a concern, but still integration of course
20:30:51 <alee> woodster_, ok lets chat after this meeting
20:31:19 <woodster_> alee: I think the main thing is scoping M3 vs beyond.
20:31:26 <woodster_> alee: sounds good
20:31:53 <atiwari__> redrobot, I will look at bugs
20:32:39 <redrobot> atiwari__ thanks!  Also, don't feel pressured to fix them all.  If there's any of them that you can't get to we can unassign them and have someone else pick them up.
20:32:56 <atiwari__> ok
20:33:51 <alee> redrobot, I'll work with you post-J3 to get the dogtag chef work done.
20:34:52 <redrobot> alee sounds good!  I'm envisioning a 3rd party testing gate that can spin up dogtag instances so we can run tests against them for every CR
20:35:24 <alee> redrobot, sounds excellent
20:37:03 <alee> woodster_, what is plugin validation?
20:37:30 <woodster_> That's asking the plugins to validate client request data
20:37:51 <woodster_> A little different than the supports() contract
20:38:41 <alee> woodster_, for certs only or other operations?
20:38:56 <woodster_> So supports() just says if a plugin can handle a process or not, and validate() would handle doing a detailed validation of the input data. The latter could be done in the API/synchronous processing, in addition to the validators.py json schema logic now
20:39:13 <woodster_> alee: it could be for all operations
20:40:08 <alee> woodster_, so you'd like to land adding the framework before J3?  the plugin methods themselves wont get written by then for sure.
20:40:13 <woodster_> alee: for example, right now we hard-code the key-type order checks (for algorithm, bit length) based on the one type we use now. In reality, the plugins should take on that validation, not hard coded logic in the common/validators.py module.
20:40:53 <alee> this sounds like something that goes to K ..
20:41:02 <woodster_> alee: it woudl be good to have a validate() method on the plugins my M3, to solidify those contracts
20:41:25 <woodster_> alee: yeah, we are coming down to the wire for sure.
20:41:52 <woodster_> alee: we might just have to say, we'll defer validation and just assume a one-plugin deployment approach for Juno
20:43:18 <redrobot> +1 one-plugin deployment for Juno
20:43:19 <woodster_> if we had a validate() method on the plugins for M3 though, I'm thinking we could complete the integration into barbican core for the final release though?
20:43:39 <alee> woodster_, right now , we do some kind of validation based on the supports() method and the keyspec
20:43:46 <alee> or am I confused ..
20:43:47 <woodster_> or is that stretching the feature freeze a bit? Does ice stretch??
20:45:15 <woodster_> alee: well, supports() is intended to select a plugin to do further processing. it wouldn't have to do a full validation check necessarily. Validation only has to be done when we receive the request. We'd call supports() on the worker side again, but a full validation would not be needed.
20:46:06 <woodster_> alee: so the symantec plugin supports() would just have to check if it is the CA requested. The validate() could then look at each key/value pair to see if the data is complete/incorrect.
20:46:31 <alee> woodster_, sure -- lets leave aside cert issuance right now ..
20:46:40 <alee> there clearly more validation is needed
20:47:13 <alee> I'm interested in what you think should be there for key generation and for storage ..
20:47:35 <alee> given that the supports methods we currrently have has a key_spec
20:48:34 <woodster_> I'd like to move this logic:
20:48:34 <alee> which plugins use to determine if they support key algorithm , length etc.
20:48:37 <woodster_> #https://github.com/openstack/barbican/blob/master/barbican/common/validators.py#L290
20:48:44 <woodster_> ...for example.
20:50:37 <alee> I see -- did not realize we only support "aes" here ..
20:50:41 <woodster_> so key generation can only support aes cbc keys now, plugins be damn*d :)  Trying to put plugins in the driver's seat. This validation logic only needs to be done in the API node, not the worker node.
20:51:01 <rellerreller> If there is a discussion about this then can you please list a date/time? I would like to know about this.
20:51:18 <rellerreller> I cannot discuss today as only 9 minutes left.
20:51:42 <alee> woodster_, yeah - lets table this and set up a meeting
20:51:45 <woodster_> ah, got it...maybe tomorrow in IRC...2 or 3pm?
20:52:08 <rellerreller> Are those ET or CT?
20:52:09 <redrobot> heh... yeah... time flies when you're having fun :)
20:52:21 <woodster_> ...looks at calendar...3 or 4pm CDT
20:52:39 <rellerreller> 4 CDT works for me
20:52:44 <alee> I have meeting at 4:30 ET
20:52:49 <rellerreller> Sorry I meant 3 CDT
20:53:06 <alee> which is 3:30 CDT
20:53:12 <alee> can we start earlier?
20:54:06 <woodster_> we have planning meetings until 3pm CDT tomorrow
20:54:24 <redrobot> Yeah... psrint planning day is never productive :-\
20:54:25 <woodster_> maybe an etherpad would work to get us started?
20:54:53 <woodster_> etherpad, then meet if needed?
20:54:54 <alee> :) ok - how about wed ? and woodster_ can get an etherpad going with some ideas
20:55:01 <rellerreller> Sounds good
20:56:05 <woodster_> #link https://etherpad.openstack.org/p/barbican-validation-options
20:56:44 <redrobot> ok, guys, it's time to wrap it up for the weekly meeting
20:56:47 <redrobot> thanks everyone!
20:57:05 <rellerreller> Shameless plug but https://review.openstack.org/#/c/101582/ has 2 +2s and only needs workflow approval :)
20:57:42 <redrobot> rellerreller I'll take a look at it :)
20:57:48 <redrobot> see you guys next week!
20:57:52 <redrobot> #endmeeting