22:00:57 <SumitNaiksatam> #startmeeting Networking Advance Services
22:00:58 <openstack> Meeting started Mon Oct 14 22:00:57 2013 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:01 <openstack> The meeting name has been set to 'networking_advance_services'
22:01:10 <SumitNaiksatam> first up, apologies to those for whom this time is inconvenient
22:01:23 <SumitNaiksatam> we will try to do it at a different time for follow up
22:01:41 <SumitNaiksatam> just thought it was easier to herd everyone together while we are here anyway
22:01:50 <SumitNaiksatam> #topic service insertion and chaining
22:02:07 <SumitNaiksatam> this is a follow up from the last VPNaaS meeting
22:02:28 <SumitNaiksatam> since this topic cuts across *aaS we thought it better to have this common discussion
22:02:36 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
22:02:50 <SumitNaiksatam> there has been some discussion on the above blueprint
22:03:22 <SumitNaiksatam> the most updated version was posted only recently so not everyone might have had a chance to take a look
22:03:37 <SumitNaiksatam> for those who did, any thoughts?
22:04:00 <gregr_3456> good progress
22:04:00 <SumitNaiksatam> there were some comments from enikanorov which have been addressed
22:04:16 <SumitNaiksatam> gregr_3456: thanks
22:04:25 <SumitNaiksatam> nati_ueno: thoughts?
22:05:01 <nati_ueno> SumitNaiksatam: +1
22:05:21 <SumitNaiksatam> the idea is be able to be able to support both single service insertion and also chains
22:05:22 <nati_ueno> SumitNaiksatam: I'll comment in the doc also
22:05:28 <SumitNaiksatam> nati_ueno: thanks
22:06:01 <SumitNaiksatam> crickets? :-)
22:06:18 <Snigs> hi guys Beginner here :) Where is the blueprinbt for the data path
22:06:21 <enikanorov> SumitNaiksatam: going over your comments. am I understanding correctly, that there could be service that is not inserted?
22:06:34 <SridarK> It was  a very productive face 2 face discussion on Thu - it is really important that we are able to get to a common model that we can implement in Icehouse. This is imperative for us to make any meaningful progress with services.
22:06:48 <SumitNaiksatam> SridarK: thanks
22:06:58 <SumitNaiksatam> Snigs: data plane model is not prescriptive
22:07:09 <SumitNaiksatam> Snigs: it is driven by the plugin/driver
22:07:21 <SumitNaiksatam> Snigs: this model is to capture the intent of the user
22:07:37 <SumitNaiksatam> enikanorov: thinking about your question
22:07:46 <Snigs> ok - so the plugin defines the data path and the encapsulation
22:07:52 <SumitNaiksatam> Snigs: yes
22:08:07 <SumitNaiksatam> enikanorov: i think every service is inserted
22:08:10 <Snigs> and this blueprint is focussed on specifying the parmeters for the chain ?
22:08:17 <SumitNaiksatam> enikanorov: it may or may not be explicit
22:08:29 <SridarK> for the data path we can consider something along the lines of NSH but we are a bit far from that at this point
22:08:33 <SumitNaiksatam> Snigs: at a high level you can look at it that way
22:08:40 <enikanorov> SumitNaiksatam: i remember that is controlled by service instertion context
22:08:49 <geoffarnold> Well, explicit or not represents a pretty fundamental difference for the end user
22:08:53 <enikanorov> which is a separate object
22:09:05 <SumitNaiksatam> geoffarnold: agree
22:09:07 <enikanorov> just thinking what level of control the user will have
22:09:13 <iwamoto> will this BP change current LBaaS or FWaaS implementation much? I wonder how chaining will be implemented
22:09:13 <SumitNaiksatam> geoffarnold: i meant to say there could be defaults
22:09:22 <geoffarnold> Let me post a multiline question....
22:09:32 <geoffarnold> Who’s doing the insertion and chaining?  It seems to me that there are two distinct (but overlapping) use cases in this area.  One is where service instances are visible to applications: where we are adding API(s) to allow an application to explicitly manage the service instance.  The other is where the service instance is invisible to the application: the application uses the Neutron APIs to interact with the logical
22:09:42 <SumitNaiksatam> enikanorov: yes, service insertion context object
22:10:18 <geoffarnold> .... elects to use service instances (rather than, say, physical resources) to realize these logical resources.  Many similarities, but also great differences.
22:10:28 <SumitNaiksatam> iwamoto: implementation may change, the degree to which it may change may be varied, the attempt is to be minimally disruptive
22:10:40 <SumitNaiksatam> geoffarnold: still reading :-)
22:11:27 <SumitNaiksatam> geoffarnold: if i could grasp that, we are addressing the former case
22:11:45 <SumitNaiksatam> geoffarnold: all neutron abstractions are currently targeting the former case
22:11:46 <geoffarnold> That's what I thought.
22:11:52 <SumitNaiksatam> geoffarnold: ok
22:11:53 <geoffarnold> But we need the second case too
22:11:58 <SumitNaiksatam> geoffarnold: sure
22:12:13 <SumitNaiksatam> these seem to be complementary
22:12:20 <SumitNaiksatam> geoffarnold: right?
22:12:30 <geoffarnold> It would be a shame to do two parallel service instance implementations and then have to refactor to belatedly catch up with the overlap
22:12:47 <SumitNaiksatam> geoffarnold: hmmm…should not be the case
22:13:07 <Kanzhe> geoffarnold: Both of your use cases are covered by the proposal.
22:13:15 <geoffarnold> We've built an example of the second model in DNRM which we'll demo in Hong Kong
22:13:26 <samuelbercovici> as i did not read the doc, yet, is the proposal is for the logical model only? what is the expectation in regards to the data plane?
22:13:32 <Kanzhe> Invisible case is the same as "Bump In The Wire" mode, where appplication is not aware of the service.
22:13:37 <geoffarnold> But Mark McClain and others are urging us to look at both
22:14:07 <SumitNaiksatam> geoffarnold: on re reading your question, i agree with Kanzhe, we are addressing the logical resource case
22:14:44 <geoffarnold> Second [DNRM] case involves no new APIs. If you have a new API, it's a new use case IMHO
22:14:55 <samuelbercovici> geoffarnold: in general neutron ia handling logical models
22:14:56 <SumitNaiksatam> samuelbercovici: data plane implementation details are in the plugin/driver
22:15:03 <Kanzhe> Inserting LB will be the second use case, where application is aware of the service insertion.
22:15:14 <SumitNaiksatam> samuelbercovici: anything specific that you would like to be incorporated here
22:15:32 <SumitNaiksatam> geoffarnold: to give you an example - lets take FWaaS and firewall
22:15:40 <SumitNaiksatam> user creates a firewall resource
22:15:43 <SumitNaiksatam> this is a logical resource
22:15:44 <geoffarnold> Agreed. But does the end user know anything about the logical resource beyond what is in the current FW/LB/L3 APIs?
22:15:53 <SumitNaiksatam> geoffarnold: no
22:16:14 <geoffarnold> So the resource could be HW or SW
22:16:22 <SumitNaiksatam> yes
22:16:41 <samuelbercovici> SumitNaiksatam: so idealy, the insertion "logical" model is specified by an admin, then the different drivers should get enough "TBD" information so they can adhere to this?
22:16:46 <SumitNaiksatam> per the blueprint the service instance is a logical resource as the user sees it
22:17:14 <SumitNaiksatam> samuelbercovici: yes
22:17:33 <SumitNaiksatam> samuelbercovici: ideally it would be great to be able to flesh that interface out
22:17:43 <SumitNaiksatam> at least from an insertion perspective
22:18:01 <samuelbercovici> SumitNaiksatam: so lets take some use cases..
22:18:08 <SumitNaiksatam> samuelbercovici: yes
22:18:27 <Snigs> is it possible to decompose the insertion problem into a classification, redirect and return (next hop)
22:18:40 <SumitNaiksatam> btw, folks,  we also have a couple of other items on the agenda for today
22:18:49 <SumitNaiksatam> so we need to give time for those as well
22:18:52 <SumitNaiksatam> but go ahead
22:18:59 <samuelbercovici> if i create a new VIP, currently i select the driver implementation, how would i specify the insertion model and the service model?
22:19:22 <SumitNaiksatam> Snigs: that i consider it to be a implementation detail, however your point on the classification is very valid
22:19:39 <SumitNaiksatam> Snigs: currently there is no defined classification mechanism in neutron
22:19:59 <Snigs> ok - let me listen a little more :)
22:20:02 <SumitNaiksatam> Snigs: i consider it to be complementary but not within the scope of this bp
22:20:03 <samuelbercovici> two portions at least are relevant here; a: how to expect the VIP handling (exmples: proxy, default gate way..)
22:20:05 <enikanorov> samuelbercovici: I think it still up to the plugin driver to decide the insetion mode. But user can give a hint in case plugin drivers supports several types of insertion
22:20:17 <enikanorov> but that's IMO
22:20:25 <samuelbercovici> then also if default gateway, than the expectation is to be inserted insted of the gw
22:20:31 <SumitNaiksatam> enikanorov: yes
22:20:45 <SumitNaiksatam> samuelbercovici: does that make sense?
22:20:57 <samuelbercovici> and b: the chaining order
22:21:41 <SumitNaiksatam> samuelbercovici: you mean replace L3 gateway with LB?
22:21:49 <SumitNaiksatam> LB -> VIP
22:22:35 <Kanzhe> samuelbercovici: Do you mean the LB provides both L3 gateway function and LB function?
22:23:01 <samuelbercovici> SumitNaiksatam: yes. if the vip "specifies" that it is going to function in a model that needs the lb service to perform as default GW for the memebers, that it should replace the L3 gw
22:23:09 <samuelbercovici> at least fro those members
22:23:16 <SumitNaiksatam> samuelbercovici: agree
22:23:29 <samuelbercovici> achiving this by the driver alone is currently no possible
22:23:46 <rudrarugge> i agree with samuel on this
22:23:55 <ivar-lazzaro> +1
22:23:56 <SumitNaiksatam> samuelbercovici: yes, so in the proposed model we have service_insertion_context
22:24:31 <SumitNaiksatam> for exactly that reason
22:25:05 <SumitNaiksatam> driver and insertion context are two different things
22:25:06 <samuelbercovici> so what would a  service_insertion_context define?
22:25:06 <SumitNaiksatam> one could write a driver that can infer the insertion context (as it does today) but that is not fexible
22:25:06 <rudrarugge> and how does context play out in a service vm
22:25:06 <SumitNaiksatam> samuelbercovici: its in the spec :-)
22:25:18 <SumitNaiksatam> i will copy paste here -
22:25:46 <SumitNaiksatam> it mainly has a insertion_type/mode
22:26:00 <SumitNaiksatam> which will indicate L3 or L2 or BITW or Tap
22:26:19 <SumitNaiksatam> and then additional attributes pertaining to whichever type/mode is chosen
22:26:44 <SumitNaiksatam> so for e.g., if L3 is chosen, then a router_id would be a part of the insertion_context
22:26:53 <rudrarugge> got it sumit but how do we associate the interfaces from service vm to the service instances?
22:27:29 <SumitNaiksatam> rudrarugge: nice segue to the next topic
22:27:35 <enikanorov> rudrarugge: that is a too forwardlooking question IMO :)
22:27:50 <rudrarugge> sure will wait
22:28:00 <bobmel> The spec uses plural; e.g. routers. What does that mean?
22:28:12 <SumitNaiksatam> geoffarnold, samuelbercovici, Snigs: do you want to follow up later on this particular topic
22:28:15 <SumitNaiksatam> ?
22:28:21 <samuelbercovici> SumitNaiksatam: so if the lbbas is a two leg solution that can bypass the l3 gw, how can it get inserted?
22:28:29 <SumitNaiksatam> can we transition to the next topic
22:28:31 <geoffarnold> Yes
22:28:49 <SumitNaiksatam> geoffarnold: thanks
22:28:52 <samuelbercovici> ok. will read the document and comment ask questions on it
22:29:03 <SumitNaiksatam> samuelbercovici: good question, hold that thought we can take that offline
22:29:11 <SumitNaiksatam> i think we can handle that insertion
22:29:30 <Snigs> Yes
22:29:58 <SumitNaiksatam> i had the second topic listed as "common agent model" for the services, but i will skip that
22:30:12 <SumitNaiksatam> since the question was asked about service VMs lets get to that
22:30:26 <SumitNaiksatam> #topic service VM library
22:30:55 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms
22:31:01 <SumitNaiksatam> note that there are other blueprints as well in the same zip code
22:31:02 <SumitNaiksatam> most notably geoffarnold's blueprint
22:31:29 <SumitNaiksatam> this particular topic for today's discussion is specifically on the service VM management framework/library
22:31:47 <SumitNaiksatam> rudrarugge: i believe your question is in this context
22:31:51 <SumitNaiksatam> lets address that
22:31:54 <rudrarugge> yes
22:31:56 <rudrarugge> thanks
22:32:11 <SumitNaiksatam> gregr_3456: there?
22:32:15 <gregr_3456> hi
22:32:26 <gregr_3456> first can talk about service VM interfaces
22:32:27 <SumitNaiksatam> you want to take rudrarugge's question
22:32:32 <SumitNaiksatam> ok
22:32:48 <SumitNaiksatam> so we have potentially two types of service interfaces
22:32:55 <gregr_3456> the though is that there are two types on interfaces
22:32:59 <SumitNaiksatam> management and data plane for any service VM
22:33:05 <gregr_3456> first type is 'management interfaces'
22:33:12 <SumitNaiksatam> gregr_3456: yes go ahead
22:33:17 <gregr_3456> second is data plane interfaces
22:33:23 <gregr_3456> (sorry, typed over you)
22:33:31 <geoffarnold> yup
22:33:44 <SumitNaiksatam> gregr_3456: np, please keep going
22:34:00 <gregr_3456> the idea is to allow the consumer of the service VM framework to allocate one or more of each type
22:34:16 <gregr_3456> based on the requirements of that particular implementation
22:34:28 <gregr_3456> so far ok?
22:34:32 <rudrarugge> yes
22:34:51 <geoffarnold> consumer as in provider of the virtual appliance, or consumer of the VM services
22:35:21 <gregr_3456> consumer is consumer of this interface, the service implementation or plugin
22:35:53 <Kanzhe> gregr_3456: What is the reason for the serviceVM library to differentiate management vs. data-place interfaces?
22:36:32 <Kanzhe> IMHO, the two are the same for the library as long as the network reference is provided.
22:36:34 <ChristianM_> Could it be in-band or out-of-band management based on the service implementation ?
22:36:43 <rudrarugge> how do we handle accessing the UI of the service through lets say a management plane for service instance
22:36:47 <gregr_3456> it may be that mgmt interface may need to be isolated from data plane for availability purposes
22:37:19 <Guest25338> the plugin should be able to access the mgmt interfaces
22:37:23 <rudrarugge> mgmt plane of service instance is different than mgmt plane of service vm?
22:37:29 <SumitNaiksatam> ChristianM_: yes both are possible
22:37:30 <yamahata> can management interface be non-nic interface? for example serial.
22:37:42 <SumitNaiksatam> yamahata: good point
22:38:00 <SumitNaiksatam> gregr_3456: i think we should capture yamahata's point
22:38:05 <Kanzhe> access to mgmt interface is done through its IP address, interface is not relevant here.
22:38:21 <geoffarnold> Which of its IP addresses? It may have multiple
22:38:29 <samuelbercovici> i am a bit lost here. what is added here on top of plain vanila spinning up VMs?
22:38:33 <gregr_3456> to Yamahatas point, the management interface may not necessarily be a network interface
22:39:08 <geoffarnold> The management interface has to be accessible to a plugin/driver
22:39:09 <SumitNaiksatam> on sec guys, i think we have people typing over
22:39:12 <Kanzhe> If the mgmt interface is not on a network, neutron shouldn't care.
22:39:12 <yamahata> gregr_3456, right.
22:39:39 <geoffarnold> Disagree
22:40:02 <SumitNaiksatam> one sec
22:40:08 <SumitNaiksatam> let me respond to samuelbercovici first
22:40:10 <amotoki> Kanzhe: but from the VM management view the mgmt interface needs to be modeled.
22:40:20 <SumitNaiksatam> that's a bigger question
22:40:33 <geoffarnold> Either Neutron is responsible for the mgmt network, or it affects availability (HA) of the {plugin+VM} subsystem
22:41:13 <SumitNaiksatam> samuelbercovici: this framework/library tries to achieve spinning up the VM, thats correct, but in a way that it can be reused across services and components
22:41:47 <gregr_3456> right.
22:41:50 <geoffarnold> hich will work for some components and not others
22:41:56 <SumitNaiksatam> yamahata, amotoki: agree the serial interface may not be for a neutron network
22:42:05 <geoffarnold> heck, we can't even prescribe the guest OS
22:42:21 <SumitNaiksatam> but the probably the framework still needs to manage it
22:42:35 <SumitNaiksatam> geoffarnold, gregr_3456: over to you :-)
22:42:52 <SumitNaiksatam> lets have one conversation
22:43:06 <geoffarnold> So I've taken a pessimistic approach
22:43:16 <Kanzhe> SumitNaiksatam: ok, I agree. serviceVM library should still capture the serial interface config.
22:43:24 <SumitNaiksatam> Kanzhe: thanks
22:43:33 <SumitNaiksatam> geoffarnold, gregr_3456 : carry on
22:43:50 <geoffarnold> needs to work with as many kinds of virtual/physical appliances, new and existing, as possible
22:43:50 <gregr_3456> should be able to specify a management interface from library pov,  whether network or serial or whatever...
22:43:51 <samuelbercovici> ic. i am asking as we implement lbaas for radware using "service vms" that are not visible for the tenant. we consumed standard openstack capabilities for this. i would not assume that the way we did it is generic but works for our solution.
22:44:18 <SumitNaiksatam> samuelbercovici: i am sure it does
22:44:31 <geoffarnold> Samuel: we should sit down and compare what we did for Vyatta in DNRM with the Radware LBaaS
22:45:00 <SumitNaiksatam> samuelbercovici, geoffarnold : yes, we can see what the commonalities are and bring them in
22:45:02 <Guest47907> In our case we have to create a router to access the VM
22:45:03 <geoffarnold> And ideally add a third virtual appliance to break ties ;-)
22:45:06 <rudrarugge> we also have a service vm implemented as firewall
22:45:17 <SumitNaiksatam> rudrarugge: welcome to the party :-)
22:45:18 <samuelbercovici> there were many small nits that we needed to have. many of those were around supporting our ha model
22:45:24 <rudrarugge> :)
22:45:40 <SumitNaiksatam> samuelbercovici: aha, thats the point
22:45:48 <geoffarnold> I looked at the device inventory BP for LB, and it generalizes nicely to what we did in DNRM
22:45:59 <SumitNaiksatam> geoffarnold: great
22:46:07 <gregr_3456> would be helpful to gather these 'nits' and try and capture as many as possible for a common framework
22:46:35 <SumitNaiksatam> gregr_3456: +1 that is why we are proposing a "common" framework
22:46:40 <geoffarnold> My feeling about frameworks is that we need a minimal mandatory piece (so we can all get along) together with "best practices"
22:46:49 <Kanzhe> Most like geoffarnold's DNRM is the first consumer of the serviceVM framework.
22:47:04 <geoffarnold> Well, Radware too.
22:47:04 <amotoki> geoffarnold: what is DNRM?   may be a silly question.
22:47:07 <rudrarugge> some nits for us: using dhcp assigned addresses for L3 mode to be used by service instances
22:47:10 <SumitNaiksatam> geoffarnold: agree, so thats a good thing, right?
22:47:16 <geoffarnold> Yes
22:47:33 <gregr_3456> yes +1
22:47:43 <SumitNaiksatam> so here is a general statement - there will be common requirements and there will be specifics
22:47:44 <geoffarnold> What's DNRM? This:  https://blueprints.launchpad.net/neutron/+spec/dynamic-network-resource-mgmt
22:47:53 <samuelbercovici> so mybe, it would be best served, to list all current impelemntation for service vms and get some nits to establish "best practices" before we try to drive a comonality
22:48:08 <geoffarnold> I'm working to carve it up into multiple blueprints, but this captures the end-to-end use cases
22:48:12 <amotoki> geoffarnold: thanks
22:48:14 <SumitNaiksatam> we need to at least capture the common requirements
22:48:42 <gregr_3456> do we have time for use cases?
22:48:49 <SumitNaiksatam> samuelbercovici: being common is not being prescriptive
22:49:07 <SumitNaiksatam> gregr_3456: yes please, in case you want to bring up any
22:49:09 <Kanzhe> Most like the common framework will satisfy a targeted use case at the beginning, then expend to support more.
22:49:10 <geoffarnold> I've restricted myself to service VMs that are completely invisible to the user; they're all owned by the "DNRM" project ;-)
22:49:41 <gregr_3456> ok, on to use cases
22:49:49 <samuelbercovici> geoffarnold: sure. worst case, we can do it in HK :-)
22:50:09 <geoffarnold> What's on the agenda for the Thursday meeting at BigSwitch?
22:50:10 <gregr_3456> likely most common case is private service owned by a tenant
22:50:41 <gregr_3456> but other use cases include shared service VMs that are owned by admin/operator
22:51:06 <gregr_3456> and for scale-out, a logical service may be hosted across multiple service VMs
22:51:19 <gregr_3456> any disagreement with this?
22:51:27 <SumitNaiksatam> gregr_3456: agree, i think those capture most of the cases
22:51:36 <rudrarugge> I am guessing shared service VMs is not a common use case
22:51:36 <samuelbercovici> we r similar to geoffarnold in that we have service VMs invisible to tenants
22:51:44 <geoffarnold> What's the mapping between "service" and "logical resource instance"
22:51:53 <geoffarnold> (The latter in the Neutron API sense)
22:51:58 <gregr_3456> terminology has been a problem
22:52:12 <SumitNaiksatam> geoffarnold: we will try to make progress on the same discussion (but we will have a chance to pull each other's hair out in person :-))
22:52:19 <bobmel> In an implementation at Cisco the service VMs are also invisible to tenants
22:52:20 <geoffarnold> Excellent
22:52:40 <gregr_3456> i have been using logical service to describe the one specified by Neutron API
22:52:44 <rudrarugge> Private service owned by a tenant but provided by the operator?
22:52:45 <Snigs> Sumit: Do we have any hair left ?
22:52:56 <geoffarnold> I have plenty (beard too)
22:53:01 <SumitNaiksatam> Snigs: :-)
22:53:22 <SumitNaiksatam> samuelbercovici: the service VM is almost always invisible to the tenant
22:53:27 <geoffarnold> I'm concerned about the interaction with placement and HA issues
22:53:37 <gregr_3456> i am an IRC newbie,  need to learn to respond to individual. :)
22:53:57 <Snigs> +1 geoff
22:53:58 <geoffarnold> And logical to physical mappings for things like multi tenant big iron LBs and routers
22:54:08 <samuelbercovici> the ha is probably the biggie here
22:54:20 <SumitNaiksatam> samuelbercovici, bobmel: there is no suggestion in this proposal to make it explicitly visible to the tenant
22:54:42 <samuelbercovici> SumitNaiksatam: k
22:54:47 <geoffarnold> Well, the BP isn't exactly clean on that
22:54:55 <SumitNaiksatam> rudrarugge: service owned by provider
22:54:58 <geoffarnold> Implies Heat might know more about mappings
22:55:03 <SumitNaiksatam> geoffarnold: ok
22:55:23 <Kanzhe> SumitNaiksatam: +1. The framework is for other module to consume, not meant for tenant.
22:55:30 <SumitNaiksatam> geoffarnold: heat will never interact with the library/framework proposed here
22:55:40 <geoffarnold> In DNRM we lump tall that complexity into a couple of policy engine black boxes, contents TBD
22:55:53 <gregr_3456> yes,  service owned by provider and pinned to tenant is another variant
22:56:02 <gregr_3456> planning to update spec after this meeting
22:56:09 <SumitNaiksatam> geoffarnold: great - policy is separate from mechnism
22:56:18 <SumitNaiksatam> geoffarnold: this blueprint is only for mechanism
22:56:27 <SumitNaiksatam> gregr_3456: thanks
22:56:40 <geoffarnold> When we're considering use cases, let's include software delivery use case - new virtual appliance installation in a running cloud
22:56:43 <gregr_3456> thanks for feedback
22:56:44 <SumitNaiksatam> nice discussion everyone - enough to keep gregr_3456 busy i think :-)
22:56:57 <geoffarnold> Thanks all
22:56:59 <SumitNaiksatam> geoffarnold: good topic for F2F meeting
22:57:00 <Snigs> thanks
22:57:03 <SumitNaiksatam> ok one more topic
22:57:05 <samuelbercovici> thany u all.
22:57:07 <SumitNaiksatam> not done :-)
22:57:09 <geoffarnold> ?
22:57:14 <samuelbercovici> good night
22:57:16 <garyduan> VM creation is triger by some neutron cli, right?
22:57:24 <geoffarnold> NO NO NO!!!!
22:57:31 <gregr_3456> still here...
22:57:33 <Kanzhe> garyduan: No
22:57:34 <SumitNaiksatam> :-)
22:57:41 <SumitNaiksatam> nati_ueno: there?
22:57:47 <garyduan> Sorry, I'm late to jump in
22:57:51 <geoffarnold> Really ned to decouple that - see my BP
22:57:57 <SumitNaiksatam> we wanted to discuss common agent model
22:58:02 <nati_ueno> SumitNaiksatam: yep
22:58:10 <garyduan> well, I mean in the use case
22:58:13 <SumitNaiksatam> #topic common L3 agent framework
22:58:16 <geoffarnold> plugin, driver, now agent. Hmmmm
22:58:16 <SumitNaiksatam> SridarK: there?
22:58:23 <SridarK> yes here
22:58:25 <SumitNaiksatam> good
22:58:30 <SumitNaiksatam> i don't think we have enough time
22:58:32 <garyduan> certainly implentation wise, it's some internal APIs
22:58:36 <SumitNaiksatam> but just want to put it out there
22:58:37 <garyduan> that's my understanding
22:59:02 <SumitNaiksatam> we currently have a situation where we have three different flavors of the L3 agent in the reference implementation
22:59:14 <SumitNaiksatam> L3, FWaaS, VPNaaS
22:59:17 <geoffarnold> However since my first DNRM implementation spins up discrete L3 routers....
22:59:38 <geoffarnold> Didn't Cisco have a refactoring proposal for that?
22:59:42 <SumitNaiksatam> as suggested by nati_ueno (and also SridarK) earlier, we need to have a better approach towards these
22:59:57 <geoffarnold> Is mastery there?
22:59:59 <SumitNaiksatam> nati_ueno, SridarK: thoughts?
23:00:07 <geoffarnold> mestery
23:00:10 <nati_ueno> yes. we should have generic service-agent
23:00:26 <SumitNaiksatam> geoffarnold: bobmel was driving that i believe
23:00:35 <SumitNaiksatam> the refactoring is complete
23:00:37 <geoffarnold> That's right - I forgot
23:00:38 <SridarK> yes and plugin service or vendor specific agents
23:00:40 <SumitNaiksatam> but that is for the plugin
23:00:50 <SumitNaiksatam> nati_ueno, SridarK: go ahead
23:00:51 <geoffarnold> We need a whiteboard
23:01:01 <nati_ueno> https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZXq7SnSSGo/edit#slide=id.p
23:01:10 <nati_ueno> This was the slide I send to the mailing list
23:01:24 <SumitNaiksatam> nati_ueno: thanks
23:01:38 <SumitNaiksatam> geoffarnold: we can potentially have this discussion as well in F2F
23:01:44 <nati_ueno> In that mailling thread, option2-2 was the conclution
23:01:47 <SumitNaiksatam> but this is the best we have in terms of opening it to the community
23:01:55 <SumitNaiksatam> nati_ueno: thanks
23:02:05 <nati_ueno> so we have a service-agent, and it will provide some hooks (event driven model)
23:02:18 <geoffarnold> OK, I have to drop off. Thanks guys. See (some of) you Thursday
23:02:23 <nati_ueno> then each service agent driver will hook that
23:02:34 <SumitNaiksatam> nati_ueno: +1
23:02:45 <SumitNaiksatam> geoffarnold: thanks
23:02:59 <nati_ueno> Any thought?
23:03:15 <nati_ueno> so in Icehouse, I wanna leave current l3-agent as-is for backward compatibility
23:03:17 <SumitNaiksatam> nati_ueno: i guess we don't need to have conclusion now, we are past the meeting time
23:03:23 <nati_ueno> sure
23:03:33 <SridarK> nati_ueno in agreement - lets talk more
23:03:35 <SumitNaiksatam> but i think it will be good for everyone to know this so that we can keep discussing
23:03:37 <SumitNaiksatam> i am +1
23:03:43 <SumitNaiksatam> SridarK: agree
23:03:56 <SumitNaiksatam> #topic Open discussion
23:04:02 <SumitNaiksatam> we can have a follow up meeting
23:04:16 <SumitNaiksatam> may be at a convenient time for other folks
23:04:25 <SumitNaiksatam> which topics did we leave out?
23:05:03 <SumitNaiksatam> or what would you like to be discussed in the context of "advance services" and common requirements?
23:05:33 <SumitNaiksatam> we use the mailing list as well
23:05:38 <SumitNaiksatam> any parting thoughts?
23:06:00 <Kanzhe> nice discussion.
23:06:03 <nati_ueno> SumitNaiksatam: How about to have a etherpad page?
23:06:05 <ivar-lazzaro> Since we are discussing about different type of insertions, implementations, I think that would be good to discuss about "retrieving" physical network mapping
23:06:12 <nati_ueno> SumitNaiksatam: it will help the summit discussion also
23:06:17 <ivar-lazzaro> which is not doable easy as is
23:06:32 <SumitNaiksatam> nati_ueno: sure, i will add one, and link this meeting
23:06:38 <nati_ueno> SumitNaiksatam: Thanks!
23:06:42 <SumitNaiksatam> ivar-lazzaro: good point
23:06:50 <nati_ueno> Also we should have weelky meeting
23:06:50 <SumitNaiksatam> lets do that for a follow up
23:07:01 <nati_ueno> because this one need many time to discuss
23:07:10 <nati_ueno> sometimes it looks like a forever discussion :P
23:07:11 <SumitNaiksatam> +1, we can set this up as a weekly meeting, may be at a different time
23:07:24 <nati_ueno> awesome
23:07:25 <ChristianM__> +1 weekly until summit
23:07:25 <SumitNaiksatam> nati_ueno: agree
23:07:27 <Kanzhe> +1
23:07:33 <garyduan> +1
23:07:36 <SridarK> Agree
23:07:40 <SumitNaiksatam> ok i can set one up, will check for a convenient time
23:07:49 <ivar-lazzaro> Good
23:07:53 <SumitNaiksatam> i know enikanorov is half asleep :-)
23:08:02 <SumitNaiksatam> or may be more than half
23:08:13 <SumitNaiksatam> alrighty, thanks everyone for your time
23:08:18 <Swami> good
23:08:21 <SumitNaiksatam> looking forward to the next one
23:08:36 <SumitNaiksatam> #endmeeting