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