17:32:00 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:32:01 <openstack> Meeting started Wed Mar 26 17:32:00 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:32:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:32:04 <openstack> The meeting name has been set to 'networking_advanced_services'
17:32:04 <Swami> hi
17:32:16 <SumitNaiksatam> Swami: hi
17:32:18 <s3wong> Hello
17:32:22 <SumitNaiksatam> #info Meeting agenda: #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices
17:32:36 <SumitNaiksatam> s3wong: yes, right meeting :-)
17:32:53 <s3wong> SumitNaiksatam: good to know
17:32:57 <SumitNaiksatam> #topic Flavors Update
17:33:08 <SumitNaiksatam> #link https://wiki.openstack.org/wiki/Neutron/FlavorFramework
17:33:20 <enikanorov_> on flavors, PoC code that would illustrate the idea is almost ready
17:33:20 <SumitNaiksatam> enikanorov_: anything changed between last week and now?
17:33:26 <enikanorov_> i plan to publish it today
17:33:29 <SumitNaiksatam> enikanorov_: thats is awesome
17:33:35 <banix> Still cold around here :)
17:33:47 <SumitNaiksatam> enikanorov_: sweet, was going to ask you if there is private branch
17:33:51 <SumitNaiksatam> banix: :-)
17:33:55 <enikanorov_> so probably once it done we could hve some discussion in gerrit also
17:33:56 <s3wong> enikanorov_: do you have the review link (or soon)?
17:34:14 <enikanorov_> s3wong: i'll send a notice, not yet
17:34:21 <s3wong> enikanorov_: thanks!
17:34:58 <SumitNaiksatam> enikanorov_: we can wait for the patch, but in terns of design, anything changed?
17:35:13 <enikanorov_> no, i don't think so
17:35:25 <SumitNaiksatam> enikanorov_: our understanding was that beyond certain minimal attributes this was most going to be key:value pairs
17:35:33 <Swami> flavor_type says "public' or 'internal". what does public or internal mean.
17:35:41 <s3wong> enikanorov_: still just a additional tag then, right?
17:36:04 <enikanorov_> Swami: probably i need to update the wiki, 'internal' seems to be unnecessary
17:36:21 <enikanorov_> SumitNaiksatam: yes
17:36:47 <SumitNaiksatam> enikanorov_: per Swami's comment earlier, i think the "flavor type" is confusing
17:37:02 <SumitNaiksatam> enikanorov_: if we need at all
17:37:24 <enikanorov_> agree, and there no such attr in the PoC code
17:37:27 <SumitNaiksatam> enikanorov_: do we?
17:37:37 <SumitNaiksatam> enikanorov_: okay, so we will wait for the code
17:37:50 <SumitNaiksatam> enikanorov_: perhaps a quick update of your wiki might help
17:38:01 <enikanorov_> yes, I'll do that
17:38:01 <Swami> ok thanks,
17:38:05 <SumitNaiksatam> enikanorov_: thanks
17:38:28 <SumitNaiksatam> enikanorov_: is there any notion of "namespaces" for the flavor names?
17:39:00 <enikanorov_> hmm, no... i think that could be solved by service_type, so different services could have flavors with same name
17:39:32 <SumitNaiksatam> enikanorov_: so you are still keeping the service_type for association with the "provider"?
17:39:54 <enikanorov_> basically i'm keeping service_type for convenience of consuption
17:40:10 <enikanorov_> horizon could filter flavors by the serrvice type
17:40:25 <enikanorov_> or otherwise full set of flavors may be confusing to the user
17:40:41 <Swami> enikanorov: can you provide some examples of "service_type" in this use case.
17:40:59 <enikanorov_> loadbalancer, vpn, firewall, etc
17:41:16 <enikanorov_> predefined network services that we already have
17:41:19 <enikanorov_> (static set)
17:41:42 <Swami> enikanorov: thanks
17:41:46 <SumitNaiksatam> enikanorov_: sorry, i was confusing the "service_type" attribute with the "service_type" in STF
17:42:16 <enikanorov_> well, if you're talking about providers - it's the same attribute, by nature
17:42:21 <SumitNaiksatam> enikanorov_: ok
17:42:32 <banix> Will the "service in a VM" be eventually a service type?
17:43:21 <enikanorov_> banix: no
17:43:29 <prasadv> banix: is service in a VM be different from physical service fi they are from same vendor?
17:43:32 <enikanorov_> it's not a service type in the meaning that we use
17:44:08 <SridarK> perhaps a different flavor ?
17:44:18 <s3wong> enikanorov_: so once haproxy works on service VM, is it the responsibility of serviceVM framework to define how to distinguish that from current impl?
17:44:43 <s3wong> or do you see flavor framework allowing tenants to choose?
17:44:48 <banix> well, my point is we may have a service that does not fit into the known set of services (or more generally we do not know what service it provides)
17:44:56 <enikanorov_> s3wong: most probably it will be another driver for service type LOADBALANCER that knows how to deal with haproxy in a VM
17:45:03 <SumitNaiksatam> yeah, i think there are two points we are discussing here
17:45:22 <SumitNaiksatam> banix and SridarK are referring to a service which is not yet defined in neutron
17:45:24 <prasadv> banix: I agree.
17:45:27 <SumitNaiksatam> being realized on a VM
17:45:48 <prasadv> i think we need a way to provision such a serice which is not defined in Neutron
17:45:51 <SumitNaiksatam> s3wong is asking about a service known to neutron, being realized on a VM
17:46:00 <banix> SumitNaiksatam: yes
17:46:03 <s3wong> SumitNaiksatam: and I am talking about known service in VM
17:46:13 <SumitNaiksatam> s3wong i think your use case js satisfied with this model
17:46:14 <s3wong> SumitNaiksatam: right
17:46:23 <SumitNaiksatam> per enikanorov_'s response
17:46:25 <banix> s3wong: right; two different things
17:46:30 <SumitNaiksatam> that is left to the driver
17:46:34 <Swami> The services that are not defined in Neutron, should they be added to neutron as a "Service" extension first
17:46:40 <SumitNaiksatam> coming back to banix and SridarK's point
17:47:01 <SridarK> SumitNaiksatam: actually i was just mentioning different realizations (or implementations from a vendor) could be different flavors
17:47:09 <SumitNaiksatam> enikanorov_: there is always a possibility of defining a new flavor type, right?
17:47:30 <SumitNaiksatam> SridarK in that case i think your use case is similar to s3wong's
17:47:34 <enikanorov_> SumitNaiksatam: yes. flavors are defined by admin, and could be listed by users
17:47:37 <banix> swami: not necessarily
17:47:39 <SumitNaiksatam> so banix's use case
17:48:01 <SumitNaiksatam> enikanorov_: yes assuming, that the admin defines such a flavor
17:48:02 <SridarK> SumitNaiksatam: yes
17:48:44 <SumitNaiksatam> the part that is a little inflexible here is about the "admin defining" the flavor
17:48:58 <SumitNaiksatam> since this is a matter of implementation and configuration
17:49:03 <s3wong> enikanorov_: so in this case, service_type can be defined by admin?
17:49:16 <enikanorov_> s3wong: defined - no, specified - yes
17:49:17 <SumitNaiksatam> we don't a framework to configure this dynamicallhy
17:49:20 <SumitNaiksatam> dynamically
17:49:29 <enikanorov_> so may be trying to answer a question on how to distinguish haproxy-on-host vs haproxy-on-vm
17:49:36 <SumitNaiksatam> banix: i see this as an evolution of the "flavor" framework
17:49:41 <enikanorov_> i don't see why a user may want to know that
17:49:55 <SumitNaiksatam> enikanorov_: do you agree?
17:49:59 <banix> SumitNaiksatam: yes to your earlier comments and this one too
17:50:13 <Kanzhe> banix: SumitNaiksatam enikanorov_ Service-type should be a list of Neutron services and a generic type for all services that is not defined by Neutron.
17:50:34 <enikanorov_> SumitNaiksatam: defining a service type is something that affects neutron core very deeply
17:50:48 <enikanorov_> i'm not sure we wand to really define service_type dynamically
17:50:55 <SumitNaiksatam> enikanorov_: that is an artifact of the design today
17:51:07 <s3wong> enikanorov_: user may not want to know whether haproxy runs on VM or lxc?
17:51:08 <banix> kanzhe: or having one specific to those realized in a VM; maybe?
17:51:10 <enikanorov_> in my mind that means that we would need to load a plugin that supports this new service type
17:51:12 <SumitNaiksatam> enikanorov_: and i agree that it cannot change overnight
17:51:26 <Kanzhe> Neutron's XaaS API is a service-configuration API. If a service is configured OOB, then admin should be able to make it available to tenants.
17:51:31 <enikanorov_> SumitNaiksatam: so it goes don to dynamic plugin loading
17:51:35 <enikanorov_> *down
17:51:46 <SumitNaiksatam> enikanorov_: it may not be a "generic" plugin
17:52:03 <SumitNaiksatam> enikanorov_: and that plugin can decide what modules to load dynamically
17:52:11 <Kanzhe> banix: Whether a service is realized in a VM or physical appliance should be captured by flavors.
17:52:37 <s3wong> Kanzhe: yes (as enikanorov_ mentioned above)
17:52:41 <enikanorov_> anyway, I've seen objections to such kind of dynamic stuff from salv-orlando
17:52:53 <enikanorov_> Kanzhe: may be captured by flavors
17:53:01 <enikanorov_> but there could be no need
17:53:02 <banix> kanzhe: agree; was wondering if the service in a VM being defined can be of a flavor on ts own….
17:53:11 <Kanzhe> SumitNaiksatam: yes, the "generic" plugiin really just do the insertion.
17:53:20 <SumitNaiksatam> regardless, i think what we need to agree on is, that if we follow the current path of flavors it should not preclude someone from being able to dynamically define services
17:53:40 <SumitNaiksatam> i think if we have agreement on that here, we are good for now
17:53:47 <enikanorov_> yep.
17:54:00 <SumitNaiksatam> everyone agree that the current flavors (as defined by enikanorov_ here) will allow that?
17:54:08 <banix> yes
17:54:12 <SridarK> yes
17:54:19 <Kanzhe> enikanorov_: I meant the services other than LB, VPN, FW.
17:54:27 <SumitNaiksatam> Kanzhe: agree?
17:54:39 <Kanzhe> SumitNaiksatam: yes.
17:54:46 <s3wong> Kanzhe SumitNaiksatam: somewhat like ML2 having a generic plugin, and everything else can be "service driver"
17:54:48 <Swami> yes
17:54:52 <SumitNaiksatam> s3wong: ye
17:54:53 <SumitNaiksatam> s
17:54:56 <SumitNaiksatam> ok good
17:54:57 <enikanorov_> Well, technically, you can specify any service_type because it is merely a string. but with current design it would be pointless
17:55:10 <SumitNaiksatam> lets wait for enikanorov_'s PoC and take it from there
17:55:14 <SumitNaiksatam> moving on
17:55:17 <enikanorov_> ok.
17:55:42 <SumitNaiksatam> #topic Group Policy requirements of advanced services
17:55:57 <SumitNaiksatam> so we had this on the agenda for the past two weeks
17:56:04 <SumitNaiksatam> but we did not get to it
17:56:14 <SumitNaiksatam> i would like to prioritize it this time
17:57:01 <SumitNaiksatam> so essentially for those not familiar with the "group policy" work, we are defining a policy abstraction
17:57:17 <SumitNaiksatam> each policy is comprised of rules
17:57:40 <SumitNaiksatam> each rule has a classification, and a corresponding action
17:57:47 <SumitNaiksatam> one of the actions is "redirect"
17:58:02 <SumitNaiksatam> redirect could be to a service or a service chain
17:58:27 <SumitNaiksatam> this is all captured here: #link https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E
17:59:00 <SumitNaiksatam> so at a high level, those abstractions expect some level of advanced services support from existing neutron abstractions
17:59:16 * cgoncalves waves to service chain :)
17:59:30 <SumitNaiksatam> in the case of redirect to an independent service
17:59:52 <SumitNaiksatam> we are somewhat covered (assuming we are able to merge the service_context notion)
18:00:04 <Kanzhe> SumitNaiksatam: should we get consensus on service insertion framework before go to GP redirect details?
18:00:06 <banix> One thing we discussed briefly was the insertion context and how that could be differnt for policies ...
18:00:20 <SumitNaiksatam> one sec
18:00:40 <s3wong> SumitNaiksatam: in that case, service-context needs to be defined outside of group-policy (which has no such knowledge)
18:00:44 <banix> SumitNaiksatam: gyes, o ahead please
18:00:52 <banix> yes, go ahead please
18:00:53 <SumitNaiksatam> Kanzhe: can you clarify what exactly you are referring to as "service insertion framework"?
18:01:19 <Kanzhe> SumitNaiksatam: insertion context. :-)
18:01:21 <SumitNaiksatam> just so that we are all on same page
18:01:50 <SumitNaiksatam> Kanzhe: you mean the "service_context" being introduced here: #link https://review.openstack.org/#/c/62599/
18:01:59 <Swami> sumitNaiksatam: Is the service insertion context driven by the group policy
18:02:05 <s3wong> Kanzhe: insertion context, is that the same as service context?
18:02:19 <SumitNaiksatam> if so we have discussed this in the past two meetings
18:02:24 <Kanzhe> SumitNaiksatam: s3wong yes.
18:02:27 <SumitNaiksatam> and i believe we all agree on the need for this
18:02:32 <Swami> Or service insertion has to be configured first for the service types and then we need to configure the group policy.
18:02:36 <SumitNaiksatam> hence i am not even bringing that up today
18:02:43 <SumitNaiksatam> Swami: one sec
18:02:48 <SumitNaiksatam> Swami: we will get to that
18:03:09 <SumitNaiksatam> i think we all agree on the need for the service_context for service insertion?
18:03:14 <Swami> sumit: thanks
18:03:16 <s3wong> SumitNaiksatam: when does the service_context get instantiated - I don't think there is a consensus
18:03:45 <SumitNaiksatam> ok so my question about agreement is in the context of the neutron elemental abstractions
18:03:53 <SumitNaiksatam> that is without group policy
18:03:58 <SumitNaiksatam> lets first base line off that
18:04:25 <Kanzhe> SumitNaiksatam: agree.
18:04:40 <Swami> sumitNaiksatam: Yes I like that
18:04:42 <s3wong> SumitNaiksatam: the need of service_context, yes - we agreed on that last week
18:04:51 <SumitNaiksatam> ok
18:05:11 <SridarK> SumitNaiksatam: One clarification - since we model the service_context as a service attribute what will we specify ?
18:05:41 <SumitNaiksatam> so without group policy we think we are good with service_context for inserting existing neutron services as independent entities
18:06:03 <SumitNaiksatam> SridarK: not sure i understand
18:06:06 <s3wong> SridarK: have we agreed on having service_context as part of service?
18:06:12 <Kanzhe> SumitNaiksatam: there is still a concern that the current service context is hard for tenant to consume.
18:06:13 <SridarK> in the redirect
18:06:24 <SridarK> since service context is not a resource
18:06:35 <SumitNaiksatam> Kanzhe: the service_context does not always have to be exposed to the user
18:06:42 <SumitNaiksatam> Kanzhe: or rather it can be optional
18:06:54 <SridarK> in the redirect do we specify the service instance ?
18:07:14 <SumitNaiksatam> SridarK: hang, we are not yet talking redirect
18:07:23 <SridarK> ok :-)
18:07:25 <prasadv> yes service context  would be needed for insertion
18:07:32 <Kanzhe> SumitNaiksatam: yes for default insertion. If a service needs to be inserted other than the default, tenant must specify through the service context.
18:07:39 <SumitNaiksatam> SridarK: want to first address that service_context is good for services as they are today (no group policy)
18:07:58 <SumitNaiksatam> enikanorov_: sound okay so far with service_context?
18:08:06 <s3wong> Kanzhe: would that be something appropriate for tenant to specify?
18:08:15 <SridarK> SumitNaiksatam: sorry that i am on board with - my confusion was on the redirect - i will wait
18:08:24 <SumitNaiksatam> SridarK: np
18:08:26 <s3wong> or do tenants consume network services as a service?
18:08:43 <Kanzhe> s3wong: that was the concern with the current service_context.
18:08:45 <SumitNaiksatam> s3wong: this does not have to be one or the other
18:08:49 <enikanorov_> SumitNaiksatam: yes
18:08:53 <SumitNaiksatam> enikanorov_: ok
18:09:22 <SumitNaiksatam> s3wong: as discussed above, the default consumption model might not require providing the service_context
18:09:22 <enikanorov_> sorry, need to step out of pc
18:09:56 <SumitNaiksatam> s3wong: so user may or may not specify it
18:10:24 <SumitNaiksatam> actually that is what we are doing with the FWaaS patch
18:10:25 <s3wong> SumitNaiksatam: certainly - I just think it is difficult for tenant to specify service_context outside of default
18:10:46 <SumitNaiksatam> s3wong: fine, but we don't necessarily take that option away
18:11:00 <SumitNaiksatam> * don't have to
18:11:15 <s3wong> SumitNaiksatam: OK
18:11:28 <Swami> sumitNaiksatam: You mentioned that the user need to specify the service_context, so how does Neutron select the service_context?
18:11:44 <SumitNaiksatam> i think we tend to get rat holed in the discussion about whether service_context is friendly to the user or not, but really its optional
18:12:07 <SumitNaiksatam> Swami: the service_context has to come from somewhere
18:12:19 <SumitNaiksatam> Swami: either the user provides it, or the backend infers it
18:12:37 <SumitNaiksatam> Swami: the service_context is merely a hook to provide this
18:12:52 <s3wong> SumitNaiksatam: well, if it isn't supposed to be specified by users, then we have to think about when the service context gets instantiated
18:13:27 <s3wong> SumitNaiksatam: so it isn't so much about being user friendly, just understanding when do we know where a service is supposed to be inserted
18:14:12 <SumitNaiksatam> s3wong: as of now, when a service gets inserted does not change by the introduction of the service_context
18:14:19 <mandeep> s3wong: I was hoping the "when/where" question to be driven by policy and "how" to be driven by service-context
18:14:34 <s3wong> Anyway - group policy and redirect, sorry for diverting the discussion :-)
18:14:34 <SumitNaiksatam> mandeep: exactly
18:14:47 <mandeep> SumitNaiksatam: I agree these are orthogonal concerns
18:15:23 <SumitNaiksatam> ok it seems we are more or less in agreement
18:15:49 <SumitNaiksatam> on the single/independent service as neutron understands it today
18:16:08 <SumitNaiksatam> so moving on in the context of group policy
18:17:10 <SumitNaiksatam> now let's address the concerns on if/how the service_context would help for single services
18:17:22 <mandeep> That way we have a single language for the user to specify service policy - independent of it being security/access issue or QoS or a richer service offered by an external/VM entity
18:17:24 <SumitNaiksatam> i think i put some folks on hold, please go ahead :-)
18:18:05 * mandeep was just agreeing with you, just using a lot of text to say that
18:18:26 <SumitNaiksatam> mandeep: yeah, i think what you are saying is that the policy will drive the service_context in that case
18:19:15 <banix> SumitNaiksatam: the idea is having a policy context as well. right?
18:19:37 <SumitNaiksatam> banix: can you elaborate?
18:20:16 <banix> If I understand it correctly a service oe a service chain gets inserted in a service context and then
18:20:58 <SumitNaiksatam> banix: lets break that down a bit
18:20:58 <banix> the context required for instantiating the service(s) get drived depending on the services…
18:21:14 <SumitNaiksatam> banix: before we get to service chains
18:21:27 <SumitNaiksatam> banix: lets first address the use case of redirect to a single service
18:21:31 <banix> sure
18:21:37 <s3wong> banix: actually I think we need a service context to see where a service is inserted, which may include a chain
18:21:52 <SumitNaiksatam> banix: and whether the service_context addresses that
18:22:00 <SridarK> SumitNaiksatam: If we take a fw usecase  with a fw created on a set of routers (service context), in the group policy - u would have a classifier and a redirect to that fw instance ?
18:22:08 <SumitNaiksatam> note that in this case the service_context is internal to the system
18:22:45 <SumitNaiksatam> the user who is interfacing with the system at the group policy abstraction level does not deal with the service-context directly
18:22:59 <banix> yes
18:23:09 <SumitNaiksatam> banix: ok good
18:23:17 <SumitNaiksatam> SridarK: yes
18:23:44 <s3wong> SumitNaiksatam: so going back to the earlier point, a plugin would need to populate a service_context according to policy?
18:23:58 <SumitNaiksatam> s3wong: yes
18:24:06 <SridarK> SumitNaiksatam: ok makes sense thanks
18:24:18 <SumitNaiksatam> s3wong:  this might be concert with the flavor/type of that service
18:24:44 <SumitNaiksatam> s3wong: but we ideally want to hide the service_context abstraction for the group policy user
18:24:50 <s3wong> SumitNaiksatam: in this case, service_context needs to be part of something else other than the actual service object
18:25:10 <s3wong> or even flavor
18:25:10 <banix> yes when the policy gets defined (or contracts are defined with consumer and providers specified) …. yes part of the contract/policy
18:25:44 <SumitNaiksatam> s3wong: why, i would argue that it needs to be part of each service so that there is a common programmable hook in each service
18:26:07 <s3wong> SumitNaiksatam: hiding it from group-policy for sure - I don't advocate adding insertion point as part of policy language :-)
18:26:23 <banix> sumit you were going to breakdown something
18:26:43 <SumitNaiksatam> s3wong: the policy "plugin" populates that service_context, and the service implementation handles it's implementation/insertion
18:27:03 <SumitNaiksatam> banix: i was breaking down in to the case of redirect to a single service, versus to a chain
18:27:07 <s3wong> SumitNaiksatam: because a plugin gets policy info, but plugin may not have access to the service object itself
18:27:24 <banix> SumitNaiksatam: so this implies we do not need a policy context
18:27:27 <banix> right?
18:27:58 <SumitNaiksatam> banix: i would imagine that the policy context you are referring to is the provided contract?
18:28:23 <banix> yeah
18:28:27 <SumitNaiksatam> banix: ok good
18:28:47 <SumitNaiksatam> s3wong: yes, plugin may not directly deal with the service
18:28:57 <OSM> Do we need to separate service definition (create) and instantiation (launch). Service context needs to be specified to instantion - by policy in some cases
18:29:01 <SumitNaiksatam> s3wong: the redirect can be to a "contract" which wraps the service
18:30:36 <SumitNaiksatam> i think the discussion is getting a bit muddled because we have to two cases for services (1) neutron services which are already defined and which have their own plugins (that can do the insertion based on the context)
18:31:21 <SumitNaiksatam> (2) generic services which are not recognized by neutron, and for which the policy plugin implementation might have to do additional operations
18:31:21 <s3wong> SumitNaiksatam: that means we need to extend EPG to include service
18:31:34 <SumitNaiksatam> s3wong: probably not
18:31:48 <banix> s3wong: hopefully not; why?
18:31:50 <SumitNaiksatam> s3wong: the contract can have a relationship to a service_type
18:32:20 <SumitNaiksatam> folks we are over our time
18:32:30 <SumitNaiksatam> the following meeting is also chaired by me
18:32:35 <SumitNaiksatam> so we can go a little over
18:32:54 <SumitNaiksatam> i am sure SridarK RajeshMohan and other FWaaS folks won't mind
18:33:01 <SridarK> no worries
18:33:12 <prasadv> sumitnaiksatam: you case (1) means that independent of policy service context needs to be deinfed?
18:33:16 <SumitNaiksatam> however we had another agenda item which Swami had brought up
18:33:26 <SumitNaiksatam> prasadv: no
18:34:12 <SumitNaiksatam> prasadv: it just means, that we need to figure how we can leverage the existing neutron service implementations within the policy plugin orchestration
18:35:00 <s3wong> SumitNaiksatam: in that case, I still don't understand - in case of not having group-policy - how we can populate service_context
18:35:03 <SumitNaiksatam> prasadv: so we can have a southbound "plugin driver" mechanism that can handle this
18:35:35 <SumitNaiksatam> s3wong:  ok so in case of not having group-policy the simplest way is:
18:35:52 <SumitNaiksatam> s3wong: the backend has a default insertion model, or
18:36:06 <SumitNaiksatam> and in which case it populates the service-context
18:36:15 <SumitNaiksatam> s3wong: or the user provides the service-context
18:36:52 <s3wong> SumitNaiksatam: backend meaning LBaaS, or even more specific like haproxy driver?
18:36:58 <prasadv> sumitnaiksatam: is the plugin driver under policy? or service?
18:37:30 <SumitNaiksatam> s3wong: it could be a combination of the service plugin and the service driver
18:37:31 <RajeshMohan> Hi Sumit
18:37:56 <SumitNaiksatam> RajeshMohan: hi, we will start FWaaS in a munute
18:38:04 <RajeshMohan> Ok
18:39:21 <SumitNaiksatam> i was saying earlier that we had another item on the agenda for this week
18:39:36 <SumitNaiksatam> Swami: we have run over by a bit, are you okay if we discuss next week>
18:39:37 <SumitNaiksatam> ?
18:41:14 <SumitNaiksatam> ok folks on the group policy discussion, i think we need to take this discussion to tomorrow's meeting
18:41:21 <banix> Thanks everybody
18:41:23 <SumitNaiksatam> but good start ;-)
18:41:29 <s3wong> Thanks!
18:41:35 <cgoncalves> SumitNaiksatam: sorry to disturb. regarding this meeting, would there be any interested in discussing the proposal I shared on the mailing list sometime here, or in another neutron meeting, or off IRC meeting?
18:41:35 <Swami> SumitNaiksatam: Ok we can discuss next week.
18:41:50 <SumitNaiksatam> cgoncalves: thanks for brining that up
18:42:01 <SumitNaiksatam> cgoncalves: yes sure lets put it on the agenda for the next week
18:42:17 * banix is totally disturbed/distracted with the discussion on #openstack-neutron about firewalls, hybrid plugins, and vif_details….
18:42:38 <SumitNaiksatam> banix: no worries, that's a fire burning
18:42:51 <SumitNaiksatam> ok lets wrap for today
18:42:51 <cgoncalves> SumitNaiksatam: ok. I was not sure whether we should bring it to the advanced service meeting or other neutron meeting
18:42:57 <cgoncalves> SumitNaiksatam: thanks.
18:43:00 <SumitNaiksatam> cgoncalves: your call
18:43:06 <SumitNaiksatam> #endmeeting