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