16:00:50 <emagana> #startmeeting networking-guide
16:00:51 <openstack> Meeting started Thu Dec  3 16:00:50 2015 UTC and is due to finish in 60 minutes.  The chair is emagana. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:55 <openstack> The meeting name has been set to 'networking_guide'
16:00:57 <Sam-I-Am> hello
16:01:18 <emagana> #topic team
16:01:28 <emagana> hi Sam-I-Am and john-davidge
16:01:38 <emagana> ok, our first IRC
16:01:47 <Sam-I-Am> yep
16:01:51 <emagana> I need to know who else was else to attend it
16:01:56 <emagana> anyone else?
16:01:57 <Sam-I-Am> and lots to cover since the team hasnt met in months
16:02:21 <emagana> Sam-I-Am: should be easy with short audience
16:02:42 <Sam-I-Am> yeah, we need more people :/
16:02:53 <Sam-I-Am> the whole idea of irc meetings was that people didnt like hangouts
16:03:04 <Sam-I-Am> but we saw this with the install guide moving to irc too
16:03:09 <emagana> #action a reminder of this meeting and how important is
16:03:19 <Sam-I-Am> yeah that :)
16:03:26 <Sam-I-Am> i also need to add an apac meeting to the list
16:04:00 <emagana> Sam-I-Am: I wont be able to host that one, could yo do it?
16:04:15 <Sam-I-Am> yeah that was the plan
16:04:21 <Sam-I-Am> it would be in the evening here sometime
16:04:25 <emagana> Sam-I-Am: I am about including people but for this one we are just three, I dont want you to be the only one in APAC
16:04:51 <emagana> Sam-I-Am: send me your preference in time and date and I will add it to the calendar, ok?
16:04:55 <lwilliams__> hi there...sorry i'm late.
16:05:05 <emagana> lwilliams__: welcome!
16:05:07 <emagana> yeah one more!
16:05:16 <lwilliams__> thx!
16:05:19 <john-davidge> Perhaps a doodle poll on the ML to find the best times and gauge attendance?
16:05:51 <emagana> john-davidge: we did it before but minimal response
16:06:01 <Sam-I-Am> this is a good time for US/EU people
16:06:05 <Sam-I-Am> we just dont have attendees
16:06:19 <emagana> ok, let's move on
16:06:40 <emagana> #topic goals
16:07:06 <john-davidge> emagana: I probably missed that unfortunately. I didn’t realise at first that i needed to be subscribed the the openstack-docs ML, rather that the docs section of the openstack-dev ML
16:07:21 <emagana> from my perspective, it is very clear. We need to move the networking-guide from WIP to Official
16:07:43 <Sam-I-Am> is it still a wip?
16:07:50 <Sam-I-Am> i thought we published it for kilo
16:07:52 <emagana> yeap.
16:07:55 <Sam-I-Am> well, MOST of it
16:07:58 <emagana> #link http://docs.openstack.org/networking-guide/
16:08:04 <Sam-I-Am> we did not get enough contributors to finish it
16:08:07 <Sam-I-Am> and still dont have enough
16:08:09 <john-davidge> emagana: Do we have a list of sections that are still WIP?
16:08:11 <emagana> the WIP warining is still there
16:08:20 <Sam-I-Am> john-davidge: more or less anything that lacks content
16:08:25 <Sam-I-Am> or seems a bit light on content
16:08:33 <Sam-I-Am> most of it is in the 'concepts' sections
16:08:51 <emagana> john-davidge: I was trying to do that yesterday and documented in our wiki: #link https://wiki.openstack.org/wiki/NetworkingGuide/TOC#Proposed_topics_for_the_Networking_Guide
16:09:20 <Sam-I-Am> we also need a place for our meeting agenda in the wiki
16:09:23 <Sam-I-Am> or whereever
16:09:36 <emagana> Sam-I-Am: I will take care of that
16:09:40 <john-davidge> emagana: Excellent, thanks
16:09:54 <Sam-I-Am> emagana: plus some advertisement to neutron
16:10:03 <emagana> #action emagana agenda in our wiki.. basically fix the wiki, it is messy
16:10:05 <Sam-I-Am> emagana: and operators, ideally
16:10:12 <navinrio> Hi
16:10:16 <emagana> Sam-I-Am: sounds good!
16:10:18 <Sam-I-Am> hi
16:10:24 <emagana> HI navinrio.. Thanks for joining
16:10:58 <navinrio> Hi Everyone I am Navin from HP
16:11:41 <Sam-I-Am> so...
16:11:47 <emagana> my proposal is:
16:12:12 <emagana> Let's review the current status of the guide and prepare a wiki with the section that we want to complete
16:12:18 <navinrio> Yes please
16:12:23 <lwilliams__> that's a good idea
16:12:30 <Sam-I-Am> emagana: how about an etherpad?
16:12:32 <Sam-I-Am> people hate wikis
16:12:33 <john-davidge> emagana: +1
16:12:38 <lwilliams__> +1
16:12:50 <navinrio> +1
16:12:51 <emagana> make potential assignments and once those sections are completed we remove the WIP finally
16:12:59 <emagana> and make a lot of noise about it  LOL
16:13:05 <lwilliams__> i think that will help
16:13:08 <navinrio> I like etherpad
16:13:08 <john-davidge> I’m a people and I like wikis. But an eterpad will be fine too
16:13:14 <Sam-I-Am> haha
16:13:19 <lwilliams__> lol
16:13:21 <emagana> ok.. I like etherpads better. Actually, we had one already but not sure where the link is
16:13:22 <john-davidge> (as long as it’s linked on the wiki)
16:13:30 <Sam-I-Am> john-davidge: yeah, it would be linked
16:13:31 <emagana> I got my laptop stolen and a lot of data is lost
16:13:36 <Sam-I-Am> its just a little more interactive, imo
16:13:39 <navinrio> I am fine with Wiki and Etherpad
16:13:46 <john-davidge> emagana: Oh man, that sucks :(
16:13:52 <navinrio> which ever team decide
16:14:00 <emagana> #action prepare etherpad with the section to be completed as target for Mitaka
16:14:52 <Sam-I-Am> emagana: might be good to add a bp/spec for the larger picture of things to add
16:14:56 <emagana> I want to start with assignments but I rather discuss that over ML once we have the etherpad
16:15:09 <emagana> Sam-I-Am: +1
16:15:09 <Sam-I-Am> something we can at least target with patches
16:15:26 <lwilliams__> agreed
16:15:34 <emagana> Sam-I-Am: I like that idea..
16:15:44 <navinrio> I also like the idea
16:15:59 <emagana> #action create a docs-spec for the section to be completed in Mitaka cycle and target all patches to it
16:16:14 <Sam-I-Am> so how about we organize our ideas in the etherpad, then figure out what we're going to target for mitaka, then write a spec
16:16:34 <emagana> Sam-I-Am: That is what I have in mind
16:16:40 <john-davidge> Sam-I-Am: Sounds good
16:16:46 <emagana> Sam-I-Am: I will have the etherpad by EOD
16:17:05 <emagana> will send the link over ML to let everybody discuss.. we are all open ;-)
16:17:19 <lwilliams__> sounds good
16:17:24 <Sam-I-Am> also make sure neutron and ops know about it
16:17:53 <john-davidge> emagana: Yes, send links on the openstack-dev ML as well
16:17:56 <emagana> Sam-I-Am: roger that, I will include their MLs in the email
16:18:09 <Sam-I-Am> and maybe join their meetings
16:19:13 <emagana> Sam-I-Am: I am trying to re-organize my schedule to attend all those meetings.. it is just hard.. but that is the goal..
16:19:40 <emagana> should we move to the next topic, OVN in networking guide?
16:20:07 <Sam-I-Am> time is hard
16:20:13 <Sam-I-Am> yeah, so ovn...
16:20:24 <emagana> #topic OVN in networking guide
16:20:27 <Sam-I-Am> the idea around the original spec was this:
16:20:57 <Sam-I-Am> "looks like ovn is the evolution of ovs, which is a ref arch, so lets document it in a way people can use BEFORE it gets released"
16:21:22 <navinrio> Understood
16:21:33 <Sam-I-Am> but its not really a refarch yet, so this opened a can of worms for vendors and third-party folks to add their plugins and stuff to the networking guide
16:21:53 <Sam-I-Am> which is exactly what we dont want, because we've already had lots of problems with third-party content in the docs
16:21:58 <emagana> The problem for me is that .. arrgghhh  you just stole my opinion
16:22:04 <emagana> LOL..
16:22:06 <Sam-I-Am> they dump stuff in there and leave it, then it gets stale, and the docs team cant maintain it alll
16:22:12 <emagana> I agree with Sam-I-Am
16:22:40 <emagana> The idea of the networking-guide was to keep it clean and easy to follow for people who wanted to use neutron
16:22:53 <Sam-I-Am> so the question is can we write policy around what goes in the networking guide that includes something like OVN and not things like astara or plumgrid
16:23:02 <emagana> it is already hard to keep it in good shape between LB and OVS to include now OVN
16:23:11 <Sam-I-Am> if ovn was accepted as a refarch for neutron this would be different, but its not (yet)
16:23:18 <lwilliams__> i think that's fair..
16:23:22 <Sam-I-Am> russellb: wakey wakey
16:23:59 <emagana> neutron should clarify if they want to support now three official plugins
16:24:16 <Sam-I-Am> emagana: i think ovn will eventually replace conventional ovs
16:24:18 <emagana> if that is the case, then we should include OVN. simple enough
16:24:40 <emagana> Sam-I-Am: That makes things easier, we just replace OVS sections by OVN ones  :)
16:24:41 <Sam-I-Am> so the other option is writing up network-guide-like docs in the networking-ovn repo, and porting them to the networking guide when ovn becomes a thing
16:24:49 <Sam-I-Am> emagana: yeah, when ovn works :)
16:24:57 <emagana> Sam-I-Am: I second that..
16:25:05 <Sam-I-Am> eventually yes, i think conventional ovs will disappear
16:25:08 <navinrio> I agree
16:25:09 <Sam-I-Am> because its really pointless
16:25:14 <emagana> Sam-I-Am: about the porting part of course.. nothing against OVN
16:26:04 <Sam-I-Am> so if we think it makes sense to document ovn in networking-ovn, we should figure out what to do with the spec, because its no longer a docs spec
16:26:18 <emagana> Well good enough to have all the potential docs in the networking-ovn repo and then help them to move it to networking-guide?
16:26:39 <Sam-I-Am> maybe reword the spec to say initial docs are in networking-ovn and we'll port into the networking guide when ready, but this may not be mitaka
16:26:49 <Sam-I-Am> emagana: yeah good thing its all rst :)
16:27:09 <Sam-I-Am> i'm working with russellb already
16:27:22 <Sam-I-Am> i can catch up with him about it later since he's not here
16:27:48 <emagana> so, what to do with this one: #link https://review.openstack.org/#/c/252592/
16:27:53 <emagana> -2 ?
16:27:58 <Sam-I-Am> in the end it doesnt matter which repo the docs start out in - the end goal is having user/oper docs available when its released
16:28:12 <Sam-I-Am> emagana: not yet
16:28:24 <Sam-I-Am> emagana: i have a feeling i'll remove the whole spec
16:28:41 <emagana> Sam-I-Am: I will include my opinion on the review to have it documented
16:28:47 <Sam-I-Am> i'll probably discuss it with the docs ptl later
16:28:51 <Sam-I-Am> sure
16:29:06 <emagana> ok.. anything else on OVN?
16:29:14 <Sam-I-Am> i dont know where we store policies for docs, but we might replace this spec with a policy for what goes into the networking guide
16:29:24 <Sam-I-Am> thats it for me on ovn
16:29:31 <navinrio> I think we shall have comparision of ovs and ovn
16:29:44 <egon> and lb
16:29:49 <Sam-I-Am> well, maybe
16:29:58 <egon> and maybe a bit of why one vs another
16:29:59 <Sam-I-Am> ovn is ovs
16:30:01 <emagana> hi egon I did not know you were around
16:30:10 <egon> i am always around ;-)
16:30:16 <Sam-I-Am> so right now we could do a comparison between lb and ovs
16:30:29 <Sam-I-Am> ovn is simply making ovs more realistic
16:30:41 <egon> true
16:30:43 <Sam-I-Am> question is how to make an objective comparison
16:30:48 <Sam-I-Am> we're all opinionated
16:31:14 <navinrio> understood
16:31:20 <egon> well, you could hash out the most edge views
16:31:29 <egon> so you get to the real meat of the differences
16:31:34 <Sam-I-Am> there's definitely some feature support differences - linuxbridge doesnt do gre or dvr, for example
16:31:37 <navinrio> as old school people will search for ovs
16:31:52 <navinrio> and some people ovn
16:31:53 <emagana> let's do not make this a OVN - OVS - LB discussion  :-)
16:32:04 <Sam-I-Am> we see a lot of nova-net people adopting linuxbridge because nova-net uses it
16:32:07 <Sam-I-Am> but yeah :)
16:32:12 <emagana> let's move on.. to scenarios restructure
16:32:17 <Sam-I-Am> most people didnt know linuxbridge existed until we wrote the networking guide
16:32:17 <emagana> sounds good?
16:32:20 <navinrio> Ok
16:32:20 <Sam-I-Am> yep
16:32:34 <navinrio> I agree
16:32:46 <emagana> #topic restructuring legacy scenarios
16:33:00 <emagana> Sam-I-Am: Please, explain the idea here
16:33:16 <Sam-I-Am> emagana: ok
16:33:31 <Sam-I-Am> the idea of neutron was to push people toward "true" cloud networking
16:33:39 <Sam-I-Am> which is self-service private networks, a router, and floating IPs
16:33:49 <navinrio> yes
16:34:19 <Sam-I-Am> but we've figured out that neutron L3 doesn't perform/scale well and a lot of people avoid it by using provider nets (l2 only)
16:34:37 <Sam-I-Am> right now, if you want to deploy the legacy scenarios, you must use L3/routing and private networks
16:34:45 <Sam-I-Am> you can't attach a vm directly to a provider network
16:34:58 <egon> ?
16:35:17 <Sam-I-Am> egon: the ext/public network is not mapped to the compute nodes
16:35:26 <Sam-I-Am> its only attached to the network nodes
16:35:42 <Sam-I-Am> so if you try booting a vm on it, neutron blows up with a vif error because the network isnt there
16:35:47 <egon> if you're using l3 routing, you mean?
16:36:12 <emagana> Sam-I-Am: does it too soon for that functionality in neutron?
16:36:15 <Sam-I-Am> well, you have to use l3 routing
16:36:32 <emagana> I dont like to make things more complicated... they are already complicated
16:36:33 <Sam-I-Am> because there's a conventional network node, and the only attach point for the ext/public net is there
16:36:44 <egon> let's clarify this after this meeting. We're attaching VMs directly to provider networks.
16:36:53 <Sam-I-Am> emagana: its not too bad. you just add the ext-net to your compute nodes
16:37:03 <Sam-I-Am> point is - i think we need to allow people to do both
16:37:16 <emagana> Sam-I-Am: understood
16:37:28 <Sam-I-Am> they can attach vms directly to provider networks when needed, but can also create private networks and routers
16:37:30 <emagana> I haven't tried it myself..  shame on me
16:37:37 <egon> Sam-I-Am: I agree people should be able to do both, but we do... already
16:37:39 <Sam-I-Am> it works fine. the install guide does it now by default.
16:37:49 <Sam-I-Am> egon: who is 'we'
16:37:55 <egon> walmart
16:38:17 <Sam-I-Am> the thought behind this is that a lot of people come from nova-net, and like the simple provider networks option because they hear bad things about neutron L3
16:38:20 <emagana> Sam-I-Am: well, makes clear that we could do the refactoring
16:38:20 <Sam-I-Am> and dvr is too complicated
16:38:53 <Sam-I-Am> so they would have the ability to use provider networks directly, but also try private/router stuff and hopefully transition some things to it
16:39:02 <emagana> but I dont want to be very aggressive on the goals for the networking guide in mitaka
16:39:39 <egon> yeah, let's talk after the meeting. We're doing both now.
16:40:02 <Sam-I-Am> sure, its not too big of a change
16:40:02 <egon> mostly the provider network directly, though
16:40:23 <Sam-I-Am> my question was a) do we need to do this and b) should we augment the existing legacy scenarios or create new scenarios
16:40:32 <navinrio> I think in Japan Provider network deployment is more popular
16:40:33 <Sam-I-Am> also i think we need to ditch the 'legacy' wording
16:40:50 <Sam-I-Am> when we did that we were under the impression people would use dvr and l3ha, but neither of them have taken off due to bugs
16:41:01 <Sam-I-Am> so i'd change legacy to conventional or something
16:41:37 <emagana> Sam-I-Am: I would like to create new ones
16:41:45 <navinrio> so I think pros and cons of provider network , private network , dvr if time permits can be included
16:41:46 <emagana> new scenarios
16:42:03 <Sam-I-Am> then the question is do we have too many scenarios - overload
16:42:41 <Sam-I-Am> navinrio: the pros and cons would initially be linuxbridge vs. ovs... then maybe we can get into provider networks vs. private networks and DVR/L3HA
16:43:28 <emagana> Sam-I-Am: I have not strong opinion on that
16:43:47 <navinrio> Copy that
16:43:53 <egon> +1
16:44:21 <lwilliams__> might be more a question of "cost" to maintain... if that cost is low and intent of scenarios is clear, probably not a big concern on #
16:44:27 <emagana> Sam-I-Am: maybe consulting with the MLs?
16:44:30 <Sam-I-Am> so we probably need a spec for somehow adding provider nets to the existing scenarios... we'll put it in the etherpad first
16:45:01 <lwilliams__> yeah, ML discussion sounds good
16:45:21 <Sam-I-Am> which ml? the people who use/write this stuff are not on the docs list.
16:45:35 <Sam-I-Am> it would probably be ops if we're polling people
16:45:41 <emagana> Sam-I-Am: docs and ops
16:45:42 <lwilliams__> true
16:45:56 <navinrio> agree with Sam-I-am opinion
16:46:18 <Sam-I-Am> i suggest we just do ops and maybe neutron
16:46:33 <lwilliams__> agree
16:47:25 <Sam-I-Am> so i can take the ML thing
16:47:35 <Sam-I-Am> i'll post it to ops and neutron, see what sticks
16:47:52 <Sam-I-Am> if there's agreement, we can add it to the mitaka spec of things to do
16:47:54 <sc68cal> isn't x-posting discouraged?
16:47:55 <emagana> Sam-I-Am: great!
16:48:16 <Sam-I-Am> sc68cal: do them sequentially? not sure how else to handle it
16:48:58 <sc68cal> Sam-I-Am: I think probably post the actual topic to one ML, and redirect the other audience to it
16:49:24 <emagana> are we good on this topic?
16:49:31 <navinrio> Yes
16:49:31 <emagana> we have one thing leaast!
16:49:32 <Sam-I-Am> sc68cal: makes sense
16:49:34 <navinrio> I am fine
16:49:38 <Sam-I-Am> emagana: give me an action
16:49:57 <lwilliams__> out of curiosity... do we have usage #s on the existing scenarios via google analytics?
16:49:58 <emagana> my bad
16:50:14 <Sam-I-Am> lwilliams__: no, thats apparently fixed now (or soon)
16:50:21 <lwilliams__> ok, cool
16:50:29 <emagana> #action Sam-I-Am will document the changes on the etherpad and write a spec after the discussion there and ML
16:50:32 <Sam-I-Am> lwilliams__: ask annegentle for more info
16:50:47 <lwilliams__> thx
16:51:40 <emagana> #topic versioning of the networking guide
16:51:46 <Sam-I-Am> this is a big deal
16:52:00 <emagana> sc68cal: yor wrote the spec, right?
16:52:41 <emagana> you*
16:53:00 <emagana> we have just eight minutes left..
16:53:07 <Sam-I-Am> problem - neutron changes a lot from release to release, often in ways not backward compatible with previous versions
16:53:20 <Sam-I-Am> we have a lot of people who install older versions for 'stability' reasons
16:53:37 <annegentle> lwilliams__: still validating the fix works :)
16:53:49 <navinrio> I agree
16:53:51 <annegentle> lwilliams__: but sadly we have no data
16:53:59 <Sam-I-Am> pretty much anything that involves specific config (like the install and network guide) need versioning
16:54:02 <lwilliams__> thx for the update, anne:) cool!
16:54:10 <Sam-I-Am> we found out that trying to use "in X version, do Y" is too hard to maintain
16:54:21 <sc68cal> emagana: no I don't believe i did
16:54:30 <emagana> sc68cal: my bad..
16:54:32 <john-davidge> emagana: Is the debate wheher or not we should verion? Or how exactly to do it?
16:54:42 <Sam-I-Am> john-davidge: whether or not we should version it
16:54:47 <Sam-I-Am> how to do it is not a problem
16:54:51 <emagana> john-davidge: yes, the first part
16:54:54 <navinrio> I think we should version
16:54:58 <Sam-I-Am> a version gets cut with each release
16:55:03 <john-davidge> I’m of the opinion that we should version
16:55:12 <john-davidge> otherwise the guides will become very messy
16:55:23 <navinrio> +
16:55:27 <sc68cal> I think we probably have to, just based on how much changes as we go forward
16:55:29 <navinrio> +1
16:55:32 <emagana> based on how much things change, we should tag after Mitaka
16:55:52 <Sam-I-Am> well here's the problem
16:56:09 <Sam-I-Am> right now the guide is for kilo, so tagging it for liberty wouldnt work
16:56:20 <Sam-I-Am> we could update it for liberty and tag but then we lose the kilo stuff
16:56:42 <Sam-I-Am> so if we can tag for kilo now that'd be great, then update master for liberty, then cut that
16:57:09 <emagana> Sam-I-Am: targetting Kilo makes more sense
16:57:10 <john-davidge> Sam-I-Am: There may already be some content that is liberty-specific
16:57:24 <sc68cal> We could tag it based on the commit date
16:57:39 <sc68cal> find a SHA of the networking guide from the kilo timeframe, tag that as kilo
16:57:57 <Sam-I-Am> sc68cal: yeah that makes sense
16:58:05 <john-davidge> sc68cal: that sounds goof
16:58:09 <john-davidge> *good
16:58:12 <sc68cal> :)
16:58:14 <Sam-I-Am> sc68cal: sounds like you just volunteered :)
16:58:19 <john-davidge> :D
16:58:23 <sc68cal> Sam-I-Am: done - i'll do it now
16:58:27 <emagana> sc68cal: I am ready to add the action  :-)
16:58:41 <Sam-I-Am> so tag kilo -> do liberty updates -> tag liberty -> then do mitaka updates in master
16:58:56 <Sam-I-Am> this changes the strategy we've been using a little too:
16:58:58 <emagana> #action sc68cal will tag networking guide
16:59:10 <sc68cal> kilo was ..... last fall
16:59:12 <sc68cal> right?
16:59:16 <emagana> ok, one minute left... wow.. long meeting
16:59:19 <Sam-I-Am> with CD, we usually waited until the end of the current release cycle to update the guide for that release cycle
16:59:23 <Sam-I-Am> sc68cal: spring
16:59:26 <Sam-I-Am> 2015.1
16:59:30 <sc68cal> Sam-I-Am: thanks
16:59:37 <john-davidge> Does this mean w should plan to remove kilo and liberty specific sections for Mitaka?
16:59:49 <Sam-I-Am> now we'll have to update the guide prior to release when we tag the release
16:59:57 <emagana> john-davidge: I would like to identify those sections first
17:00:06 <Sam-I-Am> emagana: we should move the meeting to #openstack-doc
17:00:10 <emagana> we are over time
17:00:15 <emagana> let's move the conversation..
17:00:19 <emagana> #end-meeting
17:00:20 <john-davidge> byeeee
17:00:20 <navinrio> ok
17:00:23 <lwilliams__> bye
17:00:31 <emagana> #endmeeting