| *** enikher has joined #openstack-net-bgpvpn | 03:37 | |
| *** enikher has quit IRC | 03:49 | |
| *** enikher has joined #openstack-net-bgpvpn | 03:49 | |
| *** tmorin has joined #openstack-net-bgpvpn | 08:04 | |
| *** matrohon has joined #openstack-net-bgpvpn | 08:24 | |
| *** vthapar has joined #openstack-net-bgpvpn | 09:41 | |
| matrohon | vtahpar hi | 09:47 |
|---|---|---|
| matrohon | vthapar hi | 09:47 |
| vthapar | matrohon: hi | 09:48 |
| matrohon | vthapar : tmorin had some concerns with https://review.openstack.org/#/c/254244/ | 09:48 |
| matrohon | we specified some associations constraints in the spec : | 09:50 |
| vthapar | matrohon, sure tell me. | 09:50 |
| matrohon | vthapar : http://docs.openstack.org/developer/networking-bgpvpn/api.html#association-constraints | 09:50 |
| matrohon | vthapar : we were wondering if some constraints were enforce by ODL | 09:52 |
| vthapar | matrohon, currently there are no means of communication from ODL back to driver/openstack. so constraints might be there but no way for driver to know. | 09:52 |
| matrohon | vthapar, at leatest, check that the if router and net are associated to a bgpvpn, the net cannot be attached to the router | 09:53 |
| vthapar | matohon: my impression was plugin was doing that check already. isn't post_commit bit too late to have that check in driver? | 09:53 |
| matrohon | vthapar, some tests are done at the plugin level : https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/plugin.py#L98 | 09:54 |
| matrohon | but currently we don't prevent a user to attach a net a router that both have been associated to a bgpvpn | 09:55 |
| matrohon | vthapar, ^ | 09:55 |
| vthapar | matrohon, won't that require check in router or net API? not familiar enough with openstack code so sorry if question sounds too silly. | 09:57 |
| tmorin | hi guys | 09:57 |
| matrohon | we have to think about it but the straightforward way to implement such a check is to listen to "router_interface_add" API call | 09:58 |
| tmorin | its not really like I have /concerns/ | 09:58 |
| matrohon | tmorin, hi | 09:58 |
| tmorin | it is more questions of how consistency is ensured | 09:58 |
| matrohon | tmorin : on the ODL side? | 10:00 |
| vthapar | hmm... ODL Driver or L3 plugin sits in n-odl code, so such a check could be added there. maybe take it up when we move the driver back to n-odl? | 10:00 |
| matrohon | vthapar, makes sense | 10:01 |
| matrohon | tmorin, I don't think a related bug already exist | 10:02 |
| matrohon | ? | 10:02 |
| vthapar | matrohon: for now we can document this and create a bug for it. | 10:02 |
| matrohon | tmorin : I would go for +a vthapar patche, cretaing a bug report et affecting n-odl for this bug | 10:03 |
| matrohon | vthapar, +1 | 10:03 |
| matrohon | s/et/and | 10:03 |
| vthapar | cool, I'll also take it up with n-odl folks though might not be able to do much till we bring this driver into n-odl. | 10:04 |
| tmorin | sorry, visitors in my office :) | 10:04 |
| tmorin | yes, I was wondering how "checking on router interface plug, that router/network associations constrains are respected" would be done | 10:05 |
| tmorin | I was wondering if part of that shouldn't involve the driver | 10:05 |
| tmorin | possibly,everything would be done in ODL and the driver (+ the checks already done in the service plugin today) is fine as it is | 10:05 |
| tmorin | I just wanted to know if this was covered somewhere | 10:06 |
| vthapar | am not sure how plugin/diver boundaries are deined, but I'd think that any check that every driver needs to do and is not dependent on information specific to driver backend could/should be taken care of by plugin. | 10:06 |
| vthapar | s/deined/defined | 10:06 |
| tmorin | vthapar: yes, all the router/network assoc checks that can be implemented in a common way are done in the plugin code | 10:07 |
| tmorin | eg.: https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/plugin.py#L98 | 10:07 |
| tmorin | and https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/plugin.py#L68 | 10:07 |
| tmorin | this checks in the plugin call the core_plugin and are driver-independent | 10:08 |
| vthapar | tmorin: got it. | 10:09 |
| tmorin | but there is one check that today can't be done this way: checking consistency when a net interface is plugged on a router | 10:09 |
| * vthapar should probably go through plugin code sometime soon. | 10:09 | |
| tmorin | it is not possible to do this in the plugin because there is no backend-independent way of knowing about such events | 10:09 |
| tmorin | that would be doable for all ML2-based backends, assuming we make sure that the proper events are fired, but that would not cover non-ML2 backends anyways | 10:10 |
| tmorin | so this check today has to be done by the backend I think | 10:10 |
| tmorin | ODL in your case | 10:10 |
| vthapar | tmorin: sorry, had visitors. | 10:18 |
| tmorin | vthapar: :) np, this kind of things happen -- people can't distinguish when you code/email or when you chat :) | 10:19 |
| vthapar | tmorin: that is one issue today with ODL Driver, it is one way communication where it only pushes changes to ODL. as of today no concrete means to query backend. | 10:19 |
| tmorin | this is also an issue for bagpipe driver | 10:20 |
| vthapar | tomrin: I am not sure if there are any plans to change that, will have to talk to Isaku or someone at the upcoming ODL dev forum. | 10:20 |
| matrohon | tmorin : I'm not even sure that relying on ML2 is enough since the router-interface-add API call is processed by the l3 plugin | 10:20 |
| tmorin | in the case of ODL, if ODL had the possibility of checking BGPVPN assoc consistency on an attachement of a interface to a router, it could refuse to attach the interface to the router and feedback this error to the ODL L3plugin | 10:21 |
| tmorin | anyway, the point was more to check that you had this kind of concern in mind | 10:21 |
| tmorin | I don't think the issue can be solved in the driver alone | 10:22 |
| tmorin | when can +a the change | 10:22 |
| vthapar | tmorin: agree, driver alone can't manage and currently feedback of error to ODL L3 not possible. will take it up during our next ODL VPNservice meeting. | 10:22 |
| vthapar | I guess best we can do is log error and require user intervention for now and capture it explicitly and clearly in documentation. | 10:23 |
| tmorin | yes | 10:23 |
| openstackgerrit | Merged openstack/networking-bgpvpn: Add support for router association in ODL driver https://review.openstack.org/254244 | 10:28 |
| *** enikher has quit IRC | 10:46 | |
| *** openstackgerrit has quit IRC | 11:47 | |
| *** openstackgerrit has joined #openstack-net-bgpvpn | 11:47 | |
| *** openstackgerrit has quit IRC | 12:33 | |
| *** openstackgerrit has joined #openstack-net-bgpvpn | 12:33 | |
| *** matrohon has quit IRC | 12:45 | |
| *** matrohon has joined #openstack-net-bgpvpn | 13:10 | |
| matrohon | vthapar, do you want to backport your patch to liberty? | 13:26 |
| vthapar | matrohon, I think so. I've sent out a mail internally and awaiting confirmation. | 13:27 |
| matrohon | vthapar, ok nice | 13:27 |
| vthapar | would it be a matter of simple cherrypick? | 13:28 |
| matrohon | vthapar, be aware that we are not able to merge patches in the stable/liberty branch | 13:28 |
| matrohon | vthapar, a simple cherry pick should work yes | 13:28 |
| vthapar | aha. so what would process for this be? | 13:29 |
| vthapar | do have have some backport/liberty? | 13:29 |
| matrohon | you can submit the patch on the stable/liberty branch, we will +1, be only neutron maintainers team is able to merge it | 13:30 |
| matrohon | vthapar, this is the process of the neutron stadium | 13:31 |
| vthapar | aha, got it :) | 13:32 |
| vthapar | router association on plugin side is already part of liberty, right? | 13:32 |
| matrohon | vthapar, yep | 13:34 |
| vthapar | matrohon: quick question, how do I specify multiple route_targets when creating bgpvpn? | 15:01 |
| matrohon | vthapar, good question | 15:17 |
| matrohon | vthapar, I've never played with multiple RTs, maybe tmorin did? | 15:17 |
| vthapar | tmorin: ^^^^ | 15:17 |
| tmorin | let me find that | 15:18 |
| tmorin | it's just like for any field value in all openstack apis | 15:18 |
| tmorin | neutron bgpvpn-create --help | 15:23 |
| tmorin | gives the answer in fact: | 15:23 |
| tmorin | -- --route-targets list=true <asn1>:<nn1> <asn2>:<nn2> ... | 15:23 |
| matrohon | tmorin, thanks | 15:23 |
| tmorin | you can I think also do --route-target ASN1:nn1 --route-target ASN2:nn2 | 15:23 |
| vthapar | tmorin, thanks. I was trying a comma separated list. | 15:25 |
| tmorin | ok | 15:26 |
| *** matrohon has quit IRC | 16:53 | |
| *** tmorin has quit IRC | 17:11 | |
| *** vthapar has quit IRC | 18:12 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!