15:04:59 <tmorin> #startmeeting bgpvpn
15:04:59 <openstack> Meeting started Tue Jan 26 15:04:59 2016 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:05:03 <openstack> The meeting name has been set to 'bgpvpn'
15:05:10 <tmorin> hi doude
15:05:11 <Sam-I-Am> hello.
15:05:22 <tmorin> hi pcarver
15:05:27 <tmorin> hi Sam-I-Am
15:05:31 <tmorin> hi timirnich
15:05:32 <Sam-I-Am> i haven't seen y'all in a while
15:05:41 <pcarver> hi
15:05:57 <tmorin> Sam-I-Am: good to see you
15:06:06 <timirnich> hi tmorin, hi all
15:06:29 <doude> hi
15:06:44 <tmorin> let's start
15:07:04 <tmorin> is there anything particular to announce ?
15:07:13 <tmorin> (I don't think so, but maybe someone else ?)
15:08:19 <tmorin> #topic stable/liberty
15:08:36 <tmorin> there is one change under review by vishal for stable/liberty
15:08:48 <tmorin> #link https://review.openstack.org/#/c/271933/
15:09:20 <tmorin> the issue that we will have to address is that this is not the typical bugfix change
15:09:40 <tmorin> however stable/* branches should only receive bugfix patches
15:10:12 <tmorin> we haven't identified yet the proper way of working on new features for a release for which we already have a stable branch
15:10:25 <matrohon> let's ask ihrachys if he agrees on the patch
15:10:30 <matrohon> ihrachys, hi
15:10:35 <ihrachys> hi. what's up
15:10:45 <tmorin> the topic is https://review.openstack.org/#/c/271933/
15:10:55 <matrohon> ihrachys, we have a patch under review for 271933
15:11:03 <tmorin> it's a change on the stable/liberty branch of net-bgpvpn
15:11:16 <matrohon> we wonder if the stable team agree to merge it
15:11:24 <tmorin> this is not the typical bugfix patch on a stable branch
15:11:35 <ihrachys> ok. we'll get to it, there is usually some delay before maintainers catch up with new uploads
15:11:45 <tmorin> but net-bgpvpn is *not* tagged as has-stable-branches
15:12:13 <tmorin> ihrachys: np, we're not in need of a very quick answer
15:12:13 <ihrachys> hm. should it?
15:12:24 <ihrachys> ok, then let's wait a bit, if no rush
15:13:07 <tmorin> we're wondering about the kind of work we would be allowed to do in a branch called stable/x
15:14:02 <timirnich> enikher: are you listeing in?
15:14:09 <tmorin> ihrachys: I don't think that "has-stable-branches: no" is the issue (that fits well with the relative yougness of the project)
15:14:11 <enikher> yes
15:14:35 <tmorin> ihrachys: the question is more a matter of doing the right thing wrt community practices
15:14:52 <ihrachys> tmorin: I guess there are infra issues that probably justify you using the branches without the tag
15:15:23 <ihrachys> I don't see anything wrong with the patch, I will get back to it later
15:15:59 <tmorin> ihrachys: yes, that was needed to do a release, I think
15:16:22 <tmorin> ihrachys: yes, technically even though it is not the typical bugfix, the change introduces no risk of regression
15:17:04 <tmorin> think about it, and feel free to tell us what you/stable-maintainers think
15:17:07 <tmorin> thanks!
15:17:16 <ihrachys> ok
15:17:50 <tmorin> next topic ?
15:18:36 <enikher> I have a question...
15:18:46 <tmorin> go ahead :)
15:18:47 <enikher> the would not be a topic as such :-)
15:19:11 <enikher> ok, for bagpipe we are reusing normal neutron ovs
15:19:32 <enikher> can you explain why there is an extra hop in the bagpipe architecture
15:20:16 <tmorin> you mean extra hop in terms of OVS bridges ?
15:20:19 <enikher> may be no one else is intressted then we don't have to talk in this meeting about that
15:20:25 <enikher> I think so
15:20:28 <tmorin> br-tun connected to br-mpls via a patch port ?
15:20:47 <enikher> I got to know that this is some kind of draw back fro bagpipe impl
15:20:59 <tmorin> ok to talk about that later in the meeting and address non-driver-specific question first ?
15:21:07 <enikher> is that consuming cpu load
15:22:03 <enikher> sure!
15:22:04 <tmorin> enikher: sounds like a dubious claim, but we can look at it later today
15:22:11 <tmorin> #topic static routes
15:22:26 <tmorin> just a very quick update on the topic
15:22:57 <tmorin> me and Jan Scheurich we've been working to consolidate the question around the different use cases for static routes
15:23:19 <tmorin> we may have to revisit the initial proposal (static routes as an attribute of a Port association)
15:23:34 <tmorin> but we need to work more before we're sure of what will make sense
15:23:40 <tmorin> any question on this ?
15:24:21 <tmorin> ok.. next topic...
15:24:27 <tmorin> #topic API features
15:24:43 <tmorin> This topic is a bit a call for volunteers
15:24:59 <tmorin> there are a bunch of things that have been specified as part of the initial work on the API
15:25:08 <tmorin> but that still lack an implementation
15:25:35 <tmorin> http://docs.openstack.org/developer/networking-bgpvpn/future/attributes.html
15:25:38 <tmorin> #link http://docs.openstack.org/developer/networking-bgpvpn/future/attributes.html
15:26:07 <tmorin> some of these should be quite straightforward to implement (e.g. admin_state_up)
15:27:02 <tmorin> 'technique' is fairly easy to implement, but just will require possibly a bit more discussion
15:27:34 <tmorin> 'vnid' will possibly be covered by folks working on BGP dyn routing (would need to be confirmed with Sid)
15:28:13 <tmorin> overall, I just wanted to state that for this kind of addition to land, we need people to stand up and work on them
15:28:33 <tmorin> if they are less needed, they may remain unimplemented
15:28:53 <tmorin> thoughts anyone ?
15:29:45 <matrohon> the most difficult part is to have an identical behavior of this technique attribute from one driver to another, no?
15:30:32 <tmorin> indeed, that would need to be done right
15:30:42 <tmorin> the list of possible technique would have to be constrained
15:30:59 <tmorin> I think we should have constants defined in the service plugin
15:31:13 <tmorin> then a driver would advertise the one it supports
15:31:37 <timirnich> tmorin let me look into the issues a bit more but generally we are planning to put some energy into BGPVPN
15:31:50 <tmorin> I makes me think it will become obvious at some point that we need a pre_commit hook in the drivers
15:31:57 <matrohon> timirnich, great news :)
15:32:02 <tmorin> timirnich: good :)
15:32:28 <tmorin> timirnich: I guess the next question is on what exactly to put the energy on
15:32:56 <Sam-I-Am> docs :)
15:33:35 <timirnich> yes that is indeed the question - no clear visibility now
15:33:44 <matrohon> Sam-I-Am, That remind me that I have an AP that I missed :)
15:34:13 <Sam-I-Am> matrohon: ap?
15:34:18 <tmorin> timirnich: no rush, but I think we'll need to build a common vision of what we'll try to achieve for mitaka timeframe
15:34:21 <matrohon> Sam-I-Am, Action point
15:34:35 <tmorin> doc as the next topic ?
15:34:37 <Sam-I-Am> ah ok
15:34:47 <Sam-I-Am> you know thats what i'm here to bug you about :)
15:34:50 <tmorin> #topic documentation
15:35:14 <tmorin> the short term thing that lacks more is the quick installation information
15:35:34 <matrohon> Sam-I-Am, :) I was expecting you to come back one day :)
15:35:35 <tmorin> http://docs.openstack.org/developer/networking-bgpvpn/installation.html
15:35:55 <Sam-I-Am> matrohon: yeah meeting has been at a bad time for a bit
15:35:57 <tmorin> to many occurences of "To Be Completed" there
15:36:28 <Sam-I-Am> tmorin: yeah :/
15:36:38 <Sam-I-Am> so here's question - do distros intend to package this?
15:36:45 <Sam-I-Am> or will it always be just source
15:37:12 <matrohon> Sam-I-Am, there is also a pypi package :)
15:37:16 <tmorin> Sam-I-Am: we expect some distro to ship this at some point
15:37:27 <tmorin> although we don't have visibility on the exact roadmap
15:37:45 <Sam-I-Am> ok. reason i ask it usually combining a pip install w/ distro packages makes a mess of the host... in which case the preference should always be venv
15:37:54 <Sam-I-Am> some people dont know that and they break a lot of things
15:38:20 <Sam-I-Am> venvs are a lot cleaner if they'll work
15:38:24 <tmorin> I guess we can document as "do pip install unless your distro packages networking-bgpvpn"
15:38:57 <Sam-I-Am> something like that
15:39:09 <matrohon> Sam-I-Am, I agree with Sam-I-Am : we should say do pip install in your neutron venv
15:39:39 <Sam-I-Am> matrohon: that was the next question - does it require neutron stuff in the same venv
15:40:42 <matrohon> Sam-I-Am, it's a service plugin, like vpnaas or lbaas, they are usually installed in the same venv as neutron-server, no?
15:41:10 <tmorin> Sam-I-Am: the neutron server should be able to instantiation the service plugin
15:41:20 <Sam-I-Am> not sure. but i know that people using distro packages wont have a neutron venv, so we'd have to consider that case
15:41:21 <tmorin> Sam-I-Am: has to be in the same venv I think
15:41:54 <tmorin> Sam-I-Am: do the openstack docs usually get into these kind of considerations ?
15:42:02 <Sam-I-Am> tmorin: depends on the doc
15:42:26 <Sam-I-Am> for first time users who want to experiment, we at least need some notes to point them in the right direction
15:42:27 <tmorin> Sam-I-Am: I would expect the doc to say "use pip install or follow whatever practices you have for python and openstack"
15:42:50 <Sam-I-Am> it depends on where you want to set the barrier to entry
15:43:00 <tmorin> Sam-I-Am: that could be achieved with a tutorial using one specific Openstack distro as an example
15:43:02 <Sam-I-Am> the easier you make the grunt work, the more people will try your project
15:43:29 <tmorin> Sam-I-Am: very true
15:43:48 <Sam-I-Am> a lot of people trying to deploy openstack are not python developers
15:44:12 <Sam-I-Am> my suggestion would be the following...
15:44:49 <Sam-I-Am> in the networking guide, you can assume people have installed the right stuff. for example, maybe you can build off one of the existing scenarios. "do this stuff, make sure it works, then configure bgpvpn"
15:45:25 <Sam-I-Am> bgpvpn is a bit interesting because it requires infrastructure to work, but the least you can do is provide people with the most common options they'd configure in various places
15:45:37 <Sam-I-Am> and some examples of what the output would look like from various commands to show it works
15:45:50 <Sam-I-Am> so if you have a working environment, that would be a good thing to model in the networking guide
15:47:53 <tmorin> Sam-I-Am: the issue, I have, to be fully honest, is that (this is actually true for most backends), some amount of tweaking will be required based on a basic installation to have eveyrthing in place
15:48:53 <tmorin> Sam-I-Am: for instance, for the bagpipe driver, whether you'll need a git or very recent OVS to be able to do MPLS-in-tunnels, or you'll have to tweak the interface/bridge/OVS config to do the right thing
15:49:35 <Sam-I-Am> hmmm
15:50:02 <Sam-I-Am> well, for openvswitch you can specify a minimum version
15:50:03 <tmorin> it's hard for me to picture a python/linux/openstack newbie easily doing all that based on a generic documentation
15:50:22 <tmorin> yes, that can be documented
15:50:55 <Sam-I-Am> i think this caters more toward operators with linux and network experience, but not necessarily developers
15:51:12 <tmorin> but someone confortable with compiling/installing a recent or git version of OVS, is likely to have basic understanding of what needs to be done to have python packages properly installed
15:51:25 <tmorin> Sam-I-Am: correct
15:52:05 <Sam-I-Am> yeah, hence why you can get by with 'you'll need this version of ovs and need to install bgpvpn. here's a couple of hints on how to do the latter..."
15:52:10 <tmorin> my point is just that getting into venv/pypi/distro packages questions looks to me as too much detailed compared to the amount of system skills that are still required to do the rest
15:52:23 <tmorin> yes, that would work
15:52:42 <tmorin> but I don't think we need to talk about venv or about competing pypi/distro packages
15:54:58 <Sam-I-Am> it all depends on your target audience
15:55:20 <Sam-I-Am> if you write docs in the docs repo and people file a lot of bugs about stuff you thought was easy, then you might need to re-think it
15:55:56 <tmorin> Sam-I-Am: yes, I don't know what the typical audience expects
15:56:50 <Sam-I-Am> i'm going to guess these are network-centric operators who want to make openstack work with their bgpvpn infrastructure
15:57:03 <Sam-I-Am> so they're more likely to know the bgp bits than the openstack bits
15:58:12 <tmorin> Sam-I-Am: true
15:58:34 <tmorin> but the starting point for these people, I think, is more likely to be openstack distro vendors, than openstack.org docs
15:58:38 <Sam-I-Am> so the key here is 'how do i make what i'm used to looking at work with openstack'
15:58:54 <Sam-I-Am> so things in neutron config files, openvswitch configs, etc.
15:58:56 <tmorin> or people working for these operators and already having linux/system/python skills
15:59:01 <Sam-I-Am> diagrams go a long way
15:59:08 <Sam-I-Am> giving people a picture of how it all fits is important
15:59:17 <tmorin> yes, this is the really important part
15:59:27 <tmorin> hey I didn't look at the watch
15:59:45 <Sam-I-Am> so maybe think about some visuals to make it easier
15:59:50 <Sam-I-Am> and yeah, its an hour already
16:00:09 <tmorin> yes
16:00:18 <tmorin> let's pursue the discussion later/next time
16:00:25 <Sam-I-Am> yep, thanks for the chat
16:00:29 <tmorin> everyone, anything to add?
16:00:33 <Sam-I-Am> you can always find me in -neutron or -doc
16:00:40 <tmorin> (no *has* to be the answer)
16:00:47 <tmorin> thanks Sam-I-Am
16:01:03 <tmorin> bye everyone!
16:01:07 <tmorin> #endmeeting