00:00:52 #startmeeting networking_fwaas 00:00:52 Meeting started Thu Nov 12 00:00:52 2015 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:00:56 The meeting name has been set to 'networking_fwaas' 00:00:57 Hi 00:01:09 hi 00:01:11 Hi All 00:01:27 #topic announcements and housekeeping 00:01:53 I'd like to say that it was really great to meet everyone at the summit 00:02:02 +1 00:02:08 thanks to SridarK, xgerman and those who presented at the summit about fwaas 00:02:09 sc68cal: huge +1 yes this was great 00:02:13 +1 00:02:15 +1 00:02:29 +1 00:02:30 the discussions we had f2f were invaluable 00:02:41 hi 00:03:32 +1 00:03:55 xgerman: SridarK: anything you can think of to announce, besides the new spec? 00:04:09 Mitaka schedcukle 00:04:25 at least left feeling that we had made good progress, we still have a few things to close on but it looks positive 00:04:34 #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule 00:04:40 really tight this time 00:04:43 sc68cal: we probab have to evolve the plan for us 00:05:12 yeah it is quite tight this time 00:05:38 honestly the second development cycle of the year is always shorter due to holidays and stuff 00:05:45 yes, we shd target for some basic things to be in place by end Jan 00:06:30 +1 00:06:57 ok 00:07:40 #topic New API spec 00:07:46 #link https://review.openstack.org/#/c/243873/ API spec 00:08:07 really good discussion in the comments - mickeys is setting me quite straight ;-) 00:08:18 thanks to Aish for submitting - I'm sure it took some wranging to get everything from the etherpad 00:08:25 Just a little fun back and forth :-) 00:08:44 Aish +1 00:09:30 Actually yes, it took me sometime to understand stuff from ether pad… 00:10:20 I am going through the review comments… I see that there is a lot to be added/modified.. 00:11:10 yeah, but it’s a great start 00:11:27 Thanks.. 00:13:51 We'll have to figure out how to handle updates 00:14:14 It might be a bit much to expect Aish to update some parts, based on how new she is 00:14:21 but I don't want it to be a free-for-all either :) 00:14:38 yep - we should coordinate a bit 00:15:07 sc68cal: but i think it should be fine for others (mickeys primarily) to update as well 00:15:09 I can work on some text. Perhaps use IRC when someone wants to submit a patch? 00:15:20 Maybe ask for voluntters ? 00:15:26 volunteers* 00:15:36 mickeys: u can also update as well 00:15:41 I plan to 00:15:42 I agree. I shall help updating some basic stuff.. 00:16:00 I'll volunteer as well. 00:16:10 yeah, I think with all the text mickeys offered to write he should be able to make his own patch ;-) 00:16:21 xgerman: +1 00:16:29 but lets not proliferate 00:16:34 +1 00:16:44 yeah, let's keep it to the one gerrit review 00:16:54 +1 00:16:59 we can have a few folks update and rest of us can always comment 00:17:15 yep, I think comments is the preferred way 00:17:29 Aish: Go ahead making changes replying to smaller comments. I will work on the sections I indicated in my comments and ping you on IRC when I am ready to merge and submit. 00:17:43 sounds good!! 00:17:43 ^ this sounds good to me 00:17:47 +1 00:17:51 +1 00:18:04 Sure.. 00:19:47 That's really all I had - SridarK xgerman ? 00:19:50 There is a fundamental question - the patch just blindly copies existing FWaaS behaviors like port contain port-ranges, or insert being a completely unRESTful PUT +rule. Did we intend to keep the existing interfaces in place for some reason, or was that just a strawman starting point? 00:21:17 I think the API design is a starting point and we can make more changes as we see fit 00:22:32 That is what I thought too, and not wanting to change "just because". Will comment in spec. 00:22:47 +1 00:22:49 yep, commenting is good 00:23:11 If I could just keep up with mickeys and other's changes :-) 00:23:41 From an overall perspective, at least in my head - we also want to end M with something that works even if it is evolving 00:23:41 One big issue that we need to sort out. Are we still trying for backwards compatibility? Do we intend to migrate existing deployments automatically to the new API? Do we think that is feasible? 00:24:19 the only backwards compatibility I need is for existing drivers if possible (+ there is heat and horizon) 00:24:33 mickeys: this is something that we definitely figure out - 00:24:42 i am still on the wall 00:25:06 keeping backward compatibility wont help much I guess 00:25:24 On Fri of summit - xgerman & I also had a conversation with Alex from HP who also discussed the move to lbaas v2 00:25:30 in terms of Client side implementation 00:25:41 so some careful thought into that 00:26:12 yeah, in lbaasv2 most vendors adapted but we still don’t have heat nor horizon despite the API being out two cycles 00:26:44 I was thinking of pinging vendor implementors for their comments and thoughts as well 00:26:53 at least the ones i am familiar with 00:27:09 For example, the firewall rules table currently has source_ip_address and destination_ip_address that are marked as "deprecated" in the description. If we are not trying for backwards compatibility, we can remove them. 00:27:10 so we have a migration plan in place 00:27:18 That would clear up some use cases 00:27:47 since vendor support is key I think we need to hear from them before making the final call 00:28:32 #action SridarK to talk to vendors and report 00:28:41 With LBaaS, does user provisioning through LBaaS v1 stay as v1? Or does it automatically migrate to LBaaS v2? 00:28:51 it stays v1 00:29:03 there are two different things bu only one can run 00:29:16 for LBaaS, I thought the API endpoint itself was different? 00:29:39 Can you use both API endpoints at the same time, depending on user provisioning? 00:29:40 yep, that, two 00:30:05 no, only one endpoint — they use the same database (and V2 has different columns in the v1 tables) 00:31:05 so two endpoints one DB which interprets columns differently depending if v2 or v1 00:31:16 which means only one can run 00:31:44 would devstack implementation change , i.e. a new extension created for v2? ( or maybe I am thinking too far) 00:31:44 but even if you can run both in parallel I think that would just create some mess 00:31:56 What happens to user provisioning done using v1, if the controller migrates to v2? 00:31:59 I think we will just replace the existing one 00:32:15 fwaas never went past experimental status, also it didn't have an API version 00:32:19 all the v1 stuff is lost 00:32:30 reedip: i think devstack implications are not an issue now 00:32:38 so I am thinking too far 00:32:39 iirc 00:32:50 mickeys: in that case, the new v2 backend would not be reading the v1 db entries 00:33:09 well, it would and trip over itself... 00:33:22 sc68cal: yes that is correct 00:33:59 then also even if you an migrate people like that to be hot so... 00:34:26 anyhow I am with sc68cal we just replace the existing thing with the new thing and maybe offer a migration tool 00:34:59 we'll do our best, basically. But the previous API wasn't versioned 00:35:26 yeah,I think since it was experimental we can just replace it with little notice 00:35:30 yes and we can think thru a migration plan 00:35:54 yep, people who use experimental features should understand the risk 00:36:03 ^ +1 00:36:07 xgerman: that is what i though when i added the router extension, but i was asked to come up with migration on my patch 00:36:41 yep, I am pretty sure the people I answer to will ask for the same ;-) 00:37:25 but yes now we have more flexibility, my point was to make sure we dont surprise anybody and hopefully we can get vendors to sign up for any refactoring if needed 00:37:55 Should we try to minimize the rules table? Remove source_ip_address and destination_ip_address and source_address_group and destination_address_group in favor of source_firewall_group and destination_firewall_group? 00:38:18 Should we go straight to service_group, removing protocol, source_port, and destination_port? 00:38:25 yes 00:38:27 + yes 00:38:43 +1 00:38:47 In favor 00:38:54 I am fine as well, but can we code this up for M as well ? 00:40:00 If we move to neutron_classifier, a fair amount of this gets ripped up anyways 00:40:26 at DB. Reference implementation is another issue. 00:40:43 let's try and keep this managable 00:40:59 * xgerman ships sc68cal lot’s of redbull 00:41:25 my concern is trying to squeeze everything in, and I don't know if service groups is really a must have in the first iteration thing 00:41:46 obviously it's a feature we want to have - but do we need to do it at the beginning 00:42:11 the classifiers is also WIP if i am not mistaken 00:42:19 oh believe me it is :) 00:42:31 not holding my breath on the common flow classifier 00:42:55 The structure of the classifier is pretty different between flat and service groups 00:43:23 +1 00:43:24 sc68cal: my concern too, lets have the full plan but stage it so we come out of M with something working 00:43:44 it also depends on how many people will be working on stuff 00:44:11 and whatever we do will be held together by chewing gum and duct tape 00:45:21 Duct tape can fix a lot of ills. 00:45:40 My life story :-) 00:46:15 So is the consensus yes on moving to source_firewall_group and destination_firewall_group, but don't force service_group just yet? 00:46:54 I think we should get the interface to vendors relatively stable 00:47:09 in the beginning - so getting most of the models in would be good 00:47:10 mickeys: i would lean that way, the highest priority being applying on ports, next how do we resolve SG and FWaaS on VM port and next address groups 00:47:59 I would prefer the staging proposed by SridarK 00:48:29 as would I 00:48:31 my worry is if we introduce big changes to the model the next few cycles vendors will stop supporting us 00:48:46 so dish out the pain in the beginning 00:48:49 Caution - i am only talking in terms of implementation, i agree we should lay out the full plan in the spec 00:49:00 what vendors support us currently 00:49:47 our driver list is fairly small 00:50:01 sc68cal: i believe we have 5 00:51:21 in my (limited) experience vendors like to write a driver and then forget about it 00:52:16 but I am not a vendor so second guessing... 00:52:40 we currently have two 3rd party CIs that report - both fail 00:52:46 brocade-ci-fwaas 00:52:51 ngfw-test 00:53:12 cisco has been flaky as well 00:53:13 that strengthens my set-and-forget argument 00:54:01 so - we'll do our best to have migration strategy and not disrupt vendors 00:54:01 xgerman: my concern is more abt how many bodies we will have to do all the things we need to do in the remaining time in M 00:54:42 but, without CI for these vendor drivers, stuff will break 00:54:45 yep, I hear you… and I am ok with slipping M to have more vendor buy-in 00:55:13 SridarK , xgerman : Maybe first break down the implementation, after you have had a discussion with the vendors, and then as per the possible action items, take a roll call in the next IRC meeting ( or whenever) as to who can do what 00:55:37 let’s agree on the API first ;-) 00:55:47 That would allow the possible identification of the targets and their implementation dates 00:55:54 reddip +1 00:55:58 reedip +1 00:56:04 reedip: +1 00:56:17 4 minutes 00:56:25 but let this not derail our API 00:56:44 yeah, we can always make a bigger spec and then break it down insnatges 00:56:56 so mickeys let’s put service groups in 00:57:07 xgerman: yes my point too 00:57:22 may be we think of this as a parent spec 00:57:24 cool 00:57:46 yeah, it took us like two or three cycles to implement octavia 0.5 00:57:50 But leave protocol, source_port, dest_port since we are not sure we will get service groups right away, and the impact on vendors may be larger if we remove them? 00:58:13 let’s keep them and mark them as deprecated 00:58:19 mickeys : and mark them deprecated ( I think they already are, but if they are not) 00:58:21 FWaaS specs go to Neutron spec repo, right? 00:58:26 +1 00:58:32 s3wong: yes 00:58:58 mickeys: yes and for addresses -> we move to groups ? 00:59:12 1 minute 00:59:19 I don't know if big parent / ambitious specs can be in for per-release spec repo... 00:59:19 SridarK yes 00:59:22 We have to do the work for groups anyways. If you do not support firewall groups in rules, you do not support FWaaS 2.0 00:59:34 So I think it is simpler to minimize the table on that one 00:59:39 +1 00:59:56 s3wong things slip all the time... 01:00:03 so I am not too worried 01:00:10 ok, time ism out 01:00:12 Ok, I shall remove source_ip_address and destination_ip_address and source_address_group and destination_address_group from rules table. 01:00:20 Aish: no. 01:00:35 oh, did i get it wrong? 01:00:59 ok, we're out of time. Let's try and resync tomorrow 01:01:06 k 01:01:08 or on gerrit 01:01:09 kok. 01:01:12 #endmeeting