16:02:32 <rkukura> #startmeeting networking_ml2
16:02:32 <openstack> Meeting started Wed Aug 13 16:02:32 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:34 <amotoki> hello
16:02:36 <openstack> The meeting name has been set to 'networking_ml2'
16:03:02 <rkukura> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Agenda
16:03:18 <rkukura> #topic Announcements
16:03:37 <emagana> hi all!
16:03:50 <rkukura> The Juno feature proposal deadline is coming up next week, Thursday I think
16:04:16 <rkukura> This is when all BP implementation patches need to at least be in review
16:05:06 <rkukura> I know that some are not yet, at least my hierarchcial-port-binding patch. Any others of medium priority or above?
16:05:38 <shivharis> hi, sorry late.
16:05:45 <Sukhdev> I am working on one and hope to push later today
16:06:13 <rkukura> OK, we can discuss the individual BPs/patches later in the agenda
16:06:31 <rkukura> #topic Action Items
16:06:36 <rkukura> #undo
16:06:36 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x20f6710>
16:06:45 <rkukura> Any other announcements?
16:07:32 <rkukura> guess not
16:07:38 <rkukura> #topic Action Items
16:08:00 <rkukura> rkukura to add comments to https://bugs.launchpad.net/neutron/+bug/1311470 (comments added by rkukura)
16:08:01 <uvirtbot> Launchpad bug 1311470 in neutron "Disabling an ML2 type driver can leave orphaned DB records" [Medium,Confirmed]
16:08:21 <shivharis> comments were added, but we need to get to a resolution.
16:08:30 <rkukura> I added a comment suggesting maybe this is best dealt with via documentation
16:08:48 <shivharis> rkukura: thx for the comments added
16:09:00 <rkukura> Seems to me that the operator should not unconfigure a type driver while network segments of that type exist
16:09:31 <rkukura> We could document SQL queries to determine if any such segments do exist, so these networks can be deleted first
16:09:48 <shivharis> so we want to document that not to remove type driver (absolutly or based on logs)
16:10:22 <shivharis> assuming that the db is consulted and a log entry is created
16:10:24 <rkukura> My suggestion is to document not removing a type driver when segments of that type exist
16:10:35 <rkukura> A DB query seems like the best way to determine that
16:10:58 <Sukhdev> emagana: perhaps you may want to add it in the documentation
16:11:12 <shivharis> what if we make it even more stringent that no type driver should be un-configed - what gives?
16:11:14 <emagana> Sukhdev: good one!
16:11:45 <rkukura> shivharis: I’m not sure we really need to prohibit ever un-configuring a type driver
16:11:49 <emagana> Sukhdev & rkukura: Do you want me to open a bug in docs?
16:12:28 <rkukura> emagana: If the consensus is that this should be handled via docs, then  I guess that makes sense
16:12:32 <shivharis> rkukura: i am trying to determine what is the down side of not being able to un-config a type driver
16:12:41 <Sukhdev> emagana: we need to figure out what best way to document it
16:13:04 <emagana> Sukhdev: sorry, I was behind in the discussion, of course!
16:13:10 <amotoki> IMO it is rare to change type driver configruation in production env, so adding it to docs sounds reasonable to me.
16:13:23 <rkukura> Unconfiguring a type driver could be useful to prevent admins from creating provider networks of that type, but not much else
16:13:25 <Sukhdev> emagana: for example - do not do it. But, we have to also suggest a way to clean things
16:13:47 <emagana> Sukhdev: +1
16:14:18 <rkukura> We could also document clearing the allocation table completely after un-configuring the driver
16:14:19 <shivharis> i would vote for documenting that a type driver cannot be un-configed - operator reading logs etc is too much of a hassle
16:14:42 <rkukura> I’m not suggesting to use the logs, I’m suggesting a DB query
16:15:08 <rkukura> shivharis: I agree using the logs would be unworkable
16:15:47 <rkukura> Regardless of the details, are we agreeing this bug should be addressed via docs rather than code changes?
16:16:06 <shivharis> rkukura: yes, docs it is
16:16:10 <Sukhdev> rkukura: what happens on the deletes if a type driver is un-configured? can the resource be deleted from CLI?
16:16:26 <emagana> is kevinbenton around?
16:17:04 <rkukura> Sukhdev: Not sure - may get exception when driver can’t be found for the segment type
16:17:10 <shivharis> i still like the simplicity of not being able to un-config (IMHO)
16:17:48 <Sukhdev> rkukura, emagana: so, in that case we have to document as to best ways to clean up the DB records
16:17:58 <rkukura> shivharis: Other than docs, how would we prevent un-configing?
16:18:25 <shivharis> the docs can say that we do not allow un-config
16:19:02 <emagana> Wouldn't be better to have a mechanism that always uses the old type driver even if it is disable until a conversation process is in place...  (just ideas)
16:19:09 <rkukura> Do we have agreement this should become a docs bug, or does anyone think a code change is in order?
16:19:27 <emagana> rkukura: Does my previous idea sound crazy?
16:19:40 <Sukhdev> shivharis: During init, we could check the DB and match against the installed type drivers - if mismatch, fail init
16:20:34 <shivharis> in my case there needs some code change that disallow this operation? I am also willing to go with the consensus
16:20:38 <emagana> Sukhdev: I like that! It is protecting for a misconfiguration as well
16:20:40 <rkukura> Given that we use entry points for drivers and config to load drivers, I’m not sure we have a way of preventing the unconfiguration of the loading of the driver
16:21:24 <rkukura> We could add a way to load the driver but disable it from being used for new segments
16:21:40 <Sukhdev> my understanding is that to un-configure a type driver, one has to restart - hence, failing init will work
16:21:41 <shivharis> rkukura: can u please make the final decision.. i am ok with either
16:21:50 <rkukura> Sukhdev: The check at init time may be worthwhile
16:22:06 <emagana> shivharis: I think we are working on that!
16:23:01 <rkukura> #action rkukura to add comment to https://bugs.launchpad.net/neutron/+bug/1311470 suggesting we check at init for segments without configured drivers
16:23:03 <uvirtbot> Launchpad bug 1311470 in neutron "Disabling an ML2 type driver can leave orphaned DB records" [Medium,Confirmed]
16:23:12 <emagana> IMHO (this is why I dont attend all meetings) a missing type driver in the configuration should let to a fail starting the server!
16:23:16 <Sukhdev> rkukura, emagana, shivharis: I propose that we split this bug into two - a documentation bug, as well modification to init() function
16:23:24 <rkukura> #action emagana to file doc bug corresponding to https://bugs.launchpad.net/neutron/+bug/1311470
16:24:01 <emagana> emagana: This is why you should not attend meetings! You end up with action items!
16:24:22 <Sukhdev> emagana: you are funny!!! and I like that :-)
16:24:50 <rkukura> Are we ready to move on?
16:24:58 <shivharis> yes
16:25:03 <Sukhdev> yup
16:25:08 <rkukura> https://bugs.launchpad.net/neutron/+bug/1311470
16:25:13 <uvirtbot> Launchpad bug 1311470 in neutron "Disabling an ML2 type driver can leave orphaned DB records" [Medium,Confirmed]
16:25:17 <rkukura> sorry
16:25:21 <emagana> Sukhdev: Just enjoying life!
16:25:32 <rkukura> shivharis to track bug https://bugs.launchpad.net/neutron/+bug/1352801 (carl baldwin added comments)
16:25:33 <uvirtbot> Launchpad bug 1352801 in neutron "l2pop to stop using tuples everywhere" [Medium,In progress]
16:25:48 <rkukura> shivharis: Any update on this?
16:25:52 <shivharis> next bug - introduced by dvr - reversed by carl b
16:26:08 <rkukura> shivharis: to track bug https://bugs.launchpad.net/neutron/+bug/1224978 (unit tests have been added, now need reviewers)
16:26:10 <uvirtbot> Launchpad bug 1224978 in neutron "port binding on multi segment networks could lead to agent misconfiguration" [Medium,Fix committed]
16:26:16 <shivharis> regression, will soon be ready to close
16:26:39 <rkukura> Do we need to keep action items on these two?
16:26:49 <shivharis> need code reviewer - anyone?
16:27:27 <shivharis> actually we should drop them as actions now. actions have been taken already
16:27:37 <banix> shadower: will do
16:27:44 <banix> shivharis: will do
16:28:59 <shivharis> anyone ready to code review the last one?
16:29:10 <rkukura> I will
16:29:17 <emagana> same here!
16:29:29 <shivharis> thanks,  lets move on
16:29:53 <rkukura> #topic Bugs
16:30:10 <rkukura> I see the comment to skip it this time
16:30:16 <shivharis> skip bugs this time, last time we needed more time for code reviews
16:30:29 <shivharis> will come back again next week
16:30:32 <rkukura> #topic Code Reviews
16:31:02 <rkukura> #link https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
16:31:03 <sadasu_> Need reviewers for https://review.openstack.org/#/c/74134/7 esp cores
16:31:42 <Sukhdev> The wiki has been updated - please check to ensure it reflects your BP information correctly
16:31:44 <rkukura> Did the priority column in the table disappear?
16:32:20 <Sukhdev> rkukura: that was associated with the Spec priority - may have disappeared during migration
16:32:31 <banix> probably we didnt have priority for code reviews; should add
16:33:21 <Sukhdev> rkukura: I just noticed the priority is there - but, only for specs - so, no migration error :-)
16:33:42 <Sukhdev> banix: correct - perhaps we should add
16:33:54 <banix> will do after the meeting
16:33:58 <rkukura> Lets add the priority to the code review section as well, so we can be sure to cover the high and medium ones during the meeting
16:34:00 <Sukhdev> rkukura: may want to assign an action
16:34:13 <rkukura> volunteer? banix?
16:34:18 <banix> rkukura: yes
16:34:27 <banix> rkukura: i will do it
16:34:39 <rkukura> #action banix to add priority column to code review table in https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
16:34:47 <rkukura> thanks
16:34:52 <Sukhdev> banix: Thanks - I was standing in line as a back up :-):-)
16:34:59 <banix> np
16:35:33 <rkukura> asomya1: Do you want to discuss the type driver work?
16:36:18 <asomya1> rkukura: yes
16:36:42 <asomya1> Rkukura and i discussed the scope of the refactor yesterday and reduced it just to support dynamic segments in the Juno release
16:36:49 <asomya1> Majoe refactor will be implemented in Kilo
16:37:24 <Sukhdev> asomya1: makes sense and reduces risk
16:37:39 <asomya1> The current scope entails adding a few columns to the network_segments table and adding a couple of methods in the type manager
16:38:14 <rkukura> I think asomya1 may move logic to the TypeManager in this round, but defer making the TypeDrivers manage their own segment properties in the DB
16:38:26 <rkukura> asomya1: When do you expect an updated/new patch?
16:38:34 <Sukhdev> asomya1: do you have a writeup as to what columns will be added?
16:38:35 <asomya1> rkukura: that's correct, we;ll move segment management to the typemanager for now
16:39:04 <asomya1> sukhdev: The original spec that got approved had a lot of fields but now it's severely reduced.
16:39:12 <asomya1> I'll try to cook up a short google doc on the changes
16:39:30 <rkukura> asomya1: Thanks!
16:39:30 <asomya1> I also wanted to roll in distinguishing between a tenant and provider network by introducing a boolean in the segments table, want to find out how others in the community feel about this?
16:39:54 <padkrish> asomya: +1
16:40:15 <rcurran> asomya1, an obvious +1 from me
16:40:17 <rkukura> asomya1: Would you somehow make that boolean visible to mechanism drivers?
16:40:26 <Sukhdev> asomya1: will it require modifications in the Mech drivers?
16:40:31 <asomya1> rkukura: yeah, we'll return it the the segments dict
16:40:48 <asomya1> sukhdev: nope, it'll be an extra field in the segments dict.. existing info doesn't get affected.
16:41:04 <Sukhdev> asomya1: good
16:41:06 <asomya1> Upto the mech drivers if they want to consume that bit
16:41:13 <rkukura> asomya1: And have you figured out whether “partial spec” segments are considered provider or not?
16:41:45 <asomya1> rkukura: Not yet, I'm starting a new patch for this work.. just modified the models etc.. moving onto the partial segments stuff
16:42:08 <Sukhdev> asomya1, rkukura: So, the network context that comes down to Mech drivers will have these additional columns to support dynamic segments, right?
16:42:24 <rkukura> My preference would be to deal with this as two separate patches, both which could make Juno
16:42:35 <asomya1> sukhdev: dynamic segments probably will go in the port context
16:43:01 <rkukura> The patch I'
16:43:24 <asomya1> rkukura: I can do two patches, is it acceptable against a single BP?
16:43:36 <Sukhdev> asomya1: sounds good - as long as it does not require last minutes updates from mech drivers, I am good with it
16:43:39 <rkukura> The patch I’m working on adds PortContext.segments_to_bind property that will have either static or dynamic segments, depending on the level in the hierarchy
16:44:00 <rkukura> asomya1: Multiple patches per BP is encouraged
16:44:13 <asomya1> rkukura: great , then i'll move it to a separate patch :)
16:44:43 <rkukura> Next is my hierarchical port binding work
16:44:53 <rkukura> I’ve got a patch started
16:46:08 <rkukura> I’m now pretty sure we need to store the segment_id and driver for each level of the binding in the DB, so I need to change the model a bit.
16:47:14 <Sukhdev> rkukura: how do you get the driver info? The registered drivers have to provide additional attributes?
16:47:14 <rkukura> But the DVR-related port binding changes have resulted in two different port binding tables.  So armax and I have been looking into how to clean up the port binding schema
16:47:51 <rkukura> I’ll be introducing a new config variable to describe port bindings as described in the spec.
16:48:39 <rkukura> Anyway, I expect to have this worked out soon, and a patch in review (maybe WIP) at the end of this week..
16:49:02 <rkukura> kevinbenton: Should we discuss external ports?
16:49:11 <padkrish> i have added cases in the google docs for hierarchical binding, this can act as a starting point for discussion. So, encourage folks to go through it and provide comments.
16:49:55 <banix> pdmars: link?
16:50:01 <banix> padkrish: link?
16:50:11 <padkrish> banix# https://docs.google.com/document/d/1rqTHiLgV_3bw3nbiggY_xM-xETDsw0aK5rZZVXopSU8/edit?pli=1#heading=h.3gt7q76urxew
16:50:17 <banix> padkrish: thanks
16:50:32 <Sukhdev> rkukura: time check - there is a new item on the agenda proposed by Andreas - we need to give him some time
16:50:42 <rkukura> Sukhdev: thanks
16:51:02 <banix> hi scheuran
16:51:21 <scheuran> hi
16:51:24 <rkukura> Any other non-vendor-specific BPs that we need to discuss right now?
16:52:11 <nlahouti> rkukura: extension-in-ml2 that I'm going to talk to Mark about it
16:52:22 <banix> Andreas scheuran: can you briefly explain your question
16:52:42 <rkukura> nlahouti: right, I was just going to mention that. Let me know if I can help.
16:52:56 <scheuran> banix: yes, sure. thanks for the time
16:52:57 <nlahouti> rkukura: sure
16:53:14 <rkukura> #topic: Support for network adaptors that do not allow promiscuous mode (relevant for flat & vlan networking)
16:53:29 <scheuran> I wanted to get some feedback if we could add support for networks adaptors that do not support promisc mode into exsiting ml2 drivers/agents
16:53:36 <banix> Sukhdev: in case you didnt know Andreas was scheuran :)
16:54:00 <Sukhdev> banix: I did not know - but, now I do - thanks
16:54:26 <scheuran> Promisc mode is always required when not having a tunnel, so in vlan or flat mode
16:54:44 <banix> rkukura: sorry i may have jumped the gun; thught we got to andreas topic
16:54:57 <rkukura> banix: no problem
16:55:02 <scheuran> What you have to do in such a case is to register the mac addresses of the guests in the linux device driver
16:55:11 <scheuran> E.g. the openvswitch agent could do this
16:55:17 <scheuran> Any thoughts on this?
16:55:31 <scheuran> This registration can be done via user space (e.g. using bridge fdb add) command on the backing eth device
16:55:55 <scheuran> or directly in the linux net driver (which is not very openstack like I guess)
16:56:10 <rkukura> scheuran: Do you see this as more of a bug fix, or a BP to be proposed for Kilo?
16:56:43 <scheuran> I guess it's more a feature, so I guess a blueprint
16:56:56 <rkukura> scheuran: agreed
16:57:18 <banix> but perhaps a very small feature
16:57:20 <rkukura> How common are adapters that need this?
16:57:33 <shivharis> scheuran: usually promiscuous mode is not supported for security reasons?
16:58:19 <scheuran> shivharis: yes, it's sold as feature that the card does not have promisc mode
16:58:20 <banix> shivharis: i think so
16:58:35 <scheuran> it's more in the enterprise computing segment
16:58:53 <banix> shivharis: think enterprise :)
16:59:00 <shivharis> we are saying - allow mac spoofing now
16:59:02 <banix> scheuran: was thinking the same thing
16:59:16 <rkukura> OK, sounds like a good BP to propose
16:59:23 <rkukura> Anything else on this?
16:59:30 <rkukura> #topic Open Discussion
16:59:38 <shivharis> add a bp we should discuss
16:59:46 <rkukura> Or anything else?
16:59:50 <scheuran> rkukura: ok thanks. I'll go ahead and file a bp
17:00:03 <rkukura> scheuran: thanks
17:00:17 <rkukura> Seems we are done...
17:00:28 <rkukura> #endmeeting