16:02:31 <rkukura> #startmeeting networking_ml2
16:02:32 <openstack> Meeting started Wed May 28 16:02:31 2014 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:35 <openstack> The meeting name has been set to 'networking_ml2'
16:03:05 <rkukura> #topic Announcements
16:03:18 <rkukura> I don’t have any announcements today - anyone else have any?
16:03:44 <Sukhdev> Please be sure to sign up for mid-cycle meetings
16:04:19 <shivharis> Can one attend these online?
16:04:25 <rkukura> #link agenda: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_May_28.2C_2014
16:05:01 <banix> shivharis: doubt it
16:05:12 <rkukura> shivharis: Not sure
16:05:12 <Sukhdev> shivharis: do not know about the logistics - it may be a good question to ask from Kyle
16:05:13 <shivharis> banix: k
16:05:32 <rkukura> moving on…
16:05:42 <trinaths> can there be some audio for mid-cycle meeting
16:05:59 <rkukura> #topic Action items from last week
16:06:12 <rkukura> 3 AIs are in the agenda
16:06:16 <shivharis> i'll get details from Kyle and get back
16:06:18 <Sukhdev> Based upon Montreal experiance - no, nothing remote
16:06:33 <rkukura> shivharis: can coer his in the Bugs section of the agenda
16:06:51 <rkukura> I’ll cover mine in the specs section
16:07:08 <shivharis> Bugs...
16:07:09 <banix> and I will cover mine a bit later (in the agenda)
16:07:10 <rkukura> And banix has a section in the agenda for his
16:07:38 <rkukura> Any other action items to followup on?
16:08:05 <rkukura> #topic ovs-firewall-driver discussion
16:08:10 <asadoughi> hi
16:08:14 <asomya> rkukura: Can you track the type driver refactor in the agenda as well
16:08:34 <rkukura> asadoughi: do you want to update us?
16:08:37 <asadoughi> #link https://review.openstack.org/#/c/89712/ ovs-firewall-driver
16:09:08 <asadoughi> so, ran into an obstacle with the blueprint dealing with behavioral api parity with iptables
16:09:11 <rkukura> asomya: Didn’t include type driver specifically, but we can touch on it in the specs section
16:09:22 <rkukura> asomya: We can add a topic for next week if needed
16:09:46 <asadoughi> the question i wanted to bring up is, how does the commmunity feel about having an 80% solution today versus waiting for conntrack in 2015 and having a 100% solution in a year?
16:10:27 <banix> asadoughi: can you briefly say what is the api parity issue
16:10:43 <Sukhdev> asadoughi: I favor 80% today, with a plan to reach 100% later
16:11:03 <slogan> Are there use cases that absolutely require the 80% case now? If not, perhaps waiting is good?
16:11:25 <asadoughi> banix: sure, ovs is stateless for non-tcp flows and cannot emulate iptables' RELATED feature without conntrack
16:11:27 <Sukhdev> slogan: good point
16:11:50 <banix> asadoughi: got it. thanks.
16:11:54 <yamamoto> asadoughi: imo what's lacking is a way to expose functionlity differences to users
16:12:50 <yamamoto> ie. a way to tell a user what he is using is 80%.
16:12:51 <vthapar> or to put a different spin, does a firewall driver have to be stateful?
16:13:17 <chuckC> breaking people's existing security rules might be considered rude, but what are benefits to user for ovs implementation?
16:13:32 <asadoughi> yamamoto: right, i've been thinking on that.. we could add another attribute to the api or fork it, but i'm not feeling that those are great solutions. to refresh others, we also considered documentation and runtime errors.
16:14:14 <vthapar> chuckC: in theory, performance benefits as we no longer need to use linux bridges.
16:14:31 <slogan> yamamoto: documentation I suppose. Is 80% solution hidden by an abstraction such that 100% does not require changes to what already exists, or is a rewrite of interfaces needed?
16:14:48 <yamamoto> vthapar: lack of detailed semantics definitions is a problem in sg...
16:14:58 <vthapar> chuckC: I am trying to get performance numbers, but other work commitments are holding me back.
16:15:26 <chuckC> so would we consider a config option for iptables vs ovs?  (not that I really like that idea)
16:15:39 <rkukura> asadoughi: So would this be a provider deployment decision to provide reduced SG functionality? Would the SG API need to reject requests that not all firewall-drivers could enforce?
16:15:54 <asadoughi> chuckC: right, that's what i meant by additional attribute on the api. don't think it's a winning idea, either.
16:16:21 <yamamoto> rkukura: if it rejects requests loudly enough, being 80% should be fine.
16:16:59 <vthapar> I believe it will be a config option, firewall_driver which is currently set to OVSHybridFirewallDriver, can use somethinig like OVSFirewallDriver
16:17:11 <yamamoto> but afaik there's no mechanism to do so
16:17:11 <asadoughi> rkukura: essentially, yes at this point. figuring out the intent based on current api is difficult. we have to brainstorm some additional attributes to make it a more explicit difference.
16:17:15 <rkukura> yamamoto: That’s what I was thinking. Maybe the SG API needs a configuration option that turns off support for rules requiring conntrack
16:17:21 <shivharis> what are user options after the loud rejects?
16:18:06 <chuckC> shivharis: change config or don't use stateful rules?
16:18:14 <yamamoto> shivharis: give up or change to iptables or reconsider rules or..
16:18:15 <rkukura> vthapar: Don’t forget that ML2 support multiple types of MDs, so not all nodes necessarily use the same firewall driver.
16:19:03 <asadoughi> rkukura: interesting, are you suggesting --no-conntrack could be an option for neutron cli?
16:19:20 <yamamoto> i have a vague plan to implement a firewall driver for ofagent, which has no hope to use rich features like conntrack.
16:19:23 <rkukura> asadoughi: Not for the CLI, for the provider deploying neutron
16:19:38 <vthapar> rkukura: security groups are implemented at nodes, so each node can use a different firewall_driver too.
16:19:54 <asadoughi> rkukura: ah ok
16:20:13 <vthapar> yamamoto: I was about to mention that, OFAgent will not even have option for reflexive learning till Openflow supports it
16:20:22 <rkukura> I think we’d need a way for the provider to determine what semantics SGs in their cloud have, which would have to be the least-common-denominator of all nodes’ capabilities
16:20:40 <chuckC> rkukura: +1
16:20:54 <yamamoto> rkukura +1
16:21:07 <Sukhdev> rkukura: agree - but. how to provide that?
16:21:33 <rkukura> My initial thought is that this would be a config option for the SG API mixin.
16:21:34 <shivharis> least common denominator is iptables then?
16:22:02 <rkukura> shivharis: I think iptables is more capable than ovs-firewall-driver for now
16:22:02 <chuckC> I thought ovs was 80%
16:22:14 <vthapar> shivharis: no. it would be OVS, I expect OFAgent to be least common.
16:22:46 <rkukura> So if a deploymen included nodes that could not enforce stateful UDP rules, creating these rules via the SG API would need to fail
16:23:34 <vthapar> is there an option in iptables to disable statefullness?
16:23:41 <chuckC> so need a way for agent failure to cause api failure?
16:24:18 <rkukura> chuckC: I think that gets difficult, since the SG can be shared among many port bound using different agents
16:24:37 <asadoughi> we'd configure minimum-security-groups-api-behavior at server level so that it can make the api validation decisions
16:25:04 <chuckC> asadoughi: yes, much better
16:25:07 <rkukura> I’m just suggesting a simple deployment time boolean config option for whether the SG API mixin supports rules that require connection tracking, or rejects them
16:25:39 <banix> asadoughi:  rkukura makes sense
16:25:45 <rkukura> seems like a possible way forward, but needs discussion in the review
16:25:53 <chuckC> rkukura: if it's true, and a compute node without the capability is added?
16:26:32 <Sukhdev> asadoughi: can you capture all the points discussed here into the review and let others chime and hopefully get a closure?
16:26:36 <rkukura> chuckC: That’s a tough situation for the deployer that they may need to avoid
16:26:42 <banix> chuckC: asking hard questions :)
16:26:43 <asadoughi> Sukhdev: will do
16:26:52 <rkukura> Ready to move on?
16:26:57 <shivharis> what if a vm moves from one node with capability to no-capabiity?
16:27:03 <Sukhdev> rkukura: you just read my mind :-)
16:27:10 <rkukura> #topic Modular L2 agent: planning
16:27:15 <banix> Please have a look at the etherpad (link in the agenda); Just an outline as how to go about the modular l2 agent work. Basically, have different drivers for different functions such as base l2, sec group, l2pop/tunnel, etc similar to how the ml2 plugin is organized
16:27:19 <rkukura> banix: Do you want to drive this?
16:27:27 <banix> #link https://etherpad.openstack.org/p/modular-l2-agent-outline
16:27:56 <yamamoto> i'm not sure what the driver context would look like
16:28:05 <banix> so before taking this to the ML and the spec review wanted to get the opinion here and see if this is sensible
16:28:31 <banix> so let’s start from using drivers for different functionalities
16:28:41 <Sukhdev> banix: at high level, it makes a lot of sense
16:29:07 <banix> wrt rpc, each driver may need its own rpc is taht reasonable?
16:29:36 <rkukura> banix: At quick glance it looks like a good start, but it might help to outline how existing functionality fits this model in a bit more detail, and also use cases that this enables
16:29:43 <emagana> banix: can you explain that a little bit further?
16:30:27 <banix> So if we want to have a driver that deals with l2pop or a new driver for a new extension then that driver may need to setup a new set of rpc callbacks
16:31:04 <nlahouti> banix: wrt rpc, yes
16:31:46 <banix> nlahouti: yes as in yes that’s reasonable?
16:31:56 <nlahouti> banix: yes
16:32:06 <nlahouti> banix: it is reasonable.
16:32:13 <banix> nlahouti: ok thx
16:32:38 <banix> rkukura: yes will do
16:32:56 <banix> emagana: did i answer your question above?
16:33:39 <banix> Sukhdev: ok. thx.
16:33:49 <emagana> banix: Yes, I do still need more context but I will do my proper homework!!  :-)  Thanks!
16:34:11 <banix> with respect to having a resource manager for accessing shared resources, does that sound like a good starting point? I
16:34:26 <Sukhdev> emagana: me too - I need to do my homework and read it carefully :-)
16:34:34 <banix> I will fill in details and code to experiment
16:34:48 <rkukura> banix: Do you think this is likely to be completed during juno and replace the existing agents?
16:35:02 <Sukhdev> banix: a picture to show the flow will be very helpful
16:35:03 <emagana> Sukhdev: sounds like a good topic for a meetup  ;-)
16:35:13 <rkukura> Or is it a first step during juno, but needing more work in K?
16:35:32 <banix> rkukura: I think so; at least for a couple of agents; what do you think?
16:35:41 <Sukhdev> emagana: perhaps!!
16:36:25 <shivharis> I think we should shoot for atleast 1-2 agents for Juno, the RPC contracts and callback framework will get fleshed out
16:36:29 <banix> Sukhdev: emagana: sure will add picture more info
16:36:36 <emagana> banix: Thanks!
16:36:38 <banix> yamahata: yes have to work out the details
16:36:53 <Sukhdev> banix: thanks - that will help a lot
16:37:02 <rkukura> banix: I think its possible, but it depends on people being available to do the wok
16:37:30 <rkukura> anything else on modular agent?
16:37:40 <banix> so before we put out a spec, what specifically will we need?
16:37:40 <rkukura> if not…
16:38:57 <banix> Let me do a bit more work and discuss next week (and possibly ML)
16:38:59 <rkukura> banix: A plan that gets to parity with at least one exisitng agent is needed
16:39:06 <rkukura> ok
16:39:13 <banix> rkukura: yes sure starting with ovs agent
16:39:14 <manishg> banix: some background and reference to design summit would help folks ramp up on this.
16:39:28 <banix> manishg: sure
16:39:31 <rkukura> #topic Bugs
16:39:31 <manishg> i.e. the motivations, etc. for it.
16:39:48 <rkukura> shivharis: I’ll let you drive the bugs discussion
16:40:06 <shivharis> I have put a list of 5 bugs only on the agenda
16:40:36 <shivharis> I am still working out with the infra team to get access to changing bug priortiy.
16:41:04 <shivharis> will do so when i hear back Kyle and anteaya are working on that...
16:41:13 <shivharis> so starting with the first bug:
16:41:13 <yamamoto> i tagged ofagent bugs with ml2
16:41:21 <shivharis> https://bugs.launchpad.net/neutron/+bug/1276391
16:41:31 <shivharis> bob?
16:41:39 <rkukura> An updated patch is in review at https://review.openstack.org/#/c/82945/
16:42:01 <shivharis> anyone to ping for reviews?
16:42:32 <rkukura> This had been reviewed extensively at the end of icehouse, so we need to get those reviewers to look again
16:42:50 <shivharis> i'll followup with them then...
16:42:58 <rkukura> Thanks
16:43:13 <shivharis> banix:https://bugs.launchpad.net/neutron/+bug/1227336
16:43:17 <banix> so this deals with failure in postcommit operations;  a stop gap patch was merged in Icehouse; for a more comprehensive solution Sukhdev and rkukura had the “sync” discussion
16:43:53 <banix> i think we can close this bug as fixed and wait for the sync work. makes sense?
16:43:54 <shivharis> does this overlap with sync stuff, sukhdev?
16:44:14 <Sukhdev> shivharis: yes it does
16:44:44 <shivharis> can you help bring closure to this? "will not fix etc"
16:44:55 <Sukhdev> shivharis: we need to look into the workflow stuff which Mark presented to see how can that be leveraged
16:44:55 <banix> Sukhdev: are you persuing that work
16:45:00 <rkukura> I think we should close this bug, and use a BP/spec to address sync, possibly via taskflow as discussed at the summit
16:45:16 <banix> rkukura: i agree
16:45:58 <shivharis> banix: to bring clouse to this
16:45:59 <Sukhdev> rkukura: +1
16:46:12 <shivharis> https://bugs.launchpad.net/neutron/+bug/1246737   Oleg?
16:46:13 <banix> shivharis: will do
16:46:33 <shivharis> I am not sure Olen is online.. will ping him offline..
16:47:05 <shivharis> https://bugs.launchpad.net/neutron/+bug/1224978 : romil
16:47:23 <Romil> Need more time to look into this bug
16:47:41 <emagana> Is there any specific bug that needs one more core reviewer?
16:47:51 <Romil> I am also waiting for the document to enble ML2 multi-segment network
16:48:04 <emagana> I know all of them but if anything needs extra attention, let me know!
16:48:08 <Romil> I could n't find any info on this
16:48:21 <shivharis> emagana: will need that help.
16:48:55 <shivharis> romil: if you need help please let me know, i will try to help out
16:48:56 <Romil> The last mail I could find is from Kyle in this to provide the document
16:48:57 <emagana> shivharis: free feel to ping me on IRC and discuss any patch
16:49:03 <Romil> thanks :)
16:49:24 <Romil> http://www.gossamer-threads.com/lists/openstack/dev/35217
16:49:31 <shivharis> https://bugs.launchpad.net/neutron/+bug/1260598:
16:49:34 <rkukura> Romil: Feel free to ping me on IRC regarding that bug - I remember it now
16:49:56 <Romil> sure...thanks a lot  Bob :)
16:50:28 <shivharis> https://bugs.launchpad.net/neutron/+bug/1260598    last one
16:50:29 <Sukhdev> Time Check: 10 min. remaining
16:51:08 <shivharis> Thats all from me, I have a general comment regarding a lot of bugs regarding need unit tests
16:51:13 <shivharis> will address next time
16:51:27 <shivharis> I am done for now, more next time
16:52:22 <rkukura> #topic Spec reviews
16:52:51 <rkukura> As per my action item, I moved the list of specs from the agenda to an etherpad
16:52:56 <Sukhdev> I was busy reviewing the specs last week
16:53:03 <rkukura> #link https://etherpad.openstack.org/p/Neutron_ML2_Juno_Spec_Tracking
16:53:15 <Sukhdev> rkukura: that is really cool - it helps a lot
16:53:24 <nlahouti> sukdev: can we get this one approved:https://blueprints.launchpad.net/neutron/+spec/vdp-network-overlay
16:53:33 <rkukura> On a couple of these, I tried to add info on reviewers and status
16:54:00 <nlahouti> rkujura: that would be great
16:54:10 <rkukura> I’m thinking that each spec should have two sub-team reviewers happy with it before we recruite core reviewers
16:54:15 <nlahouti> rkukura: that would be great
16:54:28 <Sukhdev> nlahouti: I will review it again later today and approve it
16:54:49 <rkukura> So as sub-team members review ML2-related specs, can you update this etherpad?
16:54:58 <nlahouti> sukhdev:Thanks a lot
16:55:09 <nlahouti> we have 4 more BP.
16:55:33 <rkukura> The point of the etherpad is to have an easy what to see which specs need reviewers, which are ready for core review, etc.
16:55:36 <Sukhdev> rkukura: i reviewed several over the weekend, I will add my name on the etherpad
16:55:47 <nlahouti> one question for python-neutronclient I added one of neutron drivers team a  approver is that correct?
16:55:47 <rkukura> Sukhdev: thanks!
16:56:38 <rkukura> nlahouti: I think the core reviewer that approve the spec should update the BP to approved
16:57:21 <nlahouti> rkukura: does it mean for python-neutronclient we need to file neutron-spec?
16:57:33 <rkukura> We don’t have time now, but next week, I’d like to walk through the etherpad and identify specs that need reviewers or have contentious issues
16:57:54 <rkukura> nlahouti: I’m not sure about that - maybe its covered by the neutron spec
16:58:10 <rkukura> Anything else on spec reviews before we move on?
16:58:28 <nlahouti> rkukura:  I have this one:https://blueprints.launchpad.net/python-neutronclient/+spec/python-neutronclient-for-cisco-dfa
16:58:57 <nlahouti> rkukura:  and also one for extension support:https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions
16:59:24 <shivharis> rkukura: need high level sorting of this list before we assign reviewers?
16:59:36 <rkukura> nlahouti: Lets link these BPs into the specs etherpad, as I did for a few of them
17:00:01 <rkukura> shivharis: I was going to add the priorities from the BPs, but they are not consistently applied yet
17:00:02 <nlahouti> rkukura: ok. make sense
17:00:29 <rkukura> We are out of time
17:00:40 <rkukura> Anything else?
17:00:41 <banix> bye everybody
17:00:42 <Sukhdev> great meeting, folks...
17:00:42 <shivharis> rkukura: add as action item for time...
17:00:52 <chuckC> bye
17:00:54 <yamamoto> bye
17:00:56 <nlahouti> bye
17:01:01 <Sukhdev> bye
17:01:03 <trinaths> bye
17:01:05 <rkukura> shivharis: Which action?
17:01:16 <shivharis> add priorities...
17:01:31 <rkukura> #action rkukura to put priorities in specs etherpad
17:01:37 <rkukura> #endmeeting