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