15:02:09 <tmorin> #startmeeting bgpvpn
15:02:10 <openstack> Meeting started Tue Dec  1 15:02:09 2015 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:13 <openstack> The meeting name has been set to 'bgpvpn'
15:02:14 <tmorin> hi everyone
15:02:22 <enikher> hey
15:02:28 <tmorin> hi enikher
15:02:46 <tmorin> hi pcarver timirnich_ wdeclercq
15:03:05 <tmorin> matrohon won't be here today
15:03:21 <wdeclercq> hey
15:03:52 <timirnich_> hi all
15:03:59 <tmorin> #topic announcements, last week recap
15:04:24 <tmorin> lot's of things were merged during  the last week
15:04:40 <tmorin> the ODL driver was merged
15:04:52 <timirnich_> *champagne*
15:04:58 <tmorin> yes :)
15:05:06 <tmorin> the tempest initial framework as well (thanks enikher!)
15:05:29 <tmorin> and the kilo backport work as well (thanks enikher again!)
15:05:44 <timirnich_> employee of the month
15:05:59 <tmorin> there was also bugfix done on the bagpipe driver, triggered by a bug found by wdeclercq (thanks!)
15:06:34 <tmorin> beyond the stuff we merged there is also more in progress
15:06:48 <tmorin> in particular the router-association work by wdeclercq
15:06:55 <tmorin> which is mostly ready I think
15:07:21 <tmorin> pending one fix in the bagpipe driver that depends on a fix in the driver
15:07:47 <tmorin> so, that was a very active week :)
15:08:13 <tmorin> the plan is to finish all this and we should be ready to release
15:09:34 <tmorin> any comment ? next topic ?
15:10:18 <enikher> I am trying a merge between kilo and master at them moment
15:10:23 <werunthenight> #wordpress-sfd
15:10:56 <timirnich_> I could maybe mention that we are in the process of clarifying the installation procedures for OPNFV
15:11:07 <tmorin> enikher: yes +1
15:11:09 <werunthenight> Yeah
15:11:12 <timirnich_> tmorin and I just had a discussion with the Fuel guys
15:11:19 <werunthenight> How did it go?
15:11:36 <timirnich_> making progress but still some way to go I'd say
15:12:08 <werunthenight> ok
15:12:12 <timirnich_> but it's more a getting all onto same page problem
15:12:27 <werunthenight> Yeah
15:13:02 <tmorin> werunthenight: are you a bot ?
15:13:06 <werunthenight> No
15:13:08 <werunthenight> Why?
15:13:36 <tmorin> I was just wondering, we weren't introduced yet :)
15:14:26 <tmorin> ok tim, let's go ahead
15:14:28 <tmorin> :)
15:14:32 <timirnich_> ok
15:14:46 <timirnich_> that is all from my side
15:15:04 <tmorin> we need to clean up the dependencies in requirements as a prerequisite for proper installer support
15:15:30 <tmorin> I plan to work with radez to help on rpm packaging of the networking_bgpvpn module
15:15:45 <tmorin> #topic auto_aggregate flag
15:16:11 <tmorin> me and matrohon were thinking about the auto_aggregate flag
15:16:46 <tmorin> unless some driver support it, we'd prefer documenting it, but as "not supporte yet"
15:17:28 <janscheurich> The ODL backend does not support it
15:19:40 <tmorin> ok, so unless anyone disagress will document it as "not implemented yet"
15:20:02 <werunthenight> lets do that
15:20:13 <tmorin> #agreed document auto_aggregate as a future attribute
15:21:07 <tmorin> #topic release
15:21:24 <tmorin> we have a few things to define before we can do a release
15:22:12 <tmorin> one thing that was clarified a little bit last week, is that we can now work in our backport/x and master branch without being blocked by the check-requirements job
15:22:33 <tmorin> but we still haven't clear guidelines on which branch to create for releases
15:22:57 <enikher> shouldn't it be stable/liberty?
15:23:00 <tmorin> lots of discussion have happened on openstack-dev on how big tent and neutron stadium project can behave
15:23:32 <tmorin> enikher: this is one option, but if we're going to release more than one liberty-targetted release, that will not work
15:23:46 <enikher> ah ok
15:23:54 <tmorin> another option is stable/[release-number]
15:24:33 <janscheurich> But how do we indicate the target OS release in such bgpvpn releases?
15:24:34 <tmorin> but it is still unclear how that branch naming can be supported by the infra tools
15:25:02 <enikher> the it will not be tested against liberty or?
15:25:03 <tmorin> janscheurich: in documentation, and in requirements.txt
15:25:39 <janscheurich> But lets assume we have release X both for Liberty and backported to Kilo?
15:25:42 <tmorin> enikher: yes, the issue is how to get the infra tools to test our branch X against the right stable/y of openstack (devstack in particular)
15:26:27 <tmorin> janscheurich: we are not in this case now, but this is not easily supported by the tools
15:26:47 <tmorin> janscheurich: if you've read the thread on openstack-dev that was mentioned also as an issue
15:27:35 <enikher> should we go now for stable/liberty and then later try to get stable/liberyV2 or something?
15:27:42 <werunthenight> sure
15:27:45 <janscheurich> What about stable/liberty_<Num>
15:28:02 <janscheurich> and stable/kilo_<Num>
15:28:33 <tmorin> janscheurich: the infra tools behavior is based on using the same branch names, using the branch as a prefix would not help in this area
15:28:58 <janscheurich> Where <NUM> stands for a given functional scope that is the same for both target releases.
15:29:06 <tmorin> we are suffering from being among the few big tent projects, while process and tooling is not fully ready
15:29:22 <janscheurich> tmorin: That problem anyhow needs to be solved
15:29:52 <janscheurich> so we should not let us constrain too much by the tooling limitations, or?
15:29:57 <tmorin> janscheurich: yes, but we won't solve it in our own corner for our own project, we need to participate in community discussion to evolve process and tooling
15:30:56 <janscheurich> tmorin: of course. but we need to define some names now and can possibly adapt them at a later stage?
15:31:13 <enikher> We should go for stable/liberty now and then push the community to be able to handel stable/liberty_<num>
15:31:16 <tmorin> janscheurich: we need to adapt to what infra tools can do; while we can tweak some ci jobs, this has a limit: the limit is reached when infra tools find we are doing weird stuff that should have a better/clean  more general answer for all big tent projects
15:31:55 <tmorin> enikher: we can start with stable/liberty
15:32:21 <tmorin> enikher: I'm not sure about stable/liberty_<num>
15:33:02 <enikher> tmorin: Can you point us to the disscuion with infra team?
15:34:07 <tmorin> discussion with the infra team was both in gerrit and on IRC
15:34:20 <tmorin> plus the discussions on openstack-dev
15:34:46 <enikher> mhh ok that is hard to folow for us
15:35:31 <tmorin> https://review.openstack.org/#/c/249322/
15:35:40 <tmorin> https://review.openstack.org/#/c/249322/
15:36:41 <tmorin> http://lists.openstack.org/pipermail/openstack-dev/2015-November/079773.html
15:37:05 <enikher> ok thanks
15:37:29 <tmorin> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080233.html
15:38:26 <tmorin> http://lists.openstack.org/pipermail/openstack-dev/2015-December/080865.html
15:38:31 <enikher> tmorin: I think from your side there is no real requirement on the branching, as long infra is ok with it
15:39:38 <tmorin> true
15:39:46 <enikher> tmorin: as said I think we should just go for stable/liberty for now and discuss the problem again when we want to release again on liberty
15:40:19 <enikher> shure we can fight for it in the meanwhile :-)
15:40:38 <tmorin> the two things important for us, if i summarize: being able to work in branch releases without requiring reviews from Neutron cores, and  having infra tools that support our branch names and are able to test against the right devstack&neutron
15:41:44 <tmorin> enikher: that's what we are most likely to do, unless people TC&infra work out proper guidelines for the case which we are in
15:41:55 <tmorin> anything else to discuss ?
15:42:36 <enikher> It would be very good if from now on every commit which is done would be cherry-picked to kilo
15:43:29 <tmorin> enikher: you've done a good job of doing so, that would be fine with us if you keep tracking them and working on making them mergeable,
15:43:37 <tmorin> we will review and merge
15:43:44 <enikher> mhhh
15:44:00 <enikher> I though about that the original commiter will do so
15:44:18 <enikher> it is quite hard for me to understand and merge every commit
15:45:06 <wdeclercq> Only send cherry-picks AFTER it has already been merged to master?
15:45:15 <enikher> yes
15:45:16 <tmorin> wdeclercq: yes
15:45:24 <wdeclercq> okay
15:45:53 <tmorin> gerrit's "cherry-pick" button does not seem to work, though, the cherry-picking has to be manual
15:46:38 <tmorin> gerrit web UI cherry-pick is possibly be doing additional checks, and only supports cherry-picks without any conflict
15:47:36 <enikher> yes it is a problem
15:47:45 <enikher> but git review is doing well for this
15:48:00 <wdeclercq> Well it kind of makes sence that gerrit can't do anything if there are merge conflicts :)
15:48:17 <tmorin> wdeclercq: yes :)
15:48:56 <tmorin> wdeclercq: but in cases that seemed trivial to me, it wouldn't work either (e.g. https://review.openstack.org/#/c/251415 )
15:50:16 <enikher> mhh not sure way it is not working. Is there a team to ask that?
15:50:18 <tmorin> enikher: on who to work on backporting changes: sometimes people doing commits will find the time to backport, sometimes the people most interested in the backport will have to ... we can't do much better than that
15:50:39 <enikher> ok
15:51:02 <tmorin> enikher: #openstack-infra folks know the intricacies of gerrit, they may know
15:51:14 <enikher> but then we will only backport needed commits and not merge the whole branch
15:51:28 <enikher> the backport branch will then die after a while.
15:53:00 <enikher> ok, at least it would be nice to get help from the original commiter
15:53:03 <enikher> :-)
15:53:33 <tmorin> enikher: you can ask, I'm sure the initial commiter will help :)
15:53:39 <tmorin> shall we wrap up ?
15:53:43 <tmorin> anything else to add ?
15:54:24 <enikher> is there an initiative to make a horizon plugin?
15:55:27 <tmorin> enikher: not yet, but last time we discussed, timirnich_ seemed to have an idea of someone having the right skills
15:55:34 <tmorin> that would be excellent to have
15:56:11 <enikher> tmorin: horizon or heat?
15:56:16 <tmorin> additionally to having support for the key operation in the right dialogs, we discussed the idea of having bgpvpns appear in the network topoloy
15:56:26 <timirnich_> enikher: let's have a coffee about this ;-)
15:56:26 <tmorin> enikher: horizon :)
15:56:45 <wdeclercq> Note that there's some undocumented documentation ;)   about plugins for horizon: https://review.openstack.org/#/c/233709/12/doc/source/tutorials/plugin.rst
15:56:54 <tmorin> the cloud-style network topology display could nicely be augmented with links for bgpvpns
15:57:07 <tmorin> #link  https://review.openstack.org/#/c/233709/12/doc/source/tutorials/plugin.rst
15:57:40 <tmorin> good to know !
15:57:45 <wdeclercq> we linked the same :p
15:58:09 <tmorin> wdeclercq: I just took your link to have it appear in IRC minutes
15:58:23 <tmorin> with the keyword for the IRC meeting bot
15:58:31 <wdeclercq> right
15:58:34 <tmorin> enikher: you also had Heat work in mind right ?
15:58:45 <enikher> yes
15:59:09 <enikher> tmorin: but that is not yet decided
15:59:12 <tmorin> enikher: feel free to propose a change on this as well, that would be highly welcome
15:59:15 <tmorin> enikher: ok
15:59:23 <tmorin> ok, let's wrap up
15:59:28 <tmorin> thanks everyone
15:59:39 <wdeclercq> o/
15:59:39 <tmorin> keep up the good work !  ;)
16:00:30 <tmorin> #endmeeting