15:00:41 <regXboi> #startmeeting neutron_northbound
15:00:41 <odl_meetbot> Meeting started Fri Aug 21 15:00:41 2015 UTC.  The chair is regXboi. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:00:41 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:41 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
15:00:48 <regXboi> #chair edwarnicke, flaviof_
15:00:48 <odl_meetbot> Current chairs: edwarnicke flaviof_ regXboi
15:00:53 <flaviof_> #info flaviof_
15:00:56 <regXboi> #topic agenda bash and roll call
15:01:09 <regXboi> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings#Agenda_for_Next.2C_Next_Meeting_.288.2F21.29 agenda in its usual place
15:01:18 <regXboi> #info regXboi
15:01:34 <edwarnicke> #info edwarnicke
15:01:43 <regXboi> we'll give a couple of minutes for folks to gather up before we plow in
15:01:51 <regXboi> but we have a lot to cover today
15:03:02 <regXboi> #topic action items from last meeting
15:03:10 <regXboi> #info regXboi, edwarnicke, flaviof to find a document contact vict.... volunteer
15:03:16 <regXboi> anybody have luck with this one :)
15:03:37 <flaviof_> heh flaviof_ had none
15:03:46 <regXboi> yeah, I wasn't expecting any
15:03:56 <regXboi> my name is there for now, we'll just leave it that way
15:04:07 <regXboi> #info edwarnicke to launch neutron-dev ML thread on observation #4 from Dec's talk
15:04:17 <regXboi> that one is done:
15:04:18 <regXboi> #link https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000289.html start of thread
15:04:21 <regXboi> thanks, edwarnicke
15:04:32 <edwarnicke> :)
15:04:34 <regXboi> #info  regXboi to update ML thread on rewrite with notes from this (8/14) meeting
15:04:39 <regXboi> that is also done...
15:04:56 <regXboi> #link https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000304.html update email
15:05:08 <regXboi> hey, look - the action item list is cleared!
15:05:12 <regXboi> #topic bugs
15:05:30 <regXboi> I wanted to take a moment and bring up a couple of old ones and see where we are with them
15:05:44 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=2088 bug 2088
15:05:56 <regXboi> Has *anybody* looked at this?
15:06:49 <flaviof_> adetalhouet: ^^ ?
15:07:01 <regXboi> edwarnicke, can I task you with contacting Rajesh and see if he is still working on this?
15:07:58 <regXboi> so, nobody here has looked, ed, hold off on the answer, because there might be more in the category :)
15:08:11 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=3304 bug 3304
15:08:27 <regXboi> isn't this now fixed?
15:08:51 <flaviof_> afaik, that is fixed.
15:08:57 <regXboi> ok, let's mark it as such
15:09:19 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=3423 bug 3423
15:09:36 <regXboi> now this one, I *know* is still open
15:10:09 <regXboi> and will be until we get the CHMs gone and the md-sal dummyproviders up and running
15:10:20 <regXboi> but that's on the list of things to do :)
15:10:33 <flaviof_> ack.
15:10:36 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=3824 bug 3824
15:10:58 <regXboi> I thought this one is also done?
15:11:08 <flaviof_> I'm pretty sure yamahata knocked this one out of the park
15:11:29 <regXboi> well... no
15:11:32 <regXboi> not 100%
15:11:33 <yamahata> No.
15:11:53 <regXboi> ok, this one is still open - but *should* be relatively easy to close
15:12:20 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=3902 bug 3902
15:12:21 <yamahata> I suppose it's not urgent. I'm chasing other bugs
15:12:41 <regXboi> yamahata: ack - I think I can bend an optic here next week
15:12:43 <flaviof_> yamahata: oops; my bad.
15:13:15 <regXboi> on 3902, I really don't care about this one right now - any takers?
15:13:25 <flaviof_> yamahata: you are right; bug 3824 is not urgent.
15:13:57 <regXboi> my feelings on 3902 are when we get to code cleanup, it becomes important, but I'm not there right now
15:14:06 <flaviof_> regXboi: +1
15:14:12 <regXboi> ok... last
15:14:15 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=3913 bug 3913
15:14:33 <regXboi> this one is a bit more serious
15:15:00 <regXboi> flaviof_: can you take a look and triage this next week?
15:15:26 <yamahata> I'm looking at this.
15:15:26 <flaviof_> regXboi: not sure. Isn't Ankur doing that?
15:15:38 <flaviof_> ok. thanks -- again -- yamahata !
15:15:45 <yamahata> Right now I'm covering it for Ankur.
15:15:51 <yamahata> He's busy with infra side.
15:15:53 <regXboi> yamahata: ack - any update?
15:16:07 <yamahata> Right now it's becoming better.
15:16:17 <yamahata> at least with my local repo.
15:16:34 <regXboi> ok, that's good news (I think)
15:16:35 <yamahata> But still there are test failures yet.
15:17:16 <regXboi> ok, not the best of news, but it hasn't fallen on the floor - that's a good thing
15:17:33 <regXboi> we'll add more next week - I want to start banging some of these out before the deluge hits
15:17:46 <regXboi> #topic open patches
15:17:54 <regXboi> #info we've got a bunch of open patches at https://git.opendaylight.org/gerrit/#/q/status:open+project:neutron - please review
15:18:24 <regXboi> I see a bunch of +2s all of a sudden, but please do the needful W+1 as well
15:19:27 <odp-gerritbot> A change was merged to neutron: BUG #4026 : Missing key is getUuid. Supplied key is RouterKey []  https://git.opendaylight.org/gerrit/24976
15:19:45 <regXboi> ok... next topic
15:19:55 <regXboi> #topic beryllium
15:20:06 <regXboi> #info M2 is 8/27 we need takers for the following items:
15:20:21 <regXboi> 1. finishing the release plan
15:20:32 <regXboi> 2. finishing the project test list
15:20:39 <regXboi> 3. requesting the system test waiver
15:21:00 <regXboi> 4. getting acknowledgement of projects we depend on
15:21:28 <regXboi> I'm assuming that we don't need extra configuration/resources from the CI infra and we can just reuse the existing JJB jobs we have
15:21:31 <regXboi> comments?
15:21:34 <regXboi> volunteers?
15:21:45 <regXboi> cricket serenade?
15:24:23 <regXboi> well - that's disappointing
15:26:11 <regXboi> but I'm not going to hold up the meeting for it
15:26:25 <regXboi> #topic open mike
15:26:33 <regXboi> or on demand agenda
15:26:38 <regXboi> anybody have topics?
15:26:44 <wojdec> aye :-)
15:26:48 <adetalhouet> flaviof_: regXboi sorry was on another meeting. For bug 2088, this one is fixed
15:27:16 <wojdec> @regXboi: the neutron ML2 driver discussion
15:27:20 <regXboi> adetalhouet: ack
15:27:26 <adetalhouet> flaviof_: regXboi while testing LBaaS I was unable to add 2 members with the same ID - and an exception was thrown
15:27:35 <regXboi> wojdec, you have the floor
15:27:58 <flaviof_> adetalhouet: ty
15:28:25 <wojdec> @all: I missed the past meetings - heard there were some questions. Got one by email + answered it… anything else?
15:28:44 <odp-gerritbot> A change was merged to neutron: Add IT cases for Security Groups  https://git.opendaylight.org/gerrit/25426
15:28:51 <odp-gerritbot> A change was merged to neutron: Add IT cases for Metering Labels  https://git.opendaylight.org/gerrit/25431
15:28:58 <odp-gerritbot> A change was merged to neutron: Add IT cases for Metering Rules  https://git.opendaylight.org/gerrit/25432
15:29:04 <odp-gerritbot> A change was merged to neutron: Add IT cases for Security Rules  https://git.opendaylight.org/gerrit/25430
15:29:20 <regXboi> wojdec: I think we need to pick up the discussion from that point
15:30:00 <regXboi> #link https://wiki.opendaylight.org/images/8/8d/Experiences_with_Neutron.pdf picking up on point 4 here
15:30:49 <regXboi> #link https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000295.html wojdec's reply
15:31:29 <regXboi> my reading of the second link is that while it makes sense for the mapping to be in ODL via a model and API, I'm *not* convinced it is in NN's scope
15:31:33 <wojdec> ok, so basically, the association between the neutron net and physical network is topological info, which IMO would/should be made available at ODL
15:32:05 <wojdec> currently it's in a very lousy place/a pita for customers/operators
15:32:27 <flaviof_> sounds like the crux of the matter is not that this would be great; but rather which project would host such a yang
15:33:22 <regXboi> flaviof_: I think so, yes
15:33:34 <wojdec> now, given that this info is only applicable when someone is doing work with Neutron N on ODL, it kind of points to this project as the default
15:33:38 <yamahata> It's generic neutron problem. Shouldn't it be addressed in neutorn first.
15:33:43 <yamahata> then map it to odl.
15:34:09 <edwarnicke> yamahata: I feel your sentiment there... but after lo these many years... I don't expect it to get addressed there
15:34:13 <wojdec> well, in odl this maps neatly into topology
15:34:26 <edwarnicke> wojdec: Say more
15:35:21 <regXboi> I think wojdec is correct - my reaction is that this feels like a natural extension of the current topology
15:35:27 <odp-gerritbot> A change was merged to neutron: Add IT cases for Floating IPs  https://git.opendaylight.org/gerrit/25334
15:35:28 <odp-gerritbot> A change was merged to neutron: Remove Floating IP ConcurrentHashMap  https://git.opendaylight.org/gerrit/25335
15:35:59 <odp-gerritbot> A change was merged to neutron: Add VPNaaS related test cases  https://git.opendaylight.org/gerrit/25494
15:36:27 <wojdec> i.e. ODL contains physical network topology (which can be aquired using various means), of devices X, Y, etc. We even have GUI rendering of this info. Now, for any given device, operator says "I want Interface X on device Y to be used for Neutron network Z"
15:37:14 <wojdec> it can be hopefully be readily seen that this info fits in nicely, also from a gui rendering perpsective, as topological info
15:37:32 <edwarnicke> wojdec: I am accostommed to thinking about interfaces associated to *ports* not networks...
15:37:36 <wojdec> i using the example of phys net, but it can apply/extend to logical nets too
15:38:06 <wojdec> edwarnicke: I'm using the (rather odd) neutron terminology
15:38:18 <wojdec> when i say network = provider network
15:38:20 <regXboi> edwarnicke: since neutron port W is scoped by neutron network Z, I think we can say X on Y used for W as an equivalency
15:38:50 <edwarnicke> wojdec: But correct me if I'm wrong, its really the mapping of physnet ports to actual physical ports you are interested in here
15:39:16 <wojdec> and Neutron Networks (eg some tenant net) maps to a provider net, which then needs to be mapped to an interface
15:39:48 <wojdec> afaik there isn't a thing called physnet port
15:40:01 <wojdec> but in essence it's about mapping physnets to ports
15:40:37 <edwarnicke> wojdec: Sure :)
15:40:50 <yamahata> wojdec: do you mean physical bridge mapping and its variants in neturon config?
15:41:01 <regXboi> I'm still seeing this as topology pulling in N data and using it as another topology view
15:41:01 <yamahata> Or is the scope wider?
15:41:18 <flaviof_> keep in mind that not all neutron ports translate into an termination point. an example of that is dvr's neutron port used as router interface, as well as neutron port for floating-ips.
15:41:24 <regXboi> (or whatever the right topology term is)
15:42:13 <wojdec> @yamahata: Current OVS agent plugin has this info as part of it's node specific config file, yes mapping of Neutron phys network to phys bridge + port
15:42:17 * flaviof_ sorry if I added more pepper to the alphabet soup
15:42:34 <regXboi> flaviof_: no worries, that was going to come up *eventually* (smile)
15:43:01 <regXboi> but I'm *still* seeing this as topology pulls in the N information and does the mapping
15:43:17 <regXboi> because that (as I understand it) is what topology does
15:43:41 <regXboi> (I am willing to have my understanding improved)
15:43:55 <wojdec> @regXboi: could you clarify what you mean by topology pulls in the N info?
15:44:15 <regXboi> where does topology get it's data set to work from?
15:44:28 <regXboi> increase the scope of that data set to include N port information
15:44:38 <regXboi> modulo flaviof_'s excellent point
15:45:16 <edwarnicke> regXboi: Please note... topology is just a model... someone needs to write code to populate this into it :)
15:45:29 <flaviof_> edwarnicke: +1 !
15:45:33 <wojdec> topology in this context = physical nodes + their interfaces. There are numerous ways to acquire this , simplest being that the user puts it in
15:45:51 <edwarnicke> wojdec: Tell us more about how you expect the user to put this in?
15:45:58 <regXboi> edwanicke: that's exactly my point - but the code *live* in the topology part of the world (i.e. controller)
15:46:03 <regXboi> er *lives*
15:46:17 <edwarnicke> regXboi: controller is on a diet and shedding stuff (and this is not in its scope anyway(
15:46:33 <regXboi> edwarnicke: then where does topology live these days?
15:46:49 <flaviof_> regXboi: that is not where all the code lives. ovsdb-southbound, for instance, populates a piece of that subtree as well.
15:47:03 <regXboi> flaviof_: that is (imho) a bad design
15:47:44 <flaviof_> regXboi: not that bad. the subtree I'm referrinf to is under 'ovsdb:1'
15:47:53 <regXboi> do we need to have a committer vote on whether this should be in our scope or not?
15:48:12 <wojdec> the means of ingesting topology isn't really the point here imo… As i wrote, in a simplest case, the user pushes in via Restconf {node: [ A. interfaces [ … ]]}
15:48:26 <edwarnicke> regXboi: That's my point... the *model* lives in yangtools... but the topology providers live in their various supporting projects
15:48:45 <regXboi> so... I can't say how much I think this is a really bad idea
15:48:49 <wojdec> that info goes in against the topo model/ is stored
15:48:55 <regXboi> I've said it gently
15:48:58 <wojdec> in MDSAL etc
15:49:02 <regXboi> and now I'm saying it less gently
15:49:02 <flaviof_> regXboi: lol
15:49:39 <wojdec> again: I'm not suggesting/scoping topology ingestion here
15:49:40 <edwarnicke> regXboi: Lets talk a bit about the underlying problem, and see if we can figure out a good solution
15:49:53 <edwarnicke> wojdec: Could you be clear about the *problem* and lets see if there are other ideas to solve it
15:50:14 <wojdec> I am scoping: Once the topo info is there, having an augmentation/extension to cover the mapping of Neutron Phys networks
15:50:16 <flaviof_> so you guys can think of an existing yang file that could be 'improved' by having a leaf called 'neutron port uuid' ?
15:50:48 <regXboi> folks, somebody needs to explain to me how this doesn't put us in the middle of the inventory business
15:51:31 <regXboi> because N ports can be created *long* before anything shows up in topology
15:52:09 <flaviof_> regXboi: +1 ... or 'never' (ergo my earlier point).
15:52:09 <wojdec> Problem: ODL gets via NN a neutron port add request. The port corresponds to neutron Network A. Neutron Network A has an external/phys network provider Z.
15:52:26 <wojdec> ODL has no info on how to setup bridging/whatever for Z
15:53:37 <regXboi> so, I don't understand why delayed binding doesn't work here
15:54:06 <edwarnicke> regXboi: I think the point is, somehow,you have to figure out the port for physnet
15:54:08 <wojdec> how does ODL get the info?
15:54:10 <edwarnicke> And right now
15:54:20 <edwarnicke> OS basically hides that info in local config files on the box
15:54:31 <edwarnicke> so we never get it
15:54:39 <regXboi> edwarnicke: my point is to go at the problem from the other side
15:54:43 <edwarnicke> So somewhere, somehow, somebody has to tell us that shit or we can't do anything reasonable
15:54:48 <flaviof_> regXboi: wojdec: so provider Z could be responsible for adding to topology/inventory the map for the neutron port?
15:54:48 <edwarnicke> regXboi: Say more
15:55:06 <regXboi> so... for instance ports, this is relatively easy
15:55:37 <regXboi> when the instance port comes up, it has enough information that you can find the neutron port that aligns with it and that gives you the network/subnet/etc. information
15:56:31 <regXboi> I *think* (but I don't know) that you can follow that chain to get information about routers, etc. and build out the pieces of the N configuration that are needed for that instance to work properly
15:56:40 <regXboi> and isn't that good enough?
15:57:03 <edwarnicke> regXboi: So... in my little experience poking around this problem, that's not actually the case... you *can't* figure out which port goes with the physnet from that data
15:57:14 <regXboi> uh
15:57:40 * regXboi finds that extremely interesting because we had internal code that *DID* just that
15:57:41 <edwarnicke> regXboi: I know for the ovs using providers, they literally are having a local script on the host read the data from the local config files and poke that data into ovsdb so they can find it there
15:58:20 <wojdec> regXboi: the network info you're reffering to above, would contain an provider-physical-network attribute
15:58:33 <regXboi> wojdec: if it were configured in, es
15:58:34 <regXboi> er yes
15:58:38 <wojdec> that needs to be then mapped to a physical interface
15:58:38 <flaviof_> edwarnicke: ack. so lets use ovsdb as provider Z to make this example more concrete
15:59:17 <flaviof_> can't we use yang wojdec to be the 'common' place (https://git.opendaylight.org/gerrit/#/c/23594/)
16:00:00 <flaviof_> and have all providers -- starting with ovsdb southbound -- populate the operational tree with the ovs interface ?
16:00:40 <regXboi> flaviof_: if all providers populate it, then I argue that it doesn't belong in NN - it belongs with the other topo models
16:01:20 <flaviof_> regXboi: ack... controller is better, you say.
16:01:27 <regXboi> folks - we are at the top of the hour
16:01:36 <regXboi> #info lots of discussion on this point (again) - see log
16:01:37 <wojdec> @flaviof: that could indeed be an option. The overall point here is of course that this info isn't tied to a switch type or implementation, and should be open
16:01:45 <edwarnicke> regXboi: I think flaviof_ and wojdec are suggesting that a common model in a common place is prefereable
16:02:04 <regXboi> edwarnicke: I'm perfectly ok with a common model in a common place
16:02:08 <edwarnicke> regXboi: Example: right now both GBP and ovsdb-netvirt are both tracking the *same* kind of mapping
16:02:18 <regXboi> but I argue *this* isn't the right common place
16:02:24 <edwarnicke> regXboi: What is?
16:02:27 <regXboi> controller
16:02:35 <viveknarasimhan> wojdec:  There was a feature we attempted in Openstack - dynamic physnet REST API
16:02:46 <regXboi> this is yet another topo model
16:02:49 <viveknarasimhan> but we weren't able to contribute to openstack
16:02:58 <regXboi> why should it live in a different location than the other topo models
16:03:00 <wojdec> @regexboi: This info is only useful if one uses Neutron
16:03:13 <regXboi> that's *not* a reason to split it
16:03:18 <viveknarasimhan> The REST API allows dynamic configuration of physnet-> bridge mappings for Openstack Neutron, instead of relying on static local config used today
16:03:18 <regXboi> I'm sorry
16:03:24 <yamahata> viveknarasimhan: link please. should we revive it and try it again?
16:03:39 <viveknarasimhan> i will provide the link , will have to search now
16:04:41 <edwarnicke> regXboi: First, this is completely out of scope for controller
16:04:42 <flaviof_> edwarnicke: I agree; it should not be in ovsdb-netvirt, nor in gbp. if we only had a net-virt project in ODL... :)
16:04:52 <edwarnicke> regXboi: Second, there is nothing in controller that does anything *vaguely* like this
16:04:54 <viveknarasimhan> The API also enables HA Cluster for Openstack Neutron see same information without manual intervention
16:04:56 <viveknarasimhan> via config files
16:04:59 <edwarnicke> regXboi: Third, controller is in the process of evaporating away
16:05:01 <regXboi> edwarnicke: and I'm not convinced it is in scope here
16:05:10 <regXboi> and I'm willing to put it to a vote
16:05:18 <regXboi> because I think that's what is going to take
16:05:29 <edwarnicke> viveknarasimhan: You come bearing potentially fantastic info :)
16:05:41 <edwarnicke> regXboi: I'd rather discuss a bit mroe
16:05:42 <viveknarasimhan> its call network-segment api
16:05:50 <edwarnicke> regXboi: Because I can't for the life of me think of another place to put it
16:05:52 <viveknarasimhan> allows to configure physnet:vlan-range and
16:05:56 <viveknarasimhan> vxlan-range information
16:06:00 <edwarnicke> viveknarasimhan: Do you have a link to its documentation?
16:06:06 <viveknarasimhan> the api can be extended for bridge mappings too
16:06:25 <flaviof_> regXboi: it is not that nn is the best place; it is just that it is the least bad place.
16:06:30 <viveknarasimhan> i couldn't find link now
16:06:32 <regXboi> if you really want that - you probably are going to have to do it in networking-odl
16:06:38 <viveknarasimhan> i will share it on ODL ML later
16:07:28 <regXboi> and if you do it in networking-ODL, then my arguements evaporate
16:08:13 <regXboi> anyway... folks -  I need to run off to another meeting...
16:08:30 <regXboi> edwarnicke, flaviof_: can one of you shut down the meeting when things are done?
16:08:46 <edwarnicke> regXboi: Sure
16:08:56 <regXboi> bye folks - talk to everybody next week
16:08:58 <edwarnicke> Guys, do we have anything else here... we are currently 8 minutes over
16:09:04 <flaviof_> regXboi: np. have a good one
16:10:46 <edwarnicke> #endmeeting