18:35:13 <SumitNaiksatam> #startmeeting Networking FWaaS
18:35:13 <openstack> Meeting started Wed Dec 17 18:35:13 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:35:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:35:16 <openstack> The meeting name has been set to 'networking_fwaas'
18:35:17 <glebo> SridarK:  ah yes, just saw him join
18:35:17 <Swami> hi
18:35:28 <SridarK> hi all
18:35:42 <SumitNaiksatam> #info metting agenda https://wiki.openstack.org/wiki/Meetings/FWaaS#Agenda_for_Next_Meeting
18:35:57 <SumitNaiksatam> #info Kilo-1 is 12/18
18:35:59 <badveli> hello all
18:36:05 <SumitNaiksatam> in case you have any code in the pipeline
18:36:16 <SumitNaiksatam> #topic FWaaS code split and work items
18:37:06 <SumitNaiksatam> SridarK: we need to revive this one #link https://review.openstack.org/#/c/141127/ ?
18:37:32 <SridarK> SumitNaiksatam: i have one on the UT - have some issues - talked to pcm on this and may see what is happening
18:38:55 <SumitNaiksatam> i see a few other pending patches #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-fwaas+branch:master,n,z
18:39:23 <SumitNaiksatam> will get to that
18:39:36 <SumitNaiksatam> anyone has any other items to discuss from the repo split?
18:40:04 <glebo> did we come up w/ a name yet?
18:40:39 <SumitNaiksatam> glebo: neutron-fwaas
18:40:56 <SumitNaiksatam> i dont believe we have the charter to choose a name here
18:41:11 <SumitNaiksatam> would be cool though
18:41:17 <SumitNaiksatam> anything else on this?
18:41:21 <glebo> sorry, for the post-split adv serv line
18:41:41 <glebo> the line formerly known as positron
18:41:56 <SridarK> glebo: :-)
18:42:21 <SumitNaiksatam> glebo: there is no “adv service” project
18:42:45 <SumitNaiksatam> glebo: three new repos have been created - fwaas, lbaas, vpnaas
18:43:00 <glebo> ah. we ended up splitting it 3 ways after all. Ok then.
18:43:01 <SumitNaiksatam> these, for now, only house the plugins and the drivers
18:43:13 <glebo> ack
18:43:15 <SumitNaiksatam> glebo: this is old news though ;-)
18:43:21 <glebo> i'm old guy
18:43:30 <glebo> so it fits
18:43:42 <glebo> =-D
18:43:50 <SumitNaiksatam> currently we are following up on action items after the split so that the tests pass on the neutron-fwaas repo
18:44:22 <SumitNaiksatam> ok moving one
18:44:24 <SumitNaiksatam> *on
18:44:27 <SumitNaiksatam> #topic Bugs
18:44:40 <SumitNaiksatam> I dont see anything new in my filter
18:45:13 <SumitNaiksatam> however, that brings up an important question - where would the bugs for neutron-fwaas be filed
18:45:28 <SumitNaiksatam> not sure if this is still going to be in neutron
18:45:35 <SumitNaiksatam> i dont see a launchpad project yet
18:46:14 <SumitNaiksatam> #action SumitNaiksatam to check with mestery on where to file bugs for split repositories (neutron-fwaas) in this case
18:46:27 <mestery> Neutron LP project SumitNaiksatam.
18:46:40 <SumitNaiksatam> mestery: ah ok, thanks for the quick answer
18:46:41 <mestery> For Kilo, we'll keep them all together and reevaluate later.
18:46:43 <mestery> Sure! :)
18:46:47 <SumitNaiksatam> mestery: ok thanks
18:47:18 <SumitNaiksatam> badveli: SridarK: any critical bug show up your radar
18:47:20 <SumitNaiksatam> ?
18:47:33 <SridarK> SumitNaiksatam: nothing new
18:47:44 <SumitNaiksatam> SridarK: okay
18:47:48 <SumitNaiksatam> then moving on
18:47:51 <badveli> i am following uphttps://bugs.launchpad.net/neutron/+bug/1386543
18:48:02 <badveli> nothing new
18:48:29 <SumitNaiksatam> badveli: by following up you mean, are there any new developments?
18:48:46 <SumitNaiksatam> ah, you said nothing new
18:48:50 <SumitNaiksatam> ok moving on
18:48:53 <SumitNaiksatam> #topic Docs
18:49:06 <badveli> no there is another bug in security
18:49:11 <badveli> similar bug
18:49:32 <SumitNaiksatam> haven’t hear from Swami, so I think we are still in wait and watch mode
18:49:39 <SumitNaiksatam> badveli: you mean #link https://bugs.launchpad.net/neutron/+bug/1335375 ?
18:49:54 <badveli> yes
18:50:05 <badveli> nothing going on
18:50:57 <SumitNaiksatam> #topic FWaaS Specs
18:51:02 <SumitNaiksatam> so the first the vendor specs
18:51:22 <SumitNaiksatam> since I believe all that were proposed were merged, right?
18:51:27 <SumitNaiksatam> did anything get left out?
18:52:02 <SumitNaiksatam> so i guess not
18:52:06 <SridarK> SumitNaiksatam: yes i believe so i think the intel one had a minor issue and should be in
18:52:38 <SumitNaiksatam> you mean that the L3 spec did not need to proposed?
18:52:46 <SumitNaiksatam> the -> their
18:53:12 <SridarK> yes related to that on the FW - Kyle had asked for the dependency to be removed
18:53:35 <vishwanathj> They have now removed the dependency in their latest patch upload
18:54:11 <SumitNaiksatam> got it, just +2’ed
18:54:24 <SridarK> SumitNaiksatam: yes that is the one
18:55:49 <SumitNaiksatam> mestery: just +2’ed this #link https://review.openstack.org/#/c/91286/ (so we have two +2s now)
18:56:06 <mestery> SumitNaiksatam: Also +A'd :)
18:56:15 <SumitNaiksatam> mestery: thanks again! :-)
18:56:25 <mestery> SumitNaiksatam: Thank you as well :)
18:56:36 <SumitNaiksatam> so on to SridarK’s spec
18:56:49 <SridarK> SumitNaiksatam: thanks
18:57:00 <SumitNaiksatam> #link https://review.openstack.org/#/c/138672/
18:57:26 <SridarK> more review comments - with issues on backward compat and upgrades
18:57:28 <SumitNaiksatam> SridarK: thanks for diligently engaging with the reviewers and promptly providing responses
18:57:45 <SridarK> no worries - good to get the shake out now
18:58:12 <SridarK> SumitNaiksatam: wanted to bring this up here for discussion so we can close quickly
18:58:38 <SumitNaiksatam> SridarK: yes sure
18:58:51 <SridarK> I think the approach taken was that we have some wiggle room because we are experimental
18:58:56 <SumitNaiksatam> SridarK: so lets take each pending point
18:59:05 <SridarK> But will be good to thrash it out
18:59:19 <SumitNaiksatam> SridarK: regarding the default insertion semantics
18:59:27 <SridarK> at least as i see it - there are possibly 3 approaches
19:00:08 <SridarK> Option 1: as in the current proposal: we don't worry about backward compat
19:00:20 <SridarK> If there is not enough deployment and being experimental - we make the change and don’t address backward compatibility or upgrade. Behavior on upgrade Firewall logical resource will be created - but will not be installed on any Router. The Firewall will be in PENDING_CREATE. An update on the Firewall with a Router - will drive it to ACTIVE. Upgrade/migration is a problem, going from 1 Firewall on all Routers —> 1 Fi
19:00:49 <SridarK> This the approach taken on the spec
19:01:22 <SridarK> some valid points raised on making sure that we want to do this and if we to make sure messaging is very clear
19:01:50 <SridarK> Option 2:  If a Router is specified on the create - it will only be installed on that specific Router. If no Routers are specified on the API - we default to current behavior - the Firewall will be inserted on all Routers on the tenant. Updates to now go to a single router will be a bit tricky. And if we are in the current model (default) when new Routers are added to the tenant - they will need to be tracked and the Fi
19:02:28 <SridarK> This is kind of a hybrid
19:02:56 <SridarK> i fear some complexity here and i think we want to get away from the all routers model
19:03:15 <SumitNaiksatam> SridarK: so “And if we are in the current model (default) when new Routers are added to the tenant - they will need to be tracked”...
19:03:23 <SumitNaiksatam> SridarK: is something we are already doing, right?
19:03:46 <SridarK> SumitNaiksatam: yes that is one part of the complexity - we will need to do that
19:03:48 <badveli> we get a trigger
19:04:22 <SridarK> and when routers are added to the tenant - we will need to add them to be tracked
19:04:24 <SumitNaiksatam> SridarK: i meant to say that we are already doing this today, so it wont be a new implementation
19:04:36 <SumitNaiksatam> SridarK: for this part
19:04:39 <SridarK> ofcourse today we do not track this
19:04:43 <SridarK> yes
19:04:49 <SumitNaiksatam> oh we dont?
19:05:04 <SridarK> well the db does not track the routers today
19:05:14 <SridarK> one of the issues we want to fix
19:05:27 <SumitNaiksatam> ah ok, but we apply the firewall to any new router that gets added
19:05:32 <SridarK> SumitNaiksatam: yes
19:05:44 <badveli> sridark we get a trigger
19:05:58 <SumitNaiksatam> if we had to implement option 2, we would need an internal state to keep track if the firewal was in default insertion mode or not
19:06:01 <SridarK> that is for the agent
19:06:08 <SridarK> badveli: that is for the agent
19:06:33 <SridarK> SumitNaiksatam: exactly - we kind of keep the old semantics and the new one as parallel implementations
19:06:35 <badveli> yes what i am trying to say is we can add to the db
19:06:39 <SumitNaiksatam> SridarK: if it was in default mode, then we would need to take the code path as of today
19:06:47 <SumitNaiksatam> SridarK: yes, i was going there
19:07:09 <SumitNaiksatam> SridarK: ok whats option 3?
19:07:10 <SridarK> a bit complex but we can do that if we can't use our "experimental" card
19:07:30 <SridarK> ok let me get there,
19:07:36 <badveli> sridark initially i was saying this specifying a router
19:07:38 <SridarK> Option 3: Posted by Cedric in the review - why not multiple Routers ? This is similar to the previous Service Insertion proposal in Juno. We can handle migration by putting it on all Routers.
19:07:59 <SridarK> badveli: yes we can will need to trigger that from the agent msging
19:08:42 <SridarK> this will solve the migration problem as addressed in the Juno spec
19:08:49 <badveli> sridar, as i was saying we should make the router as an optional so that we do not have much complexity and fulfills what we need
19:09:12 <SumitNaiksatam> badveli: it is already optional
19:09:26 <SridarK> badveli: yes it is optional
19:09:44 <SumitNaiksatam> SridarK: seems like option 3 can be reach either via option 1 or 2
19:09:56 <badveli> the previous time we had the meeting i was saying this as i was worried about the upgradation/downgrade part
19:10:02 <SridarK> badveli: the point of this exercise was also to get specific on the router to insert and not on all routers
19:10:28 <SumitNaiksatam> SridarK: i mean as a process of evolution from option 1 (since that has only insetion for one router)
19:10:37 <SridarK> SumitNaiksatam: yes that is correct
19:11:05 <SumitNaiksatam> SridarK: but option 3 is more readily reached from option 2, since option 2 already supports on multiple routers (all in that case)
19:11:15 <SridarK> SumitNaiksatam: the point raised by Cedric was that Option 3 gives us a migration pathg
19:11:18 <SridarK> *path
19:11:45 <SumitNaiksatam> SridarK: migration path to what?
19:12:10 <SridarK> current model: 1 FW - All routers  ----> new model 1 FW but put on all routers (but tracked)
19:12:18 <SumitNaiksatam> i believe Cedric is zzele?
19:12:19 <SridarK> SumitNaiksatam: the migration path
19:12:28 <SridarK> SumitNaiksatam: i am not sure
19:12:30 <glebo> seems to me that option 2's default if no router specified is "all routers" whereas option 1's default if no router specified is "no routers"
19:12:42 <SridarK> glebo: yes correct
19:12:43 <glebo> I think we need to pick one of those as a base
19:12:44 <SumitNaiksatam> glebo: that is corect
19:12:50 <glebo> then 3 is the "add on" behavior
19:12:55 <SumitNaiksatam> glebo: yes, it boils down to that
19:13:13 <SridarK> yes, in option 1 we can specify only 1 router
19:13:13 <glebo> I like 3 with default to "no routers"
19:13:20 <SumitNaiksatam> glebo: yes, but 3 is easier to achieve through option 2 (because we would have already implemented some of it)
19:14:01 <glebo> SumitNaiksatam:  less interested in what's "easy",  more interested in what meets customer environment
19:14:08 <SumitNaiksatam> glebo: completely agree
19:14:22 <SridarK> glebo: yes definitely
19:14:25 <SumitNaiksatam> glebo: do you have customer feedback on this?
19:14:27 <glebo> SumitNaiksatam:  (but not to undervalue time to implement)
19:14:55 <SumitNaiksatam> glebo: since no one chimed on the spec, i took it at that there isnt particular customer preference on this
19:14:57 <SridarK> glebo: the point is more on the migration and backward compat aspects - if it is experimental can we look for a simpler model
19:15:00 <glebo> SumitNaiksatam:  well… really I don't see customers much wanting to even deploy on routers, i.e. at L3, to be honest
19:15:13 <SumitNaiksatam> glebo: good point
19:15:26 <SumitNaiksatam> glebo: that opens a different can of worms! ;-)
19:15:42 <SumitNaiksatam> glebo: very much in agreement though
19:15:49 <SumitNaiksatam> ok back to SridarK’s points
19:15:50 <SridarK> glebo: pls :-)
19:15:51 <glebo> customers mostly want to insert "invisibly" at L2 on the OVS
19:16:03 <glebo> SumitNaiksatam:  it does.
19:16:09 <SridarK> glebo: lets solve this problem first
19:16:12 <glebo> SumitNaiksatam:  so let me answer a different question:
19:16:32 <glebo> Q: do customers care much about the default behavior?
19:16:46 <glebo> wrt L3 insertion, that is…
19:16:54 <glebo> … yes, I think they do.
19:17:16 <SridarK> glebo: it is also with regard to backward compat
19:17:31 <Swami> SumitNaiksatam: I saw -2 on the FwaaS east-west spec are you aware about it.
19:17:31 <glebo> They don't want us default adding FW services all over the place, on every L3 instance. They would prefer to build up, rather than filter down, as I see it
19:17:48 <SumitNaiksatam> glebo: SridarK: its also with regards to addressing reviewers here, without which we cannot make progress! ;-)
19:17:56 <SumitNaiksatam> Swami: yes
19:18:14 <SridarK> glebo: yes that indeed is the point that we want to be specific rather than all over the place
19:18:22 <glebo> it's experimental today. Very little use in real world (if any?)
19:18:38 <glebo> I'm not sure we have any bakward to break.
19:18:42 <glebo> see my point?
19:18:49 <SridarK> glebo: can we break existing deployment if any ?
19:18:50 <SumitNaiksatam> glebo: so yes, that would justify the motivation for option 1 with a patch to moving to option 3
19:18:55 <SridarK> is the question
19:19:11 <glebo> let's get the architecture right for the customer, and do it now, when people have other things to fix and update anyway, before we start getting real deployment
19:19:24 <SumitNaiksatam> glebo: but people have raised the concern about backward compat on the reviews so we need a good answer
19:19:34 <SridarK> mestery: could i pls trouble u to jump in as well regarding the backward compat issues
19:19:45 <SumitNaiksatam> glebo: it will be helpful if you bring your points to the gerrit spec as well
19:19:57 <SumitNaiksatam> glebo: in response to some of the reviewers comments
19:20:04 <glebo> SumitNaiksatam:  are those reviewers aware of the sample size N of deployments, where N <= 2?
19:20:28 <glebo> SumitNaiksatam:  ack on review in gerrit.
19:20:41 <SumitNaiksatam> glebo: in fact that question asked back to the author!
19:20:50 <SumitNaiksatam> so please comment on the reviews
19:20:54 <SridarK> glebo: it is good to thrash these out now so it is well communicated to any deployers
19:21:05 <SridarK> glebo: i think that is one of the points raised in the review
19:21:12 <glebo> SumitNaiksatam:  in that effort, do any of you have deployers?
19:21:38 <SumitNaiksatam> so if i have to summarize, the team here thinks that Option 1 with a path to moving to Option 3 is preferred?
19:21:40 <glebo> We had PoC's in progress, but no deployers. Others? It would be good to validate my sense of the un-deployed nature of FWaaS today
19:22:07 <glebo> SumitNaiksatam:  yes, and we feel that because N is very low, if any
19:22:30 <SumitNaiksatam> glebo: yes
19:22:39 <SridarK> SumitNaiksatam: glebo: I think that is the assumption we went with
19:23:06 <glebo> can others pipe up now if you have customers deployed that would be wrenched by this change of behavior.
19:23:11 * glebo listening?
19:23:31 <SridarK> glebo: as a vendor -  i do not see an issue
19:23:38 * glebo hears the sound of silence
19:23:56 <SridarK> glebo: i heard from brocade that it was fine for them
19:24:52 <SumitNaiksatam> time check - we have 5 mins
19:24:59 <glebo> SumitNaiksatam:  based on this sounding, can we let the minutes reflect that the vendors are fine w/ letting go the backward compaitbilty requirement due to insignificant number of deployments?
19:25:11 <SumitNaiksatam> glebo: absolutely
19:25:12 <SridarK> glebo: pls do comment on the spec if possible
19:25:31 <SumitNaiksatam> that said some of the reviewers engaged on the spec review are not here
19:25:41 <glebo> SridarK:  will do, but I want to be able to point to a minute entry to back up my assertion of low N
19:25:44 <SumitNaiksatam> and it can be argued that such consensus should be reflected on the gerrit spec
19:26:00 <SridarK> i will reach out to mastery: and other reviewers on the spec to make sure that they are okay
19:26:01 <SumitNaiksatam> so please comment on the spec, #link https://review.openstack.org/#/c/138672
19:26:14 <glebo> SumitNaiksatam:  can you do that irc voodoo to make that point a minuted item?
19:26:19 <SumitNaiksatam> SridarK: thanks much for your persistence and effort on this
19:26:26 <SridarK> SumitNaiksatam: no worries
19:26:28 <SumitNaiksatam> glebo: good point
19:26:31 <badveli> sumit do any deployer raise fwaas bugs?
19:26:33 <glebo> ack, well done SridarK
19:26:56 <SumitNaiksatam> #agree the fwaas team (with their vendor hats) think that breaking current backward compat is not an issue
19:27:00 <glebo> SumitNaiksatam:  that way I can point to it easily in my review
19:27:08 <badveli> my point is based on that can we have any idea of the deployments
19:27:16 <SumitNaiksatam> #agreed the fwaas team (with their vendor hats) think that breaking current backward compat is not an issue
19:27:27 <glebo> SumitNaiksatam:  thx, m8
19:27:33 <SumitNaiksatam> glebo: ;-)
19:28:08 <SumitNaiksatam> the above is in context of those who are present here
19:28:09 <SridarK> ok so i will go back to spec and state this
19:28:30 <SumitNaiksatam> there might be others who are outside this meeting and might have a different opinion based on their deployments
19:28:55 <badveli> yes
19:29:00 <SumitNaiksatam> SridarK: do you have enough agreement here to wrap up the spec?
19:30:11 <SridarL> *sorry got bounced and my typing is horrible now i have a new name
19:30:18 * SumitNaiksatam thinks SridarK has figured out a way to clone!
19:30:18 <glebo> SumitNaiksatam:  sure, always might be others. Did you have particular vendor in mind?
19:30:48 * SumitNaiksatam expect at least 26 Sridars now! great for the fwaas team! ;-P
19:31:02 <SridarL> :-)
19:31:05 <SumitNaiksatam> glebo: perhaps those who have commented on the reviews
19:31:19 <SumitNaiksatam> glebo: will have to check their affiliations ;-P
19:31:41 <glebo> SumitNaiksatam:  k
19:31:47 <SumitNaiksatam> ok we got wrap here folks
19:31:52 <SumitNaiksatam> SridarK: hope this was helpful
19:32:01 <SumitNaiksatam> thanks all for your input and participation
19:32:13 <badveli> no service spec
19:32:17 <SridarL> yes certainly - i will await response from reviewers
19:32:24 <SumitNaiksatam> lets keep it going on the gerrit specs and the mailers
19:32:28 <badveli> sumit quickly wanted to check what should we do?
19:32:52 <SumitNaiksatam> badveli: i think you are doing all the right things
19:32:57 <SumitNaiksatam> not sure what else can be done
19:33:10 <badveli> thanks sumit
19:33:20 <SumitNaiksatam> i will end the meeting here, we can continue the discussion on #openstack-fwaas
19:33:21 <glebo> mestery:  ideas for badveli and I on the service spec?
19:33:38 <glebo> no reviews as of yet
19:33:48 <glebo> 4 th round trying to get this into a release
19:34:04 <badveli> i have the code ready
19:34:33 <glebo> mestery:  there?
19:36:12 <SumitNaiksatam> glebo: wait some more?
19:36:20 <glebo> when the services spec got bounced from Juno,
19:36:23 <badveli> thanks glebo, i think no response
19:36:44 <glebo> badveli and I asked PTL and upward why. the
19:37:09 <glebo> answer was that we didn't get the "right" reviewers to review, even though the written process was followed to a "T", so
19:37:24 <glebo> we asked which reviewers specifically were missing,
19:37:50 <glebo> the answer was someone representing API and someone from security
19:37:59 <glebo> so we asked, who specifically
19:38:18 <glebo> and we were told, "we'll identify them in kilo"
19:38:30 <glebo> and we've asked in 4 emails, with no response,
19:38:37 <glebo> so not sure how to proceed.
19:38:43 <glebo> SumitNaiksatam:  guidance?
19:39:16 <SumitNaiksatam> glebo: i have reviewed the spec in the past, and have +2’ed as well
19:39:34 <SumitNaiksatam> glebo: however the +2 was overriden
19:40:06 <SumitNaiksatam> glebo: at this point i believe we have exhausted most available optiopns
19:40:42 <SumitNaiksatam> since the neutron drivers team is deciding which specs to approve or not, its difficult to discuss here
19:40:46 <SumitNaiksatam> we are 10 mins over
19:40:51 <SumitNaiksatam> so i will close the meeting
19:40:55 <SumitNaiksatam> thanks all and by
19:40:57 <SumitNaiksatam> bye
19:40:57 <glebo> ack
19:41:02 <SumitNaiksatam> #endmeeting