14:00:26 <jorgem> #startmeeting neutron lbaas
14:00:27 <openstack> Meeting started Thu Jul 24 14:00:26 2014 UTC and is due to finish in 60 minutes.  The chair is jorgem. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:31 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:45 <dougwig> o/
14:00:50 <jorgem> Role call please :)
14:00:53 <crc32> Over
14:00:54 <xgerman> gm
14:01:00 <sbalukoff> Morning!
14:01:02 <blogan> \o/
14:01:10 <dougwig> here
14:01:22 <jorgem> Anyone want to add to the agenda?
14:01:34 <evgenyf> Hi
14:01:48 <s3wong> hello
14:01:51 <jorgem> Agenda currently has the following items:
14:01:51 <jorgem> •	Review Updates
14:01:52 <jorgem> •	TLS Work Division
14:02:47 <crc32> is evengy here?
14:03:01 <jorgem> yes
14:03:09 <evgenyf> I'm here
14:03:25 <jorgem> Okay well we should have a pretty short meeting then today!
14:03:38 <sbalukoff> Yay!
14:03:40 <jorgem> #topic Review Updates
14:03:54 <jorgem> Anybody have any review updates they'd like to share?
14:04:28 <blogan> Not really much just updating based on comments
14:04:45 <evgenyf> There is a TLS implementation on review, welcome https://review.openstack.org/#/c/109035/3
14:04:56 <sbalukoff> I just want to say that I'm glad Kyle and Mark accepted the ones they did this week. That's huge for adding new features to Neutron LBaaS for Juno!
14:05:05 <xgerman> +1
14:05:08 <jorgem> sbalukoff: indeed
14:05:19 <ptoohill> hello
14:06:05 <jorgem> Okay well as long as reviews are going at the pace they are I think we should be good
14:06:25 <jorgem> Anything need special attention besides TLS?
14:06:32 <sbalukoff> Yep. Need to keep the momentum up getting actual code reviews done now that specs for major features are approved.
14:06:55 <xgerman> +1
14:06:56 <jorgem> Alright then let's move on to the next topic
14:07:03 <jorgem> #topic TLS Work Division
14:07:25 <jorgem> There is a ML thread on this but wanted to bring it up here since it's important to a lot of us.
14:07:36 <jorgem> evgenyf: How much have you completed thus far?
14:07:59 <jorgem> evgenyf: And more importantly, can any of us help?
14:08:01 <ptoohill> I have my TLS ref impl spec that ill be working on for sure. But willing to help, if needed, on the parent spec
14:08:20 <evgenyf> jorgem: extension + db + unit tests for them
14:08:37 <dougwig> evgenyf has the db/plugin model work done (see review.)  remaining is the ref driver and the code that pulls from barbican.
14:09:15 <xgerman> + the registration if rmwork gets accepted
14:09:28 <evgenyf> dougwig: exactly, There is a spot for TLS containers validation by using a new common module that should use Barbican APi
14:09:33 <sbalukoff> Isn't the ref. implementation stuff mostly about the haproxy config template?
14:09:55 <blogan> evgenyf: that common module is that something you added or something neutron has added?
14:09:58 <sbalukoff> Oh, I guess there's additional code for interfacing with barbican, too.
14:09:58 <ptoohill> correct sbalukoff
14:10:20 <xgerman> yes, barbican code + common logic for extracting CN, etc.
14:10:20 <sbalukoff> (The L7 stuff will be about the haproxy config template almost entirely.)
14:10:31 <sbalukoff> Ok, cool.
14:10:38 <crc32> I'm not sure when the X509SubjNameExt class code is going to be accepted into pyopenssl. Its dependent on bindings that need to be released in the cryptography project as well. So should we be codeing the asn1_module for now and switch it out later or what?
14:11:14 <sbalukoff> crc32: IF we really don't know when it's going to get into pyopenssl, I would say, "yes."
14:11:16 <xgerman> sounds like a strategy
14:11:17 <dougwig> crc32: we've for 4 weeks left; i don't think you can bet anything on someone else releasing first.
14:11:26 <dougwig> /for/got/
14:11:32 <evgenyf> Carlos, we may start by just commiting API of the module
14:11:53 <TrevorV> o/
14:12:05 <samuelbercovici> crc32: we need to make the libraray api concrete and have implementation as fast as possible, we can always switch the implementation to something nicer later
14:12:08 <blogan> is that something that has to be in?
14:12:14 <ptoohill> Yea, there wont be a whole lot, if any, actual work needed to the driver itself now. I will need to create a haproxy1.5 template, make it configurable any additional testing for it.
14:12:20 <crc32> ok sounds like pyasn1 then.
14:13:09 <samuelbercovici> blogan: if we agree that we skip validation of the x509, than we can process
14:13:25 <xgerman> sounds good for v1
14:14:39 <samuelbercovici> so to propose, 1. complete the review without the library and get it in ASAP. 2. add a "bug" to fix it using the library later to be completed either in Juno or after. or tey and do 1+2. I am in favor of 1
14:14:42 <samuelbercovici> and then 2
14:15:10 <xgerman> samuelbercovici +1
14:15:14 <sbalukoff> samuelbercovici +1
14:15:25 <dougwig> so i think i hear ptoohill working on the driver, crc32 on the x509 parsing.  is one of you doing the barbican integration, or someone else?
14:15:52 <sbalukoff> As far as who does what: I'm happy to volunteer to review code (as I've been doing with other patches to date, too). :)
14:16:27 <jorgem> I think rm_work may be working on Barbican integeration.
14:16:29 <rm_mobile> I was planning to look at the barbican integration
14:16:41 <sbalukoff> Cool.
14:16:46 <blogan> evgenyf: where is this common module you mentioned earlier?
14:16:49 <samuelbercovici> rm_mobile: any eta on this?
14:16:53 <dougwig> rm has gone mobile.
14:17:02 <rm_mobile> The CR is up for the functionality we need
14:17:13 <dougwig> blogan: see the review, i believe he means the tis validation method.
14:17:16 <crc32> I'm gonna kickstart adam on the barbican integration.
14:17:17 <rm_mobile> So... Maybe soon?
14:17:27 <xgerman> but we still need to write code in neutron-lbaas which retrieves the cert
14:17:40 <dougwig> #link https://review.openstack.org/#/c/109035
14:17:47 <xgerman> even if the subscriber thing doesn't make it
14:17:47 <evgenyf> blogan: It does not exist yet but ints API spec is in TLS rst
14:17:55 <samuelbercovici> otherwise, each driver will need to implement this by its own
14:18:23 <samuelbercovici> this == barbican integration
14:18:47 <jorgem> samuelbercovici: I believe once the CR is complete on the Barbican side will rm_work start on the integration.
14:19:02 <samuelbercovici> CR?
14:19:04 <rm_work> yeah I think the plan was to do the barbican pull in the higher level API and pass the cert/key to the driver
14:19:06 <jorgem> code review
14:19:08 <dougwig> code review
14:19:17 <samuelbercovici> k
14:19:22 <crc32> change request.
14:19:24 <rm_work> possibly also the barbican ID in case the driver would rather use that?
14:19:26 <crc32> oh I mean code review
14:19:31 <jorgem> crc32: ah yes
14:20:03 <Pattabi> hi guys
14:20:15 <rm_work> I will be working with the barbican team to get python-barbican-client up to speed for us
14:20:18 <dougwig> Pattabi: hiya
14:20:21 <Pattabi> This is Pattabi from Brocade .. I have a question regarding the data model changes
14:20:35 <rm_work> and then will probably be working with either blogan or crc32 to get that into neutron-lbaas
14:20:45 <rm_work> there's also some stuff about Keystone Trusts we need to work out...
14:20:46 <Pattabi> at the end of Juno, will only the new data model supported ?
14:20:46 <dougwig> Pattabi: one sec, on a tis agenda item.
14:20:46 <samuelbercovici> al in all without validation, the code should use the tenant identity under which the lbaas call is done and get the container which has the cert+key
14:21:07 <dougwig> jorgem: can you add an agenda item for Pattabi ?
14:21:14 <rm_work> well, it looks like we will also need to set up a Keystone Trust and track that… :(
14:21:20 <blogan> Pattabi: v2 will be the only code that gets worked on, but v1 will still exist
14:21:31 <rm_work> so the workflow has an extra step now above what I originally thought would be necessary
14:22:06 <samuelbercovici> rm_work: can you please initiate this description on ML so we can discuss details?
14:22:19 <jorgem> So to recap these are the items being worked on for TLS:
14:22:20 <jorgem> Barbican Integration (rm_work)
14:22:20 <jorgem> Reference Implementation (ptoohill)
14:22:20 <jorgem> DB/Plugin Model (evgenyf)
14:22:25 <jorgem> dougwig: sure
14:22:42 <sbalukoff> code reviews: Everyone else
14:22:55 <xgerman> +1
14:23:03 <rm_work> samuelbercovici: sure
14:23:04 <samuelbercovici> also cert validation and information extarction - crc32
14:23:24 <crc32> yes.
14:23:29 <sbalukoff> Yep
14:23:35 <blogan> yes code reviews, avishay and eugene have already caught a few stupid mistakes I made
14:23:36 <jorgem> samuelbercovici: noted
14:23:56 <crc32> can we get the stub module so I can start injecting my code.
14:24:24 <dougwig> crc32: pull the review above.
14:24:55 <jorgem> Okay anything else related to TLS?
14:25:16 <jorgem> Switching to Pattabi's topic...
14:25:21 <Pattabi> thanks
14:25:28 <jorgem> #topci New vs Old Data Model Support
14:25:35 <dougwig> blogan's answer:  Pattabi: v2 will be the only code that gets worked on, but v1 will still exist
14:25:43 <blogan> thanks dougwig
14:25:43 <Pattabi> i submitted the code for brocadew lbaas driver
14:25:57 <blogan> Pattabi: i'm assuming it only supports the v1 model?
14:26:03 <jorgem> #topic New vs Old Data Model Support
14:26:07 <Pattabi> the spec was rejected mentioning that the data model changes happen and waitf or K
14:26:44 <crc32> yea I have the review open but I'm seeing a bunch of DB model stuff.
14:26:54 <Pattabi> would like to know what does it take to get the code reviewed and merge upstream
14:27:10 <blogan> Pattabi: the spec approval deadline has passed anyway, i doubt it would get it now
14:27:28 <blogan> Pattabi: is this code or a spec?
14:27:33 <samuelbercovici> Pattabi: the best would be to discuss with Kyle
14:27:38 <Pattabi> i understand ... i had sewnt for approval much earlier than that and code review also
14:28:24 <Pattabi> sjd i focus on v3 model or v1 only for my driver ?
14:28:30 <jorgem> Pattabi: Also, to stay informed please visit #link https://wiki.openstack.org/wiki/Neutron/LBaaS
14:28:54 <blogan> Pattabi: I would suggesting just implementing the v2 model and driver interface
14:29:10 <blogan> v1 will eventually be deprecated and removed
14:29:20 <Pattabi> blogan: thanks
14:29:22 <jorgem> Pattabi: v1 will be deprecated sometime in the future I believe so v2 is the best bet right now.
14:29:26 <dougwig> Pattabi: your best bet is to retool the spec/code for v2, and then engage directly with mestery.  Expect it to be a low priority; all vendor items seem to be.
14:30:06 <blogan> dougwig: sounds like a sore topic
14:30:08 <dougwig> (on the release schedule, i mean.)
14:30:22 <Pattabi> ok ... is there an exception list for the specs now that deadline is passsed
14:30:30 <dougwig> i didn't mean that to sound as harsh as it came out.  it's early.  :)
14:30:37 <jorgem> Yes, Kyle can override it
14:30:40 <dougwig> Pattabi: yes, it's via the ML.
14:30:41 <blogan> Pattabi: there is but they aren't adding any more to it unless it is really high priority and necessary
14:30:52 <crc32> dougwig: I meant the module for mangling the x509 and keys.
14:31:26 <dougwig> crc32: standby for the end of this agenda topic.
14:31:56 <xgerman> Pattabi  it looks mestery joined
14:32:37 <Pattabi> mestery: this is regarding hte brocade lbaas driver code reivew and approval
14:33:37 <jorgem> mestery "joined"?
14:33:46 <blogan> i have a topic, Avishay sent an email about not liking the specific entity not found exceptions in favor of a General entity not found exceptions, this sounds good to em.  What does everyone else think?
14:33:47 <xgerman> yeah, I saw his name being changed
14:34:10 <dougwig> Pattabi: how long would it take you to retool for v2?
14:34:19 <jorgem> blogan: topic added
14:34:24 <Pattabi> i am working on it now ...
14:34:38 <Pattabi> couple of days i think i shd have a v2 based driver
14:34:52 <ptoohill> sure, sounds reasonable, blogan.
14:34:57 <sbalukoff> blogan: I must have missed this e-mail. Was it tagged with [Neutron][LBaaS] ?
14:34:57 <dougwig> 1 day?  1 week?  1 month?  if it's a few weeks, then you're in the same boat as the other vendors, and have a good argument.
14:35:14 <blogan> sbalukoff: it was
14:35:31 <Pattabi> i upload the private patches for the v2 changes and refactoring my driver currently
14:35:57 <avishayb> I can copy  & paste here .. (the mail)
14:36:01 <Pattabi> hen will v1 model deprecated
14:36:08 <sbalukoff> Wow, gmail is being exceedingly slow for me this morning...
14:36:21 <jorgem> Okay, let's start next topic
14:36:33 <sbalukoff> Pattabi: As soon as possible. ;) But probably in K release
14:36:36 <crc32> psatbin
14:36:38 <jorgem> #topic Exception Naming
14:36:38 <dougwig> Pattabi: an accelerated deprecation for drivers was discussed at the July meetup, so they may be marked deprecated in Juno.  K at the latest.
14:36:52 <jorgem> go ahead blogan
14:37:42 <blogan> Okay currently there are LoadBalancerNotFound and ListenerNotFound, and so forth exceptions.  This should probably change to just EntityNotFound so we dont have all the different types of exceptions
14:37:48 <dougwig> i agreed with the email and common name.
14:38:01 <blogan> v1 has the VipNotFound, PoolNotFound, MemberNotFound exceptions so I just followed that model
14:40:03 <blogan> ok dougwig and avishay and I agre
14:40:04 <jorgem> Yeah common exception until we actually need a specific one
14:40:07 <rm_work> as long as they all inherit properly, you should just be able to catch them with their parent type
14:40:13 <ptoohill> and phil
14:40:14 <rm_work> but whatev <_<
14:40:17 <ptoohill> if that matters
14:40:22 <dougwig> to make a counter-argument against myself, i am guessing they are separate for localized error messages.
14:40:37 <xgerman> well, that's what inheritence is for
14:40:45 <blogan> the error message will be localized
14:41:12 <jorgem> Okay so 1) Use common exception 2) If not 1 use specific exception (inherited of course)
14:41:14 <dougwig> right, but an unspecific "not found", even in spanish, is just about worthless in something like a UI.  it's maddeningly obtuse.  :)
14:41:30 <blogan> the error message will have the actualy entity name
14:41:54 <jorgem> dougwig: It should be implied on what you were querying for right? That is if you are querying for one thing and not a nested object.
14:42:19 <dougwig> not in the "create an LB like an instance" UI paradigm that ebay demoed, no.
14:42:20 <jorgem> dougwig: Also you can pass a string into the exception for detail
14:42:32 <dougwig> but as long as they can still see what isn't found, that argument is moot.
14:42:40 <blogan> they will see what isn't found
14:43:07 <blogan> that sounds like a great philosophical quote
14:43:31 <sbalukoff> Haha
14:43:31 <dougwig> i'm full of nonsense in the morning.
14:43:40 <blogan> i wouldn't call it nonsense....
14:43:57 <jorgem> Okay, any other topics? If not I think we are done!
14:44:07 <sbalukoff> Yay!
14:44:16 <Pattabi> i have a question on v2 data model
14:44:26 <blogan> Pattabi shoot
14:44:37 <jorgem> #topic Question on v2 on data model
14:44:43 <Pattabi> can the same pool be bound to different listeners
14:44:52 <dougwig> one of us needs to get with carlos and talk about where to plumb the x509 parsing in.  hopefully that can wait an hour.  :)
14:44:56 <blogan> pattabi: not right now but it may be supported in the future
14:44:58 <sbalukoff> Not in this revision.
14:45:13 <Pattabi> then the db code should handle this check
14:45:25 <jorgem> dougwig: I have crc32 in a meeting afterwards :)
14:45:43 <Pattabi> it does not check for this as part of the listener default_pool_id update
14:46:06 <blogan> Pattabi: the default_pool_id is set up as a unique constraint
14:46:43 <Pattabi> yes .. it generates the DB exception that is not propagated upwards properly
14:46:57 <blogan> Pattabi: you're probably right on that, could you add a comment
14:46:59 <blogan> to the review
14:47:06 <Pattabi> i will add today
14:47:10 <blogan> thank you
14:47:19 <Pattabi> same with hm to pool
14:48:29 <rm_work> yes unfortunately we're out for the next 3 hours for sprint planning through lunch <_<
14:48:44 <jorgem> :)
14:49:02 <blogan> yall have a good day
14:49:02 <jorgem> Okay, I think we are done everyone
14:49:10 <sbalukoff> Thanks y'all!
14:49:13 <evgenyf> guys, regarding TLS work split, do we need another session on this?
14:49:15 <Pattabi> thanks all
14:49:20 <dougwig> i'll be around all day.  and carlos knows where brandon sits, worst case.
14:49:21 <xgerman> thanks
14:49:23 <blogan> sbalukoff the only person who mixes eh and yall
14:49:39 <xgerman> bye
14:49:39 <sbalukoff> :)
14:49:40 <jorgem> evgenyf: I have some notes on this but I think you and crc32 need to meet I believe
14:49:47 <jorgem> and anyone else of course
14:49:56 <dougwig> later folks
14:50:04 <blogan> evgenyf: is it late for you?
14:50:10 <dougwig> Pattabi: you can find us on #openstack-lbaas
14:50:13 <crc32> yea but I can't meet just yet caue I'm getting screwed over in a planning session.
14:50:24 <jorgem> #endmeeting