15:01:42 <tmorin> #startmeeting bgpvpn
15:01:43 <openstack> Meeting started Tue Dec  8 15:01:42 2015 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:44 <tmorin> hi everyone
15:01:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:46 <openstack> The meeting name has been set to 'bgpvpn'
15:02:01 <matrohon> hi
15:02:02 <tmorin> hi doude, pcarver, timirnich
15:02:07 <tmorin> hi matrohon
15:02:13 <doude> hi
15:02:21 <matrohon> let's wait a few minutes to have a more crowded room
15:06:34 <matrohon> may be a day off in germany :)
15:10:12 <matrohon> tmorin, doude let's move on?
15:10:27 <tmorin> ok !
15:10:39 <doude> ok
15:10:40 <matrohon> I did an agenda
15:10:53 <tmorin> link ?
15:11:08 <matrohon> #link : https://wiki.openstack.org/wiki/Meetings/BGPVPN#Agenda
15:11:42 <matrohon> #topic reaminig bugs
15:12:08 <tmorin> we need to decide on auto-aggregate
15:12:22 <matrohon> so you are very close to our first release
15:12:29 <matrohon> few bugs remains
15:12:49 <matrohon> let's start by auto aggregates bug
15:12:56 <tmorin> the proposition in https://review.openstack.org/#/c/252519/ consist in removing all code related to auto-aggregate
15:13:07 <tmorin> because no driver is supporting the feature today
15:13:15 <matrohon> #link : https://bugs.launchpad.net/bgpvpn/+bug/1522325
15:13:15 <openstack> Launchpad bug 1522325 in bgpvpn liberty "auto-aggregate flag not implemented" [Medium,In progress] - Assigned to Thomas Morin (tmmorin-orange)
15:13:24 <tmorin> the idea is to be ready to revert the removal once drivers start supporting it
15:13:32 <tmorin> #link  https://review.openstack.org/#/c/252519/
15:13:56 <tmorin> let suggest the people who will read the IRC meeting log to vote/comment on this change
15:14:06 <tmorin> if everybody is ok will proceed
15:14:14 <matrohon> hope they will read it :)
15:14:39 <tmorin> yes :)
15:15:01 <tmorin> if not, I guess we will proceed by default and release without any auto-aggregate code
15:15:07 <tmorin> next bug ?
15:15:14 <matrohon> #link : https://bugs.launchpad.net/networking-bagpipe/+bug/1522797
15:15:14 <openstack> Launchpad bug 1522797 in BaGPipe "bagpipe: update bgpvpn attachement of an existing port does not work" [Critical,Confirmed]
15:15:28 <matrohon> I wonder if it's still a bgpvpn issue?
15:15:43 <tmorin> no it is not, the fix will land soon in networking-bagpipe
15:15:53 <doude> +1 to remove auto-aggregate
15:16:21 <matrohon> great!
15:16:23 <tmorin> doude: can you +1 in the gerrit change as well ?
15:16:42 <doude> tmorin: sure
15:16:48 <tmorin> next bug ?
15:16:56 <matrohon> #link : https://bugs.launchpad.net/bgpvpn/+bug/1478998
15:16:56 <openstack> Launchpad bug 1478998 in bgpvpn liberty "de-duplicate route_targets and {import,export}_rts" [Medium,Confirmed] - Assigned to Mathieu Rohon (mathieu-rohon)
15:17:15 <tmorin> this one may need a bit of discussion
15:17:23 <tmorin> it is a pretty minor thing
15:17:34 <tmorin> but the question is about reverting a choice made earlier
15:18:07 <tmorin> specifically what is documented here: #link http://docs.openstack.org/developer/networking-bgpvpn/specs.html#database-design
15:18:33 <tmorin> the proposal is to *not* do what is described at the link above, and keep the DB as-is
15:18:38 <tmorin> motivations are documented in the bug
15:18:46 <matrohon> to sum up : we're moving the pain of consolidating route-targets submitted by cloud admin to the drivers
15:19:13 <tmorin> "pain" being a big word for a trivial operation :)
15:19:14 <matrohon> doude : is there any validation of RT in the contrail driver
15:19:22 <tmorin> union of sets
15:20:12 <tmorin> RTs to be used for exports = union ( export_rts, route_targets )
15:20:17 <doude> matrohon: you mean the formated string representation of a RT ?
15:20:44 <matrohon> doude, yep
15:20:52 <tmorin> I think matrohon means avoiding having an RT both in export RTs in Route Targets
15:20:58 <tmorin> ah, sorry
15:21:10 <doude> matrohon: yes, there is
15:21:19 <matrohon> doude, great!
15:21:25 <tmorin> matrohon: the API already does a validation, doesn't it ?
15:21:49 <matrohon> tmorin, I don't think it validate overlaps
15:21:52 <doude> that seems logic to let the driver validate it
15:22:17 <doude> not realy the driver but the SDN controller used by the driver
15:22:32 * tmorin looking at the code
15:22:48 <matrohon> doude : +1
15:22:53 <doude> networking-bgpvpn cannot validate the overlap
15:23:34 <doude> some RT can be added/deleted on the SDN controller in other way that networking-bgpvpn
15:24:24 <matrohon> tmorin, it validates that one list has no overlap, but doesn't validate that there is no overlap between RT and import RT for instance
15:24:28 <tmorin> maybe there is something to check here in the contrail driver
15:25:04 <doude> tmorin: to validate the overlap into the requested list?
15:25:08 <tmorin> reading the opencontrail driver code I think there might possibly be an issue if an RT is both in route_targets and import_rts
15:25:17 <matrohon> doude : yep
15:25:23 <tmorin> see https://github.com/openstack/networking-bgpvpn/blob/7f141ecfa2673dcd3da06f3de712e051541b24db/networking_bgpvpn/neutron/services/service_drivers/opencontrail/opencontrail.py#L128
15:26:40 <doude> tmorin: no beacause if the RT already exists it re-uses it https://github.com/openstack/networking-bgpvpn/blob/7f141ecfa2673dcd3da06f3de712e051541b24db/networking_bgpvpn/neutron/services/service_drivers/opencontrail/opencontrail.py#L51
15:26:48 <tmorin> doesn't this line make an RT import only, event if it was given as an import/export RT 5 lines above ?
15:27:03 <tmorin> you know better
15:27:14 <tmorin> doesn't the new link overwrite the previous one ?
15:27:34 <tmorin> line 123 the RI is linked to the RT as an import/export RT
15:28:14 <tmorin> I wonder if at  line 128 the RI is linked with the RT as an import-only RT, thus possibly overwriting the previous link ?
15:28:35 <doude> tmorin: yes true
15:29:29 <doude> perhaps bgpvpn plugin can make clean of overlap before sending RT lists to the driver?
15:29:56 <tmorin> a nice way to fix this would be to have helpers function usable by all drivers to retrieve import_export_rts, import_only_rts, export_only_rts, all_export_rts, all_import_rts
15:30:10 <tmorin> doude: that would be another possibility
15:30:33 * tmorin thinking again
15:30:39 <tmorin> well no
15:31:00 <tmorin> that would have the same drawback as the drawback discussed in https://bugs.launchpad.net/bgpvpn/+bug/1478998
15:31:00 <openstack> Launchpad bug 1478998 in bgpvpn liberty "de-duplicate route_targets and {import,export}_rts" [Medium,Confirmed] - Assigned to Mathieu Rohon (mathieu-rohon)
15:31:12 <tmorin> because the modified sets would be stored in the DB
15:31:43 <tmorin> I like better the idea of helper functions
15:31:59 <matrohon> we could have a comon method to generate a consolidated list based on the 3 list
15:32:02 <tmorin> also, different drivers may have different needs
15:32:16 <tmorin> some drivers will want all imports RTs unioned
15:32:30 <tmorin> some drivers will want the common import/export RTs and separately the import-only RTs
15:32:52 <tmorin> matrohon: see my suggestion above (helpers function for import_export_rts, import_only_rts, export_only_rts, all_export_rts, all_import_rts)
15:33:11 <doude> tmorin: yes
15:33:12 <tmorin> matrohon: but it's better to make it more than one function
15:33:58 <matrohon> tmorin : makes sense, let's start with what is needed but the current drivers first
15:35:12 <tmorin> bagpipe code will benefit from that as well (https://github.com/openstack/networking-bgpvpn/blob/7f141ecfa2673dcd3da06f3de712e051541b24db/networking_bgpvpn/neutron/services/service_drivers/bagpipe/bagpipe.py#L197)
15:35:51 <tmorin> how do we prioritize that vs the release ?
15:36:06 <matrohon> doude, however if you conssolidate before sending to contrail, you will fall in the bug, since RT lists submitted by the client won't be stored anywhere, am I wrong?
15:36:10 <tmorin> the bug in contrail would be worth fixing, but can possibly wait for later ?
15:37:09 <matrohon> doude can you fix the contrail driver first, quickly, and then we consolidate with a common method?
15:37:47 <doude> matrohon: the bug is not very important imo
15:38:26 <tmorin> ok, so let's track the contrail issue in a bug for next release, and the helper improvement in an rfe bug for next release ?
15:38:37 <matrohon> tmorin, +1
15:38:39 <doude> it appears only if the admin does not prvide correctly the RT lists
15:38:48 <doude> yes
15:39:24 <tmorin> doude: +1
15:39:40 <matrohon> #topic release
15:39:59 <matrohon> I discussed earlier with ttx
15:40:37 <matrohon> the situation is confusing currently, and it's going to be discussed in today's infra meeting
15:41:29 <matrohon> do we want to stay in neutron or be a standalone project? that's one of the main question
15:42:40 <tmorin> the questions relates to the branch that may result from the first release
15:43:05 <tmorin> the initial assumption was that a release from our master would create a stable/liberty branch
15:44:13 <tmorin> my understanding is that unless a decision is made to advertise the stability of a branch via a tag (rather than the branch name), we will have to use a branch named backport/liberty or something like that
15:44:45 <tmorin> I'm guessing we need to have a decision on this branch before the release button can be pushed
15:44:56 <tmorin> armax, dougwig : ^^
15:45:06 <tmorin> mestery: ^^
15:45:16 <tmorin> russellb: ^^
15:50:51 <tmorin> western america is likely to be asleep at this time
15:51:33 <tmorin> the best conclusion we have is that we need to get in touch with neutron PTL and core developers to see what needs to be decided before the release button can be pushed
15:52:20 <matrohon> +1
15:52:51 <matrohon> #topic : open discussion
15:53:03 <matrohon> we could have the first meeting in french language in the history of openstack :)
15:53:17 <matrohon> enikher, hi
15:53:19 <doude> :)
15:53:31 <enikher> hello
15:54:04 <matrohon> enikher, you're late by one hour :)
15:54:20 <enikher> yes sorry, had a conflicting meeting
15:54:36 <tmorin> hi enikher
15:54:39 <enikher> I just wanted to see the results of todays discussion
15:54:42 <tmorin> anything to add ?
15:54:52 <tmorin> I fear you'll have to read the logs :-(
15:55:00 <enikher> AP for me?
15:55:14 <enikher> sure I will do
15:55:16 <enikher> :-)
15:55:18 <tmorin> not really, we wouldn't dare in your absence :)
15:55:37 <tmorin> if you want to give a status on kilo backport, or on heat, or anything else, go ahead
15:55:57 <tmorin> apart from that, there are two bugs on which feedback is expected before we proceed
15:56:02 <enikher> I am spending more time on the fuel plugin at the moment
15:56:24 <enikher> we have an internal review process for HEAT plugin at the moment
15:56:29 <enikher> that will need more time
15:57:05 <enikher> the backport kilo branch looks stable beside the fact the neutron client still has to be patched
15:57:09 <enikher> thats all
15:57:32 <tmorin> ok, thanks for the status
15:58:35 <tmorin> anything else before we wrap up ?
15:59:39 <enikher> could it be a good idea to add audio to this meeting?
15:59:51 <enikher> just as we doing for opnfv?
16:01:07 <tmorin> enikher: this is not the usual Openstack "way of life"
16:01:14 <enikher> ok
16:01:51 <tmorin> since the audio isn't archived we'd lose a lot of the benefits
16:02:04 <tmorin> we have to free the floor
16:02:07 <enikher> ah ok understood
16:02:19 <tmorin> thanks everyone!
16:02:23 <tmorin> bye !
16:02:26 <tmorin> #endmeeting