14:01:02 #startmeeting neutron lbaas 14:01:03 Meeting started Thu Feb 6 14:01:02 2014 UTC and is due to finish in 60 minutes. The chair is enikanorov__. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:04 Howdy! I am! 14:01:07 The meeting name has been set to 'neutron_lbaas' 14:01:08 hi 14:01:49 * pcm_ lurking 14:02:05 ok, lets start with the announcements 14:02:14 hi 14:02:20 hello 14:02:23 and the most important is that gates are working more or less 14:02:41 \o/ 14:02:48 so core team may spend more time on reviews 14:03:01 and also you actually can get +1 on your patches 14:03:06 :-) 14:03:15 Good! 14:03:15 and if it's -1 from Jenkins - you need to really dig into the logs 14:03:20 and not just recheck no bug :) 14:03:42 Hi, rkukura 14:03:58 the second announcement is that feature proposal deadline is 18th of feb 14:04:16 if i'm not mistaken, so any new featuers implementation should be published before that 14:04:47 what is published? merged to trunk or submitted to Gerrit? 14:05:01 pushed to gerrit. if it's on review alredy - that's fine 14:06:14 we have whole line of patches under development on all three major features 14:06:21 l7, lb instance, ssl 14:06:59 the features are important and make a big part of lbaas API and functionality 14:07:46 in my opinion there are very little chances that what we are working on right now will be merged in Icehouce 14:08:33 but at the same time we'd like to give users some advancement in lbaas service over what whas in Havana 14:09:11 so there is an idea to make a 'downstream' version of neutron (focused on lbaas plugin and drivers) 14:09:45 what does that mean? can you elaborate? 14:09:49 yep 14:10:24 that supposed to be the merge of current master + exsiting features on review, which are stable and tested 14:10:51 so the branch could be packed and given to users for early adoption 14:11:14 so I'd like to ask if that makes sense to you guys? 14:11:28 who will track and make this release happen? 14:11:29 who will be using that downstream version? Are therte such requests from someone? 14:11:48 When should that happen? 14:12:13 I think some of Radware customers are candidates 14:12:14 vjay: i guess i'm going to do that if there is such demand 14:12:22 now i'm exploring the need for that 14:12:51 of course this is some additional work that needs to be done 14:12:56 we can not come with nothing in lbaas for H version 14:13:03 however it may be beneficial for some vendors/customers 14:14:23 but having downstream version doesn't means every unmerget lbaas patch gets in 14:14:42 so we need some kind of policy for that (of course focused on quality) 14:14:55 are there any examples of such downstream versions in any other OS projects? 14:15:22 obondarev: in fact many adopters use whiole OS in such manner 14:16:00 enikanorov__: are we planning to do this version before or after a freeze of Icehouse 14:16:00 I'm trying to understand will it be beneficial for development speed 14:16:05 yeah, I know, my question was about kind of official downstream version 14:16:15 as we'll need to work with two repos 14:16:44 evgenyf: we don't have deadlines, although what I'm talking about is not something decided 14:16:50 it's just an idea 14:16:59 i'm going to discuss it with Mark 14:17:28 How will fixes get into this branch? 14:17:29 as we don't wan't to position it as 'here, have that, because neutron could not make anything in Icehouse' 14:18:16 till when we will support this? 14:18:36 vjay: i think if a patch passes Jenkins and the author has tests to verify the patch, it will be a candidate for inclusion 14:18:44 by saying tests i mean integration tests 14:18:51 (scenarios) 14:19:27 vjay: good question. It needs to be decided 14:20:14 meanwhile it would be good if you could ask potential customers if they will be willing to try such kind of stuff. 14:21:13 well, i know of two types of customers. one that dont want to move from havana to icehouse. Others who wants to jump from grizzly directly to icehouse. 14:21:40 using this version will be very tricky 14:21:50 a question: what about horizon? do we need a downstream horizon version for new features merged to downstream neutron? 14:22:07 ok, basically that's the argument against the idea :) 14:22:16 will this branch be kept in sync with neutron changes in icehouse? 14:22:24 changes == fixes 14:22:25 obondarev: i don't think so, CLI would be enough 14:22:40 vjay: yes 14:22:58 and it will be cut on top of havana? 14:23:01 enikanorov__: is CLI really ok for customers? 14:23:04 sorry 14:23:06 icehouse 14:23:44 vjay: i think it will be following current master, because we are not targeting particular release 14:24:01 it matters how we distribute the code 14:24:20 then it will be tricky. 14:24:24 enikanorov__: ok, so for CLI we need a downstream neutron client version - right? 14:24:24 it could be a mere diff applied to a certain revision of neutron's master 14:24:31 obondarev: yes 14:24:57 vjay: it's not very simple, but we can try to make it simple 14:25:18 enikanorov__: things are getting complicated :) 14:25:30 well, not really 14:25:37 hmm...it is a long shot... as you said we need to first verify the need. 14:25:45 to test a new feature in the devstack you only need to provide a link to a repo 14:25:48 in your localrc 14:26:02 so using downstream version should not be more complex 14:26:20 so what specific functionality will be added to this branch? 14:27:24 edhall: based on review results. it could be a common case when feature is not getting approved because of some minor concerns or feature freeze or ... 14:27:39 in this case if we are sure it's working - we add it to our branch 14:29:46 any more questions on the downstream idea? 14:30:30 Let's here Mark's opinion 14:30:36 Expansion on edhall's question: Are there specific features being considered to add to this branch right now? 14:30:37 hear* 14:31:15 sbalukoff: i think we don't have major feature that is ready for that 14:31:24 Ok. 14:31:31 loadbalancer instance may be, but it's not a big addition to functionality 14:32:08 also, we'll have 3 months between feature freeze and the time new features will be reviewed for merging 14:33:19 enikanorov__: just to double confirm. there is no chance that ssl, l7 will make it to icehouse. is that right? 14:33:58 i didn't say no chance, but i don't think we will manage to polish those features 14:34:18 so this is essentially a way to progress in the face of the Feb 18th feature freeze? 14:34:45 That's what it sounds like to me, too. 14:34:47 feature freeze is Feb 28 I think 14:35:22 yes, but our deadline is closer 14:35:31 so we have a bit more time to polish 14:35:54 what is our deadline? 14:35:58 right, our objective is to publish the code before 18th :) 14:36:04 not have it merged 14:36:35 we'll have ~2 additional weeks to address review comments 14:36:44 but it's still lot's of work 14:36:47 right 14:37:29 it's all depends on the review speed 14:37:34 from core reviewers 14:37:44 i think it also depends on development speed right now 14:37:56 as we don't have working implementations of l7 and ssl yet 14:38:03 right now yes 14:39:25 so let's move to the statuses on features? 14:39:26 let's briefly discuss the features under development 14:39:37 i'll start with lb instance 14:40:04 the patch is ready, obondarev is working on applying instance approach to haproxy 14:40:17 I've uploaded a patch wich adopts lb instance for agent scheduling 14:40:19 so users will be able to create multiple pools in haproxy 14:40:42 these are prerequisities for L7 rules 14:40:54 second patch will adopt lb instance for lbaas agent itself, I'm working on it 14:42:02 my next steps for SSL are: writing db layer unitests and fixing all review comments 14:42:12 avishayb: obondarev: what's the status of l7? do we have CLI for l7 resources? 14:42:31 I have updated the wiki - https://wiki.openstack.org/wiki/Neutron/LBaaS/l7 14:42:55 BTW, I have undated the WIKI page too, https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL 14:42:59 evgenyf: good 14:43:07 its in sync with the code now. Begining next week I will start to react on reviews 14:43:15 No CLI yet 14:43:20 avishayb: i see 14:43:29 evgenyf: i have another concern on ssl API 14:43:33 avishayb: I put some new comments on the patch. Also will be great if you can address/answer comments on the previous patch sets 14:43:55 it seems complex to me, so I'd like to see some ability to use simplified workflow 14:44:00 obodarev: I will 14:44:01 it's really hard to review if you don't know what you agrre and what not and why 14:44:02 i'll explain what i mean 14:44:03 There is beagaviour description for vip/pool/ssl policy protocole mismatches. Guys, please have a look.. 14:44:13 *behaviour 14:45:04 by saying 'complex API' i don't mean it needs to be changed, but instead it should provide ability to do things on less steps 14:45:15 avishayb: thanks 14:45:24 say, create a vip with 1 command, providing all ssl attributes 14:45:34 evgenyf: do you think it's possible? 14:45:54 1 command = 1 rest call 14:47:06 enikanorov__: Do you mean using CLI? 14:47:31 no, i'd prefer to see it in the API 14:48:11 it's like loadbalancer instance, you can create one, and then add pool to it, or you can create a pool and lb instance will be created for the pool automatically 14:48:34 can we apply the same approach to policies/certs? 14:49:21 you mean applying default SSL poliy and certs. to vip on creation stage? 14:50:09 default cert? 14:50:13 no 14:50:24 i mean i could provide cert on vip create 14:51:04 I do not see a reason for doing that.. can you elaborate ? 14:51:05 i'm just thinking of the terrible amount of parameters i need right now to setup a ssl vip 14:51:44 ok, i'll review the API again and will explain more precisely 14:52:08 enikanorov__: Ok, let's discuss it 14:52:32 ok, that's all i wanted to discuss today 14:52:43 doesn anyone have questions/items to discuss? 14:53:12 Please review SSL wiki page for new details 14:53:22 lbaas scenario test is in good shape, should be merged soon 14:53:41 is anyone working on sslconnect+haproxy? 14:54:12 vjay: stunnel? 14:54:26 sorry, yes stunnel 14:55:25 it's me, but i have not made much progress on that particular item as I'm working with evgenyf on ssl API patch 14:56:24 ok. 14:57:55 ok, if theres' no other questions then let's wrap up 14:58:02 thanks for joining everyone 14:58:35 bye. 14:58:42 Seeya! 14:58:43 bye all 14:58:48 bye 14:58:51 bye 14:58:52 see you all 14:58:57 #endmeeting