21:01:00 <mestery> #startmeeting networking
21:01:01 <openstack> Meeting started Mon Oct 27 21:01:00 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:04 <openstack> The meeting name has been set to 'networking'
21:01:08 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:01:19 <mestery> #topic Announcements
21:01:30 <mestery> The Kilo Design Agenda has been published!
21:01:31 <mestery> #link http://kilodesignsummit.sched.org/overview/type/neutron#.VE5G_9YweYw
21:01:56 <Swami> hi
21:02:05 <mestery> The only slot left to fill is the lightning talk slots
21:02:14 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-October/049090.html
21:02:24 <mestery> That is the lightning talk submission email, thanks to those who submitted talks!
21:02:29 <mestery> #link https://etherpad.openstack.org/p/neutron-kilo-lightning-talks
21:02:35 <mestery> I wanted to encourage folks to add their name to the list.
21:02:40 <emagana> hello!
21:02:53 <mestery> I'll be sending out the link for a SurveyMonkey soon so we can vote on the talks.
21:03:08 <mestery> Does anyone need more time to add their talk to the list?
21:04:11 <mestery> OK, one last announcement: I've been working with the LBaaS team to merge their patches into the feature/lbaasv2 branch
21:04:12 <mestery> #link https://etherpad.openstack.org/p/lbaas_reviews
21:04:18 <marun_> I quite liked 'Tips on getting reviewers to block your changes'
21:04:21 <mestery> I encourage cores who have time to review there.
21:04:24 <emagana> mestery: Just added minie
21:04:29 <mestery> emagana: Thanks sir!
21:04:34 <marun_> It would be a shame if nobody put their name to it.
21:04:50 * marun_ is sorry for the digression
21:04:51 <mestery> marun_: Maybe we make that one a team lightning talk if no one claims it?
21:04:59 <marun_> mestery: +1
21:05:05 <blogan> i figured that was a typo and meant unblock
21:05:14 <mestery> lol
21:05:29 <dougwig> blogan: the optimist among us.
21:05:29 <armax> blogan: that would’ve made more sense :)
21:05:54 <mestery> Either way, as marun_ said, hopefully someone claims it as it would be a useful lightning talk
21:06:14 <mestery> Any other announcements for the team this week ... the final meeting before the summit?
21:06:44 <mhanif_> Question: Have we started to build the Kilo project plan?  If not, when does that work being?
21:06:46 <Sukhdev> mestery: are you going to make it to Paris or not?
21:07:00 <mhanif_> I meant to say begin?
21:07:01 <mestery> mhanif_: Yes, partially, and it will fall out of the design summit a bit as well.
21:07:03 <marun_> mhanif_: I think that would be post-summit.
21:07:22 <mestery> Sukhdev: I will not be in Paris, my fourth child is due 11-7, I'll be home welcoming the latest Mestery into the world.
21:07:26 <marun_> mhanif_: Though the topics under discussion are a good indication of what the priorities are likely to be.
21:07:36 <blogan> mestery needs to get his priorities straight
21:07:49 <dougwig> mestery: something that costs more sleep than being PTL.  nice.
21:07:52 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-October/047954.html
21:07:56 <mhanif_> mestery: Thanks.  If partially, is there a link where we keep this information?
21:07:56 <mestery> mhanif_: See ^^^
21:08:04 <mestery> blogan: lol
21:08:14 <mestery> dougwig: It was hard to find, but I think I nailed it.
21:08:22 <yamamoto> what's "Neutron contributors meetup"
21:08:34 <mestery> yamamoto: A round table we get on Friday :)
21:08:42 <mestery> I'm hoping people will signup for slots there
21:08:47 <mestery> To talk about things which have a smaller auidence, etc.
21:08:50 <glebo> mestery: congrats on #4
21:09:00 <glebo> mestery: so cool
21:09:00 <mestery> glebo: thanks :)
21:09:55 <mestery> So, just to circle back: LBaaS reviews! It woudl be great to get some folks on the final large patch and try to merge it prior to the summit. Rumour has it blogan and dougwig are buying drinks if it lands. :)
21:10:11 <blogan> just dougwig
21:10:15 <emagana> mestery: I like the agenda very much.. It is completely focus on Neutron request  But nothing on the Nova-network deprecation!!
21:10:22 <glebo> dougwig: very funny, sleep comment. Soooo true!
21:10:23 <Sukhdev> mestery: What is the criteria to sign up for the round table discussion topics?
21:10:33 <dougwig> i will totally buy drinks if it lands.
21:10:47 <mestery> emagana: There is a nova slot for that
21:10:51 <ptoohill> Holding ya to that ;)
21:11:02 <mestery> Sukhdev: I don't know yet, I'm assuming a whiteboard will hve time, but I'll create an etherpad for it iinstead.
21:11:12 <mestery> #action mestery to create etherpad with table discussion slots
21:11:14 * glebo likes dougwig buying drinks
21:11:48 <mestery> OK, lets move on
21:11:49 <emagana> mestery: Thanks!
21:11:53 <Sukhdev> mestery: we have couple of ideas about ML2 discussions - this round table will be nice for that
21:11:53 <mestery> emagana: Sure thing!
21:11:59 <mestery> Sukhdev: Perfect!
21:12:18 <mestery> #topic Bugs
21:12:23 * mestery pokes enikanorov ...
21:12:24 <mestery> enikanorov: here?
21:12:47 <mestery> And if not, I encourage folks to discuss bugs here.
21:13:47 <salv-orlando> armax is taking on a gate breaking bug I think
21:14:02 <salv-orlando> but I do not have bug # at hand unfortunately
21:14:03 <armax> salv-orlando: I delegated carl_baldwin
21:14:16 <armax> salv-orlando: #link https://bugs.launchpad.net/neutron/+bug/1381617
21:14:18 <uvirtbot> Launchpad bug 1381617 in neutron "Check for FIP status in scenario tests cause instability in neutron gate jobs" [High,In progress]
21:14:25 <mestery> That's 3 levels of nesting, has carl_baldwin delegated to someone else yet?
21:14:40 <armax> mestery: nope
21:14:46 <mestery> :)
21:14:46 <armax> his patch is up for review
21:14:50 <mestery> armax: Nice!
21:14:58 <carl_baldwin> carl_baldwin: Nope, still me.
21:15:23 <blogan> nice self reference!
21:15:26 <blogan> i do it all the time
21:15:49 <dougwig> you had an opportunity to go meta there, and instead used 'i'
21:15:50 <mestery> carl_baldwin: Thanks for addressing that one.
21:16:06 <mestery> Any other bugs the team should be aware of this week?
21:16:13 <carl_baldwin> mestery: glad to help
21:16:20 <carl_baldwin> #link https://review.openstack.org/#/c/130655/
21:16:42 <mestery> Post Summit, I'd like to see us run a few bug scrub days, we haev a LOT of bugs open, and getting eyes on them would be good.
21:16:52 <markmcclain> #link https://launchpad.net/bugs/1380787 XML is dead
21:16:53 <uvirtbot> Launchpad bug 1380787 in neutron "remove XML support" [High,In progress]
21:17:11 <mestery> markmcclain: Just +A'd that one.
21:17:58 <mestery> OK, lets move this meeting along!
21:17:59 <mestery> #topic Docs
21:18:06 <mestery> emagana: Hey! Any updates on things this week>?
21:18:16 <emagana> mestery: Not really!
21:18:30 <emagana> We did not have last friday networking docs meeting
21:18:33 <mestery> emagana: OK sir, no problem. Keep us apprised of things there as they evolve!
21:18:35 <emagana> So, nothing to report!!
21:18:41 <mestery> OK, we'll move on then. Thanks!
21:18:52 <mestery> #topic Trunk Port Discussion
21:18:59 <mestery> sgordon_ ijw: Here?
21:19:02 <markmcclain> mestery: thanks.. just wanted to let folks we actually did remove it this time
21:19:05 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-October/048957.html
21:19:11 <sgordon_> mestery, yessir
21:19:29 <mestery> I'd like us to use this time to try and come to a consensus on this issue.
21:19:36 <mestery> It's important for many players in the NFV space.
21:19:42 <mestery> There are multiple proposals out there:
21:19:47 <mestery> #link https://review.openstack.org/#/c/94612/
21:19:51 <mestery> #link https://review.openstack.org/#/c/97714
21:19:55 * mestery is missing one ...
21:20:24 <sgordon_> can never have too many specs right...
21:20:33 <mestery> ijw sent an email with some good thoughts on this. Would you care to summarize for us?
21:20:37 <mestery> sgordon_: So true.
21:21:19 <sgordon_> http://lists.openstack.org/pipermail/openstack-dev/2014-October/049270.html
21:21:22 <sgordon_> that's the email
21:21:35 <mestery> sgordon_: I think it comes down to what use cases we want to solve here.
21:21:48 <mestery> sgordon_: Can you summarize what the NFV group wants addressed?
21:21:56 <sgordon_> i think his main point was  having a flag to indicate that a network was passing VLAN tagged packets
21:22:01 <ijw> Sorry, distracted
21:22:08 <ijw> We have different aims, basically.
21:22:10 <mestery> ijw: Welcome back.
21:22:35 <sgordon_> in a galaxy far far away cloudon had attempted to summarize here: http://lists.openstack.org/pipermail/openstack-dev/2014-October/047548.html
21:22:57 <ijw> The most straightforward, and non-negotiable, I think, is that we have to have networks that pass VLAN tagged traffic when they're requested, totally aside from whether we can split or combine VLANs in networks.
21:23:16 <sgordon_> right
21:23:25 <mestery> ijw: Make sense.
21:23:34 <ijw> On splitting and combining, the two options are a block that does it (sort of like an L2 router, which is why it's been called a 'gateway' in the past), or a special kind of port that attaches to multiple networks simultaneously.
21:24:29 <ijw> They would appear to do largely the same thing, but they actually serve different uses - the gateway is particularly useful if you're sending packets out of a cloud, and the port is more useful if you have a 'service' VM.
21:25:08 <ijw> To be perfectly honest, I think I would accept specs for all three of these things, work on the assumption that they're *not* competing ideas, and approve or decline them on their individual merits.
21:25:31 <mestery> ijw: The "pass VLAN tagged traffic" thing seems straightforward enough for one.
21:25:55 <rkukura> Is the assumption in these proposals that the deployment is using VLANs for tenant network isolation, and some subset of those VLANs are to be trunked to certain VMs, or is it that any kind of tenant network isolation may be in use, and each VM wants some subset of the tenant networks trunked on specific VLANs? These seem very different to me.
21:26:05 <ijw> The only thing I would add is that the last gateway proposal was immensely complex by the end of it, partly because it was trying to accommodate network infrastructures that didn't pass VLAN tagged packets and used VLANs as the underlying encap.  I would avoid letting that drive a solution, and go with something very simple.
21:26:28 <ijw> rkukura: I think it's important that we make *absolutely no* assumption about the underlying deployment.
21:26:31 <mestery> rkukura: No, not for the "pass VLAN tagged traffic" idea. Not at all. It coudl be tunnels.
21:26:34 <armax> my suggestion would be to make sure that a blueprint is scoped in a way that can be completed in the span of a cycle
21:26:35 <mestery> ijw: Yes, what you said.
21:27:10 <mestery> Do we feel like any of the existing specs accurately captures these three use cases ijw?
21:27:11 <ijw> rkukura: The only accommodation I would give is that we accept that, in some circumstances, networks will *not* pass VLANs by default and that's why a special flag on networks is required.
21:27:47 <ijw> The VLAN transparent networking one is fine, and I'd have to recheck what Erik did on the port based one (it may have predated specs).  The gateway one needs a going over.
21:28:15 <sgordon_> i think erik's had a spec as well
21:28:19 <ijw> armax: I would agree - simple and extensible, or even simple and wrong, trumps comprehensive and unfinishable.
21:28:21 <bmelande> For service in VM, enabling VLAN tagged packets on VM VIF (one VLAN per Neutron network), makes it simple to attach service instance in the VM to those neutron networks.
21:28:23 <sgordon_> there was one older proposal in mestery's email
21:28:56 <armax> ijw: yes, also I think there’s value in tracking vlan-to-the-vm and l2-gw separately
21:29:04 <SridharRamaswamy> bmelande: +1
21:29:33 <rkukura> ijw: So this is new kind of network that passes VLAN tags, not a special kind of port that presents normal networks on VLANs?
21:30:05 <bmelande> armax: I also think that makes sense
21:30:35 <ijw> rkukura: So: we would have a network that passes VLANs, *and* a port that can be attached to multiple networks, *and* a gateway block that decomposed trunks, potentially.
21:31:05 <ijw> As I say: wait and judge the specs, but please just avoid the assumption that doing one or two of these means the third is not required.
21:31:34 <ijw> Any other opinions?
21:31:38 <rkukura> ijw: I’ll review the specs.
21:31:40 <marun_> ijw: I think the problem here isn't the specs
21:31:55 <marun_> ijw: I think it's a lack of cohesive communication as the use-cases involved.
21:32:10 <ijw> marun_: Where do you want that documenting?
21:32:14 <salv-orlando> what changes in the mgmt layer (ie: APIs) are need for the spec where we allow networks to pass VLAN tagged traffic?
21:32:22 <marun_> ijw: Your email to the list did a better job than the specs have done those far, imho.
21:32:42 <marun_> ijw: that was my reasoning behind attempting to unify the specs, or at least providing an overarching one
21:32:44 <ijw> salv-orlando: That spec exists, but basically it's one extra flag on a network
21:33:09 <marun_> ijw: so there could be an opportunity for more cohesive/comprehensive documentation of the use-case and how they related
21:33:10 <ijw> marun_: I prefer specs that can be signed off complete, which is why I suggest separate ones, but I agree that the commonality has to be clearly written out somewhere
21:33:11 <marun_> relate
21:33:24 <bmelande> marun_: You think #link https://review.openstack.org/#/c/94612/ is unclear?
21:33:50 <marun_> bmelande: I think the relationship between the different use-cases is not clear
21:34:15 <marun_> bmelande: It's hard for someone unfamiliar with nfv to sign off on things without a view of the bigger picture.
21:34:40 <marun_> ijw: I don't have a problem with smaller specs. I think there needs to be better communication about the efforts as a whole and how they relate.
21:34:47 <marun_> ijw: Rather than expecting reviewers to infer.
21:34:59 <ijw> marun_: In fact, the only essential one for NFV is the trunk network one.
21:35:11 <marun_> ijw: That's not sufficient detail.
21:35:20 <marun_> ijw: If we don't understand the 'why', the 'how' doesn't matter.
21:35:22 <ijw> marun_: This is IRC, not documentation ;)
21:35:27 <salv-orlando> ijw: I remember that, I was trying to recollect the change needed at the API layer. I understand the differences between what ijw and erikmoe propose. My only point is that I would like to achieve that and at the same time not defer the complexity to the API consumer. Ie: do I need a trunk port or a vlan passing network? That is a decision which might be taken by the deployer or the cloud admin, but definetely not the tenant
21:35:31 <marun_> ijw: I'm not talking about irc.
21:35:47 <salv-orlando> tenant == regular API consumer
21:35:54 <marun_> ijw: I'm asking for an overarching spec/doc/whatever that will give context to the individual efforts around vlan trunk ports.
21:36:09 <ijw> salv-orlando: That is exactly a decision for the tenant, because some things solve some tenant problems and not others, but as marun_ says that needs documentation to make clear.
21:36:19 <salv-orlando> If we agree on that point I’m happy to approve as many approaches you wish to have to pass traffic for NFV use cases
21:36:50 <salv-orlando> ijw: you think of a tenant as somebody who’s designing a sort of data center in the cloud?
21:37:11 <ijw> salv-orlando: I think of a tenant as someone who's trying to use a cloud.  NFV applications are tenant applications.
21:37:31 <ijw> Even aaS VMs are tenant VMs, in a sense.
21:37:38 <ijw> (just not the consuming tenant)
21:38:13 <ijw> salv-orlando: And that was my point on the ML, that we make the hard things possible.  If we simplify the API to the point that some things are impossible, then we have a problem.
21:38:27 <salv-orlando> ijw: well we’re entering the meta-cloud level here… the cloud which uses the cloud! For the NFV application use case I agree however it is a sensible decision to let it decide how the traffic should be passed
21:38:44 <glebo> ijw:  could NFV be an app run as part of the infrastructure by the cloud provider FOR a service delivered TO the tenant?
21:39:25 <ijw> glebo: I would argue that NFV is always a tenant application in its purest sense, but on the other hand a network function plus a multiplexing layer does indeed make a resellable service, yes
21:39:26 <glebo> in this case it still NFV (/me thinks), still a service, but now under the administrative control of the provider infrastructure, and not under tenant control
21:39:37 <salv-orlando> ijw: “simple” is a word with a very relative meaning. If the user is, for instance, a cloud application like nodepool, simple is much different from what simple means for a NFV application
21:39:50 <glebo> ijw: thx for clarification
21:40:05 <ijw> salv-orlando: Indeed, and I'm not trying to simplify NFV in that respect, I'm only trying to make it possible.
21:40:08 <salv-orlando> the former wants no control over the network, just use it, whereas the latter needs to dictate how things should work at data plane layer
21:40:27 <glebo> i've found a lot recently that in thinking through use cases we need to clarify who controls the resource, i.e. how is the admin on it, vs who consumes it
21:40:55 <ijw> salv-orlando: On the whole, the latter wants to mainly have networks that work like wired networks (the VLAN transparency).  L2 gateways is a small step over that into what a managed switch would usually provide, granted.
21:41:05 <ijw> But that, being a service, could easily be turned off.
21:41:05 <bmelande> glebo: +1
21:41:07 <mestery> Folks, we have 20 minutes left and ideally we'll lave most of that to at least touch on the advanced services split.
21:41:29 <mestery> I think we've got the ball in motion on this trunking thing now, I'm hopeful people can come out of hte summit understanding hte use cases with some solid specs proposed.
21:41:33 * mestery looks at ijw.
21:42:29 <ijw> We're going to have to take this back to the ML, but I think the point is that trunks are easily agreed, there are some people with issues on the other two proposals, and I'll try and better articulate the use cases to make it clear what proposals we need.
21:42:30 * sballe looking forward to the discussion on Advance Services split
21:42:32 <mestery> #topic Advanced Services Spinout
21:42:36 <salv-orlando> I want to implented a gateway which converts vlan tagged trunks into ice creams
21:42:40 <mestery> ijw: Agreed.
21:42:53 <mestery> OK, per the discussion today, there is a Summit slot for this.
21:43:11 <salv-orlando> and when traffic tagged with a specific vlan tag pass, I want boy george to show up singing karma chameleon
21:43:12 <sbalukoff> salv-orlando: Sign me up, too.
21:43:26 <xgerman> ice cream? I am in!
21:43:27 <Sukhdev> salv-orlando: I am in
21:43:38 * mestery ratholes on ice cream.
21:43:46 <mestery> This is why we can't have nice things. :)
21:43:49 <blogan> lol
21:43:56 <sbalukoff> haha
21:44:03 <blogan> so what are the details on a split?
21:44:05 <mestery> OK, who's in favor of splitting out the chocolate from the vanilla ice cream?
21:44:06 <dougwig> lol
21:44:16 * dougwig raises hand.
21:44:16 * sbalukoff raises a hand
21:44:18 <blogan> banana split
21:44:20 <glebo> lmao
21:44:20 <mestery> lol
21:44:22 <ijw> We can put the strawberry in between.
21:44:29 <dougwig> ugh, heathens.
21:44:34 <blogan> way to go salv-orlando
21:44:42 <ijw> So, I believe at one point we were talking about networking?
21:44:43 * mestery ratholes on whether fruit should be considered a desert.
21:44:48 <glebo> salv-orlando: boy george reference was the best part. Looooong time since I've pictured that character.
21:44:49 <mestery> ijw: Indeed
21:44:53 <mestery> OK
21:44:57 <mestery> Advanced Services split.
21:44:59 <blogan> mestery: maybe a dessert but definitely not a desert
21:45:01 <mestery> Summit Session.
21:45:04 <mestery> lol
21:45:12 <ijw> Sumit session?
21:45:13 <dougwig> mestery: you are doomed here.
21:45:20 <sballe> dougwig: +1
21:45:25 <mestery> dougwig: I realize that now :)
21:45:29 <sbalukoff> summit session.
21:45:30 <blogan> so what does split mean?
21:45:30 <mestery> #link https://etherpad.openstack.org/p/neutron-services
21:45:33 <blogan> spin out?
21:45:35 <glebo> ice cream vs adv services split…. um… really?
21:45:57 <sbalukoff> I would like to see blogan's question answered, though will understand if that answer is too complicated for an IRC meeting.
21:45:59 * glebo pretty sure everyone would PREFER to speak ice cream, but, alas...
21:46:10 <mestery> sbalukoff: Agreed, though a good starting point
21:46:20 <ijw> This makes a lot of sense to me, though it's not clear to me if a router is an 'advanced' service
21:46:21 <blogan> sbalukoff: i think that question is dependent on things dougwig brought up
21:46:35 <mestery> ijw: Think things above L2/L3.
21:46:35 <sbalukoff> blogan: Notably not ice cream.
21:46:37 <salv-orlando> I’ll try and make an imaginary bridge with the previous discussion
21:46:41 <blogan> lol yes
21:46:49 <dougwig> #action dougwig update advservices etherpad with ML content
21:46:50 <ijw> mestery: the question was more why a router is special
21:46:55 <salv-orlando> how many people think lbaas is an application consuming core network services?
21:46:58 * mestery has some oceanfront land to sell salv-orlando in Minnesota.
21:47:11 <sbalukoff> salv: I do!
21:47:15 <salv-orlando> and friewall, and vpn for that reason
21:47:22 <blogan> and nova
21:47:24 <sbalukoff> salv: Indeed.
21:47:24 <dougwig> isn't that kind of like asking how many cloud users use a network?
21:47:33 <glebo> blogan: swear I thought you meant "banana" split. Shucks
21:47:34 <markmcclain> mestery: global warming will make that land very valuable
21:47:38 * ijw tries the linux analogy
21:47:41 <sballe> salv-orlando: I agree on LBaaS, FW and VPN
21:47:53 <ijw> If you want a mail server, do you implement it as an app, or do you write it into the kernel?
21:48:00 <mestery> kernel
21:48:02 <mestery> every time
21:48:08 <ijw> If you write an advanced service, is it better as a tenant app or as a core component?
21:48:10 <salv-orlando> another question is whether the typical consumer of the LBaaS API is also a typical consumer of Nuetron “core” APIs
21:48:12 <dougwig> don't joke, i know some high perf appliances that do that.
21:48:17 <ijw> Also, never let mestery write C.
21:48:18 <mestery> dougwig: rofl
21:48:25 <blogan> salv-orlando: i dont believe so
21:48:29 <blogan> more like a typical user of nova
21:48:33 <glebo> salv-orlando: I think its a bit more nuanced than that (disclaimer, I'm not a LBaaS person, but I am a FWaaS person)
21:48:37 <dougwig> blogan: +1
21:49:06 <sgordon_> this is an easy one, you write the mail server into the text editor
21:49:18 <ijw> LB is different to FW and VPN; some things clearly need internal access to routers, some don't.  But the concept is there and it seems worth a summit discussion of what might work
21:49:21 <sbalukoff> sgordon_: Been there done that. It's called emacs.
21:49:28 <salv-orlando> that is the bit I honestly do not know about. I am all in favour about load balancing evolving independently at the control plane
21:49:36 <salv-orlando> leveraging neutron’s data plan
21:49:39 <ijw> sgordon_: /boot/vmemacs
21:49:47 <blogan> yea i think lbaas makes a lot of sense being spun out, fwaas and vpnaas i can see both sides
21:50:04 <salv-orlando> for the API I’m still on the fence whether it should be part of the openstack networking API or a completely distinct API set.
21:50:28 <SumitNaiksatam> mestery: can you define what is your idea of “spin-out” here?
21:50:32 <dougwig> part of the conversation is what happens with all the code that is similar between *aaS ?  where does that live?  do we even try to leverage it?
21:50:33 <ijw> blogan: My take is that this might work.  It might be more trouble than it's worth for some services, though.  But the way to work that out is with a get together and probably a big whiteboard
21:50:45 * glebo thinks "Service" means anything that does some advanced mojo on/with packets up above L2 as they pass by. Especially, they need to fwd packets, but fwd is not their main job, it's just done because the must sit in the path in order to do their job
21:50:46 <blogan> ijw: and ice cream of course
21:50:48 <mestery> SumitNaiksatam: Taking the advanced services code out of neutron and into their own repository
21:50:52 <xgerman> dougwig: Neutron OSLO, NOSLO?
21:51:13 <SumitNaiksatam> mestery: okay, so as a separate project and serice in itself?
21:51:20 <sbalukoff> So... my opinion is that when you start to get to layers 4 and above, you shouldn't be a core service. Most of the "advanced" features we want to add to LBaaS are layers 4 and above. But there is a part that's layer 3-4, too.
21:51:26 <salv-orlando> dougwig: The nichilist way of looking at that is that most of that code should be thrown away in any case
21:51:32 <SumitNaiksatam> *service
21:51:40 <mestery> SumitNaiksatam: That's murky and somewhat depends on where OpenStack governance evolves (see big tent discussion and plan to spend a weekend catching up).
21:51:50 <sbalukoff> So, there's a little overlap there with core services, though that overlap could probably be handled via exposed API (ie. LBaaS is a consumer of core services)
21:51:55 <SumitNaiksatam> mestery: exactly, asking in that context
21:52:08 <dougwig> salv-orlando: granted, but when we rewrite all the port wiring, or the service vm logic, or anything else that's clearly common.
21:52:10 <glebo> +1 to ijw; LBaaS is a bit different than FW and VPN and TrafficShaping and Monitoring/Snarfing, as LBaaS can draw packet to itself via VIP, whereas others must wedge into the forwarding plane somewheres
21:52:23 <mestery> SumitNaiksatam: I would say out of Neutron and into their own repository, how that looks governance wise is clearly up for discussion.
21:52:30 <markmcclain> sbalukoff: right.. I think where we want to provide L3 access we can create interfaces for it
21:52:50 <sbalukoff> markmcclain: +1
21:52:51 <xgerman> +1
21:53:08 <dougwig> markmcclain: +1
21:53:10 <glebo> blogan:  +1 (being GF, I appreciate Ice Cream over Cookie treats)
21:53:11 <ijw> markmcclain: +1 - the key here is the interfaces.  There's no need to remove the code yet, it makes more sense to work out what interfaces are missing as step 1 to enable removing the code in the future
21:53:48 <markmcclain> ijw: agreed, but I think that having a real plan is needed
21:53:50 <SumitNaiksatam> so do people feel that the current “port” interface in neutron is not enough driver services’ integration?
21:54:03 <dougwig> i'm not sure the interfaces will be correctly identified until the pain of attempting removal.
21:54:11 <ijw> SumitNaiksatam: looks ok to me - did you think something was missing?
21:54:11 <mestery> dougwig: +1
21:54:16 <sbalukoff> dougwig: +1
21:54:25 <SumitNaiksatam> there is certainly a need for higher level abstractions, but if one were to use neutron as is and keep it “pure”
21:54:35 <ijw> SumitNaiksatam: some sort of notification interface is starting to look in order, mind
21:54:44 * dougwig waits for a lightning bolt, hearing neutron and pure in the same sentence.
21:54:53 <markmcclain> dougwig: right.. that several other spin out attempts in other projects have stalled on the designing interface stage for that reason
21:54:55 <SumitNaiksatam> ijw: we already have notifications for resources being created
21:54:57 * ijw rains fire on dougwig from the heavens
21:55:07 <armax> I think the discussion for svc spin-out needs to happen at multiple level: external API’s, internal API’s as well as implementation’s
21:55:18 <ijw> SumitNaiksatam: to apps outside Neutron, not on Rabbit
21:55:32 <markmcclain> armax: ++
21:55:39 <mestery> armax: +1
21:55:39 <glebo> ijw:  +1, interfaces > removal, in fact, interfaces enables removal, in fact, can't remove until interfaces are clear and effective, otherwise we kill existing features/capability. Bad for operators
21:55:42 <ijw> There is clearly insufficient beer present to come to a conclusion today
21:55:50 <dougwig> maybe we even just spend 5 minutes brainstorming the interfaces that we think aren't right yet.
21:55:55 <mestery> ijw: Nor time, though beer is more important.
21:56:01 <mestery> dougwig: Thanks for pulling us back in.
21:56:19 <ijw> dougwig: VLANs ;) (half kidding, but Bob M was right on that)
21:56:20 <sbalukoff> Haha
21:56:23 * HenryG is still not sure how database tables will be managed for spin-outs
21:56:25 <dougwig> i meant at the summit, but here works oto
21:56:26 <dougwig> lol
21:56:31 <salv-orlando> anyway, I just think we cannot split out. There’s no feasible way of doing that. We need to grow the new independent advanced service alongside the builtin ones.
21:56:46 <dougwig> salv-orlando: why is it not feasible?
21:56:48 <blogan> i do agree with dougwig though that identitying the interfaces that need fixed/added will happen mostly during the pain of spinning out
21:57:05 <salv-orlando> I think it’s just too difficult. It will be easier to build a new service.
21:57:10 <ijw> salv-orlando: that's really another perspective over growing the interfaces and then the services, I think - the old services can't go till new ones replace them
21:57:28 <dougwig> yeah, they'd just be diverging forks until deletion.
21:57:40 <ijw> nova-network, The Revenge (tm)
21:57:40 <blogan> which is why i brought up the octavia api possibly replacing neutron lbaas as an lbaas api
21:57:41 <salv-orlando> dougwig: not for any conceptual reason. I’m just thinking from a practical and pragmatic perspective
21:57:42 <dougwig> which isn't a huge issue, unless it spans cycles.
21:58:02 <xgerman> what doesn't span cycles?
21:58:06 <sbalukoff> Part of that is having buy in from the important parties on that: When the new service is ready, we need to actively kill the old service. :/
21:58:20 <salv-orlando> blogan: I might try and say that where you guys were always headed in the first place with octavia!
21:58:33 <SumitNaiksatam> salv-orlando: are you thinking in terms of a v2 implementation of services in stackforge which the v1 still remains and is maintained in neutron?
21:58:39 <dougwig> xgerman: it'd suck for users if when K releases, there is a spun out lbaas and an internal lbaas.  which to use when? why?  etc.
21:58:42 <ijw> sbalukoff: or proxy the calls over, which is a bit weird
21:58:46 <SumitNaiksatam> which -> with
21:58:47 <blogan> salv-orland: it was definitely something i always kept in the back of my mind
21:58:59 <sbalukoff> ijw: Assuming API is compatible enough.
21:58:59 <glebo> blogan:  dougwig: +1, identify IFs needing attention to make a spin out successful
21:59:00 <salv-orlando> SumitNaiksatam: I’m not yet thinking of anything. Just looking at somethign that we can practically iterate on
21:59:16 * mestery notes the cycles are always shorter than they appear.
21:59:20 <ijw> markmcclain had the right idea, I think.
21:59:22 <mestery> Kilo-1 will be here faster than many people are aware.
21:59:24 <sbalukoff> mestery: +1
21:59:26 <SumitNaiksatam> salv-orlando: okay, thinking -> looking
21:59:29 <ivar-lazzaro> dougwig: isn't it the same with nova network?
21:59:41 <mestery> OK, 1 minute left folks.
21:59:44 <mestery> I'm going to wrap this up.
21:59:48 <dougwig> the parallels haunt me, yes.
21:59:48 <ijw> Interfaces first, then let people bugger about on the service front, it doesn't have to be committed to find out if it'll work, and it doesn't even have to be in stackforge
21:59:49 <mestery> I expect a lively discussion in Paris on this!
21:59:54 <salv-orlando> mestery: I think you can wrap it up.
21:59:54 <mestery> Have fun and enjoy Paris!
21:59:57 <mestery> #endmeeting