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