17:31:28 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:31:29 <openstack> Meeting started Wed Apr  9 17:31:28 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:31:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:31:32 <openstack> The meeting name has been set to 'networking_advanced_services'
17:31:49 <SumitNaiksatam> #topic Flavors Framework
17:31:58 <SumitNaiksatam> #link: https://review.openstack.org/#/c/83055/
17:32:06 <SumitNaiksatam> also #link https://wiki.openstack.org/wiki/Neutron/FlavorFramework
17:32:21 <SumitNaiksatam> enikanorov: i think there was some activity on the PoC patch
17:32:24 <Swami> hi
17:32:34 <SumitNaiksatam> Swami: hi, thanks for joining
17:32:39 <enikanorov> SumitNaiksatam: yes, but i think people reviewed it as regular one
17:32:51 <enikanorov> while i think it make sense to focus on shceduling part of it
17:32:56 <SumitNaiksatam> enikanorov: i know, more on syntax than semantics :-)
17:33:21 <SumitNaiksatam> enikanorov: yeah the scheduling part was not very clear to me
17:33:39 <SumitNaiksatam> enikanorov: for the benefit of everyone here, can you quickly walk through the workflow
17:33:46 <enikanorov> so the idea of scheduling is that it is falling into two parts
17:33:47 <SumitNaiksatam> enikanorov: if it can be done briefly
17:34:02 <enikanorov> 1. choose the provider that generally supports all requested capabilities
17:34:17 <enikanorov> 2. if provider manages some backends - try to chose particular backend
17:34:48 <enikanorov> #2 is totally driver-dependent operation, it can be omitted, e.g. scheduling on the driver side can be just empty
17:34:59 <enikanorov> so, for lbaas #2 could be agent scheduling
17:35:08 <enikanorov> so #1 will chose haproxy provider
17:35:15 <SumitNaiksatam> enikanorov: the “provider” definition here is per the service type framework?
17:35:18 <enikanorov> #2 will chose particular lbaas agent
17:35:21 <enikanorov> SumitNaiksatam: yes
17:35:31 <enikanorov> provider/driver
17:36:00 <garyduan> enikanorov: for #2, do you mean to choose different verdor's AGENT driver?
17:36:05 <enikanorov> if some driver manages hw/sw appliances, then #2 could be scheduling on them
17:36:26 <enikanorov> garyduan: no, scheduling is done on the plugin-driver side
17:36:33 <enikanorov> e.g. it chooses plugin-driver first
17:36:48 <garyduan> enikanorov: I see. so #2 is to talk to the device
17:37:03 <enikanorov> not exactly, i'd say
17:37:22 <enikanorov> driver evaluates available backends and choses matching backend
17:37:31 <SumitNaiksatam> enikanorov: moreover, the vendor name could be a “tag” value as well?
17:37:33 <enikanorov> it's not necessary to ommunicate with backends
17:37:50 <garyduan> enikanorov: understand now
17:37:51 <enikanorov> SumitNaiksatam: yes, i believe that was one of the unit tests showing such example
17:37:54 <Swami> enikanorov: What do you mean by backend here.
17:37:55 <SumitNaiksatam> enikanorov: to provide a hint to the scheduler
17:38:05 <SumitNaiksatam> enikanorov: ok
17:38:20 <enikanorov> Swami: backend is an entity actually implementing the service
17:38:35 <Swami> enikanorov: thanks
17:40:05 <enikanorov> that's it from my side...
17:40:10 <garyduan> enikanorov: probably, provider should do the validation to make sure the flavor can be scheduled to the backend
17:40:22 <enikanorov> garyduan: that's the step #2
17:40:37 <enikanorov> it can internally match flavor with capabilities of managed backends
17:41:20 <enikanorov> and if no backend is found, then scheduler may try to use another provider/driver
17:41:35 <songole> Is the plugin doing this match?
17:41:46 <garyduan> enikanorov: yes. that's what I am thinking now
17:43:13 <enikanorov> songole: basically, yes
17:43:21 <SumitNaiksatam> enikanorov: the “schedule” method is not defined in any base class in the current patch
17:43:49 <enikanorov> SumitNaiksatam: it's defined in class SchedulingProvidersPlugin
17:43:58 <enikanorov> it's in the test_flavors.py
17:43:59 <banix> can you post the link to the BP if handy
17:44:24 <SumitNaiksatam> banix: #link https://wiki.openstack.org/wiki/Neutron/FlavorFramework
17:44:26 <enikanorov> banix: https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework
17:44:29 <banix> thanks
17:44:31 <songole> enikanorov: thanks. what is the flavor framework doing in the process?
17:44:36 <enikanorov> yep, and the description is on the wiki
17:44:48 <enikanorov> songole: what do you mean?
17:45:27 <enikanorov> SumitNaiksatam: most of the meaningful code is in test_flavors, i intentionally didn't separate it to different files
17:45:50 <garyduan> enikanorov: does the capability have anything to do with extensions?
17:45:54 <SumitNaiksatam> enikanorov: ok
17:46:15 <enikanorov> garyduan: flavors are API extension itself
17:46:53 <SumitNaiksatam> enikanorov: so on the flavors API side
17:46:54 <songole> API lands on the plugin first. Is there an interface between plugin & flavor?
17:47:38 <enikanorov> songole: the plugin for the flavors API is FlavorManager, it's a class instance similar to plugins
17:47:52 <SumitNaiksatam> enikanorov: the API lets you programatically create flavors
17:47:58 <enikanorov> i think it makes sense to implement it like provider framework
17:48:02 <enikanorov> SumitNaiksatam: yes
17:48:23 <SumitNaiksatam> enikanorov: what about the “service types"
17:48:41 <banix> this may have been mentioned earlier but the provider knows how to schedule the backend? that is the idea behind having a two step approach here?
17:48:43 <enikanorov> right now patch assumes serviec types are constant
17:48:50 <enikanorov> LOADBALANCER, FIREWALL, etc
17:49:05 <songole> enikanorov: ok
17:49:40 <SumitNaiksatam> enikanorov: ok, that is fine for individual services
17:50:08 <SumitNaiksatam> enikanorov: there was a feeling that one should be able to dyncamically create and publish chains as well
17:50:15 <enikanorov> for combinations/types - i don't know yet. i think there should be API to define such types first
17:50:59 <Swami> will there be any validation to check if those chains are valid chains before deploying the service.
17:51:02 <s3wong> enikanorov: in that case, you would need more dynamic flavor - not constants service_type
17:51:05 <enikanorov> banix: provider/driver may need or need not scheduling at all, that's why it's delegated to the driver
17:51:31 <enikanorov> s3wong: right, instead of a string, that will be a foreign key to service-types
17:51:47 <enikanorov> but right now i'm not sure how flexible such construct can be
17:52:16 <enikanorov> i mean that a chain should have a driver, i don't think it can be arbitratry, can it?
17:52:28 <s3wong> enikanorov: yes, still undefined today
17:52:54 <SumitNaiksatam> enikanorov: i think we had this discussion earlier, the feeling is that there could potentially be a generic driver which might be able to handle such cases
17:52:59 <s3wong> enikanorov: there are two camps on that. We want to have fixed template for chains, or some of us also want to have dynamically defined chains
17:53:26 <enikanorov> SumitNaiksatam: i don't think it will be a major change even if service types will be dynamic
17:53:32 <SumitNaiksatam> enikanorov: at this point, if possible, it might be good to not close that possiblity
17:53:46 <SumitNaiksatam> enikanorov: ok good
17:53:54 <SumitNaiksatam> any more questions for enikanorov
17:54:03 <SumitNaiksatam> enikanorov: what is the plan forward
17:54:08 <banix> enikanorov: s3wong does it make sense to have one or more driver of srvice type "chain" that may be able to instantiate certain chains?
17:54:11 <SumitNaiksatam> enikanorov: when does this come out of WIP?
17:54:28 <enikanorov> well... I filed a design track for that
17:54:30 <SumitNaiksatam> banix: i believe that is the current plan
17:54:37 <enikanorov> on the summit, i mean
17:54:49 <SumitNaiksatam> enikanorov: so this will be WIP until/after the summit?
17:54:50 <enikanorov> so i hope to gather more attention of the core team
17:54:57 <s3wong> banix: yes, I believe that is what SumitNaiksatam said above. Having a driver to render the chain definition
17:55:16 <banix> enikanorov: shall we work on getting a more detailed design before then?
17:55:30 <enikanorov> SumitNaiksatam: considering the state of lbaas (where I was planning to apply it at first) i'm not sure i'm able to proceed with some non-wip code
17:56:04 <SumitNaiksatam> garyduan: would you be interested in trying this on FWaaS?
17:56:18 <enikanorov> banix: to me the design is quite straightforward, if you see some issues - feel free to email me or reach out to IRC, i'll update the wiki and the code
17:56:30 <banix> enikanorov: can you ellaborate what you mean by state of lbaas;
17:56:38 <banix> sorry for being ignorant on that front
17:57:04 <enikanorov> banix: np. we're thinking of some API redesign, and basically flavor framework is not a top priority there
17:57:17 <banix> enikanorov: i see. thx.
17:57:31 <enikanorov> btu i may try to apply the patch to some other adv service
17:58:21 <SumitNaiksatam> enikanorov: are you offering to apply the patch to some other adv service or are you suggesting that some one else can apply?
17:58:34 <enikanorov> btw, sorry for interrupting
17:58:52 <enikanorov> my patch assumes that service already employs provider framework
17:59:09 <enikanorov> and that is something that we had not agreement with some core team members
17:59:12 <enikanorov> so...
17:59:16 <SumitNaiksatam> enikanorov: ok, that is a bit of catch 22
17:59:25 <banix> Is it possible to invent a simple service just for experimentation? or the calue is in picking an existing service and see how it can use this framework?
17:59:35 <banix> value
17:59:39 <SumitNaiksatam> enikanorov: since the STF is not approved for FWaaS or VPNaaS
17:59:39 <enikanorov> banix: it's implemented in my patch :_)
17:59:52 <banix> enikanorov: right
18:00:11 <pcm> STF not hard to add though...
18:00:26 <enikanorov> SumitNaiksatam: so the value that i see in STF is dispatching mechanism, but STF is blamed for bad user experieence
18:00:26 <SumitNaiksatam> pcm: that is correct, the patches are already there
18:00:55 <SumitNaiksatam> pcm: yeah, per enikanorov ^^^ the STF future itself is uncertain
18:01:00 <Swami> pcm: Why was the STF patch not approved.
18:01:19 <SumitNaiksatam> Swami: see enikanorov’s comment ^^^
18:01:25 <pcm> Swami: I think the discussion of flavors put a hold on it.
18:01:31 <SumitNaiksatam> ok all, we have other topics
18:01:33 <songole> SumitNaiksatam: Apologies for my ignorance. What is STF?
18:01:42 <enikanorov> service type framework
18:01:48 <Swami> SumitNaiksatam,pcm: thanks
18:01:50 <songole> oh. thanks
18:01:50 <enikanorov> or provider framework
18:02:06 <SumitNaiksatam> lets think about what’s a good way to make progress, and if you have suggestions, please send to the mailer, we can revisit next week as to where we are
18:02:14 <SumitNaiksatam> songole: STF - service type framewrok
18:02:22 <SumitNaiksatam> moving on
18:02:40 <SumitNaiksatam> cgoncalves: wanted some time last week, and we could not accommodate that
18:02:50 <SumitNaiksatam> #topic Port chaining proposal
18:02:57 <cgoncalves> SumitNaiksatam: thanks
18:03:02 <SumitNaiksatam> #link https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit?pli=1#
18:03:16 <SumitNaiksatam> cgoncalves: i believe you sent an email to the mailer?
18:03:21 <cgoncalves> so, I don't know if any of you read that doc
18:03:37 <SumitNaiksatam> cgoncalves: i had a quick run through it
18:03:40 <cgoncalves> SumitNaiksatam: I did send an email to -dev ml some time ago
18:03:45 <SumitNaiksatam> hope others had a chance to look
18:03:54 <SumitNaiksatam> btw, enikanorov: thanks for the earlier update! :-)
18:04:07 <enikanorov> np!
18:04:44 <SumitNaiksatam> cgoncalves: does anyone have thoughts on cgoncalves’s proposal?
18:05:27 <SumitNaiksatam> cgoncalves: perhaps people need a little more time to read through
18:05:36 <SumitNaiksatam> cgoncalves: you want to quickly summarize?
18:05:43 <banix> cgoncalves: are you following the work being done on services in VMs? are these related?
18:05:49 <cgoncalves> in a nutshell: if I'm not mistaken, every Neutron network service is attached to a Neutron port. the currently work regarding network service chain only adresses those Neutron network services
18:06:25 <banix> cgoncalves: ignore my question and carry on pls
18:06:27 <cgoncalves> what I'm proposing is not restrict to those supported services but anything that is reached via a Neutron port
18:06:28 <SumitNaiksatam> cgoncalves: that is somewhat true (regarding each service attaching to a port)
18:06:34 <s3wong> SumitNaiksatam: cgoncalves: what are we really adding with port-based chaining over service-context based one?
18:07:05 <SumitNaiksatam> banix: service VM discussion coming up, hang in there :-)
18:07:34 <banix> SumitNaiksatam: sure. thanks.
18:07:36 <SumitNaiksatam> s3wong: it is supposed to be a more flexible approach
18:07:50 <cgoncalves> s3wong: in the service-context based one you can only attach Neutron services (vpn, lb, fw) to the chain. I'm proposing augumenting it to something more broad and hence a port-based approach
18:08:01 <SumitNaiksatam> s3wong: as banix hinted, this might have more relevance when services are in a VM
18:08:25 <cgoncalves> s3wong: so that you can mix in a chain VMs and Neutron services
18:08:45 <SumitNaiksatam> cgoncalves: so my take on this is that this could be potential approach to chaining
18:09:06 <cgoncalves> the group policy BP could also benefit from this approach rather than also be limited to the service-based approach
18:09:07 <s3wong> SumitNaiksatam: cgoncalves: yes, I can see more relevancy in case a service has multiple ports
18:09:17 <SumitNaiksatam> cgoncalves: however it requires the user to actually understand everything about how a service is realized
18:09:39 <SumitNaiksatam> cgoncalves: we were trying to hide that to some extent by making services available as *aaS
18:10:04 <s3wong> cgoncalves: for GBP, I don't know if tenants would even "see" a port to a service
18:10:21 <cgoncalves> SumitNaiksatam: yes, but as argued in the proposal Neutron can't keep up with all network services providing them as *aaS
18:11:07 <s3wong> cgoncalves: OK - you are thinking if the tenants themselves are bringing in their own services
18:11:10 <SumitNaiksatam> cgoncalves: that is true, but in that case that service is not a service, its just a VM as far as Neutron/OpenStack is concerned
18:11:33 <SumitNaiksatam> s3wong: yeah, mean to say the same thing
18:11:36 <cgoncalves> s3wong: yes. you can see use case #2 for instance (the DPI one)
18:11:42 <s3wong> SumitNaiksatam: but you can't chain that service then, right?
18:11:46 <cgoncalves> SumitNaiksatam: that's right.
18:11:47 <banix> Network Service as a Sevice?  NSaaS
18:11:57 <SumitNaiksatam> banix: :-)
18:12:02 <s3wong> banix: ha ha :-)
18:12:07 <SumitNaiksatam> recursive defintion like GNU
18:12:12 <banix> :)
18:12:25 <cgoncalves> SumitNaiksatam: the whole propose is to be agnostic to what's running in those ports, either a VM running some kind of service or a Neutron provided network service
18:12:53 <SumitNaiksatam> cgoncalves: essentially you want a way to be able to specify that traffic be steered between certain ports
18:13:43 <cgoncalves> btw, IETF folks have been recently working on the definition and such on this matter http://datatracker.ietf.org/wg/sfc/
18:13:55 <cgoncalves> SumitNaiksatam: yes.
18:13:59 <s3wong> cgoncalves: in case of GBP, in case of having service represented by a group, having to specify a "port" seems to be limiting
18:14:20 <SumitNaiksatam> s3wong: i dont see this being directly consumed at the policy abstraction level
18:14:36 <SumitNaiksatam> s3wong: however the “renderer” could potentially make use of this
18:14:37 <kanzhe> cgoncalves: what about define a "GenericServiceaaS" with service context? then undefined services can be inserted or chained with serviceContext.
18:14:53 <cgoncalves> SumitNaiksatam: given this approach, the work you've been working on Neutron network service chaining could use this work
18:15:06 <SumitNaiksatam> cgoncalves: yeah, i was trying to say that
18:15:39 <SumitNaiksatam> kanzhe: i see, that could be another way of doing it
18:15:57 <cgoncalves> s3wong: that could be hidden from the user, I guess
18:16:04 <s3wong> SumitNaiksatam: how so? The chain itself is "rendered" by GBP in our thinking so far, right (contract scope chains)?
18:16:16 <s3wong> or service object
18:16:25 <cgoncalves> kanzhe: that's another way, yes
18:16:38 <SumitNaiksatam> s3wong: still not completely sure, there are differing opinions :-)
18:16:56 <SumitNaiksatam> cgoncalves: ok thanks, good start, lets think about it a little more
18:17:08 <cgoncalves> kanzhe: but I think in that particular case you would say that VMs could be initiated and configured by Neutron just like other services (fw, lb, vpn)
18:17:09 <banix> cgoncalves: this all sounds very interesting; will read through more carefully and get back to you.
18:17:18 <cgoncalves> banix: thanks
18:17:19 <SumitNaiksatam> cgoncalves: and lets give others a chance to think through this as well
18:17:36 <cgoncalves> SumitNaiksatam: ok. thank you the time slot to briefly present it here
18:17:49 <SumitNaiksatam> cgoncalves: very welcome and we will circle back
18:17:59 <SumitNaiksatam> #tpoic Service VM progress update
18:18:08 <cgoncalves> we've been working on models and API. next week I think I can present something to you all
18:18:08 <SumitNaiksatam> #topic Service VM progress update
18:18:16 <SumitNaiksatam> cgoncalves: great thanks
18:18:29 <s3wong> cgoncalves: great. Looking forward to seeing that
18:18:36 <SumitNaiksatam> so yamahata cannot make it to this meeting
18:18:52 <SumitNaiksatam> s3wong: voluteered to provide update from the service VM meeting
18:18:59 <SumitNaiksatam> s3wong: over to you
18:19:09 <banix> s3wong: that's nice. thanks.
18:19:15 <s3wong> SumitNaiksatam: I see yamahata online, but I guess he is really sleeping now :-)
18:19:22 <kanzhe> cgoncalves: I think this group is working on many enhancement around XaaS to address resource scheduling, insertion, chaining, and other issues. The port-based proposal won't be able to leverage all the improvement.
18:19:28 <SumitNaiksatam> yamahata: there?
18:19:35 <s3wong> So yamahata has done pretty much all the work so far
18:19:39 <SumitNaiksatam> kanzhe: that is good point
18:19:46 <s3wong> the API and DB model is here:
18:19:48 <SumitNaiksatam> s3wong: yes please go on
18:20:06 <s3wong> #link https://review.openstack.org/#/c/72068/
18:20:53 <s3wong> The basic architecture consists of a management interface driver and a device manager/driver
18:21:12 <s3wong> management manager/driver is for management interface on the VM
18:21:27 <s3wong> device manager/driver is for managing the actual service VM
18:21:50 <cgoncalves> kanzhe: if you could elaborate more on that thought next week or mailing list I would appreciate :-)
18:22:18 <s3wong> at this point, the reference implementation we are aiming for is LBaaS haproxy driver on a VM
18:22:29 <s3wong> some preliminary diff can be found here:
18:22:42 <kanzhe> cgoncalves: sure.
18:22:52 <s3wong> #link https://review.openstack.org/#/c/72068/
18:23:01 <s3wong> that is not working yet, BTW
18:23:39 <SumitNaiksatam> the API patch is here #link https://review.openstack.org/#/c/56892
18:23:39 <s3wong> yamahata is also working with the community on defining a message proxy server
18:24:18 <s3wong> SumitNaiksatam: sorry, cut and paste error :-)
18:24:25 <SumitNaiksatam> s3wong: np
18:24:44 <s3wong> currently the suggestion is to use Marconi
18:24:45 <SumitNaiksatam> s3wong: perhaps let people dwell on these links a little more
18:24:56 <SumitNaiksatam> s3wong: ok, sounds logical
18:25:07 <s3wong> which I have no idea what Marconi really does, so I will refrain from commenting too much :-)
18:25:36 <s3wong> yamahata would like our comment on the API and DB model, especially
18:25:38 <SumitNaiksatam> s3wong: i believe they had applied for incubation
18:25:43 <SumitNaiksatam> s3wong: sure
18:26:02 <SumitNaiksatam> all, please respond to the review patches in Gerrit
18:26:06 <SumitNaiksatam> s3wong: thanks
18:26:10 <SumitNaiksatam> Swami: there?
18:26:27 <s3wong> SumitNaiksatam: Thanks for letting me proxy yamahata for couple minutes :-)
18:26:27 <Swami> yes here
18:26:47 <SumitNaiksatam> s3wong: we will circle back next week, thanks!
18:26:48 <banix> s3wong: thanks
18:26:57 <SumitNaiksatam> #topic Service Insertion for distributed service implementation
18:27:25 <SumitNaiksatam> Swami: you want to quicly brief the team about the issues you were facing?
18:27:38 <Swami> SumitNaiksatam: Yes
18:27:48 <SumitNaiksatam> Swami: please go ahead
18:28:12 <Swami> For the Distributed routed module, some of the services can be distributed and there are certain services that need to be centralized.
18:28:27 <Swami> Say for example FWaaS and LBaaS can be distributed.
18:28:47 <Swami> VPNaaS should be a singleton service and should be centralized.
18:29:18 <banix> Swami: dictributed as in a cluster
18:29:29 <Swami> Is there any way that we can identify the services and assign it to the right routers.
18:30:16 <Swami> banix: Distributed across your compute Nodes. For the Distributed Virtual Router, all tenant routers will be distributed and will be available in each and every compute node were the Tenant routed vm resides.
18:30:29 <s3wong> Swami: distributed LBaaS as in elastic load balancing?
18:30:32 <banix> swami: got it; thx.
18:30:36 <SumitNaiksatam> Swami: how useful do you think the “service_context” be in this case?
18:31:04 <Swami> s3wong: For LBaaS today it is not tied to the router, so it might not be a problem.
18:31:08 <SumitNaiksatam> BTW, we are the end of the meeting but we can go on longer, since i have the next meeting slot as well on this channel
18:31:15 <SumitNaiksatam> Swami: go ahead, take your time
18:31:27 <Swami> SumitNaiksatam: Thanks
18:31:47 <SumitNaiksatam> SridarK: apologies for the delay on FWaaS but i believe you are equally interested here :-)
18:32:05 <Swami> So here in this case we are proposing the chain is created and then we apply the chain to a router.
18:32:15 <SridarK> Yes no worries at all interested too SumitNaiksatam:
18:32:56 <Swami> How do we distinguish between the services and apply those service chains to the respective routers is my question.
18:33:10 <Swami> If this has not been addressed, then we should take it into consideration.
18:33:34 <SumitNaiksatam> Swami: we have discussed before, but we have not addressed it
18:33:48 <Swami> SumitNaiksatam: Yes I do agree.
18:33:59 <banix> Swami: agree
18:34:00 <SumitNaiksatam> Swami: since currently even the single service/centralized insertion is kind of fuzzy :-)
18:34:11 <banix> SumitNaiksatam: yeah :)
18:34:18 <Swami> SumitNaiksatam: Yes I agree .
18:34:34 <SumitNaiksatam> Swami: but this is a good time to bring this up, since we dont want to paint ourselves in a corner
18:34:50 <SumitNaiksatam> Swami: my earlier question, will sevice_context help in this case?
18:34:56 <kanzhe> Swami: This is the same issue with NAT service, which DVR proposal has a solution. Are you proposing a more generic way to tackle the problem?
18:34:56 <Swami> Even with today's model we might be able to include it into our discussion and see where we end up, rather than modifying our stuff later.
18:34:59 <SumitNaiksatam> Swami: or we need to think through it again?
18:35:20 <SumitNaiksatam> kanzhe: sorry go ahead
18:35:29 <SumitNaiksatam> Swami: kanzhe’s question ^^^
18:35:33 <Swami> SumitNaiksatam: yes we need to think through it again and probably walk through a use case.
18:35:59 <garyduan> Hi, sorry, I was in a meeting
18:36:14 <SumitNaiksatam> garyduan: np, we are still in the previous meeting too :-)
18:36:16 <Swami> kanzhe: yes DVR is proposing that NAT being done at the Service Node. That's where we are also thinking that the VPNaaS should be running.
18:36:35 <SumitNaiksatam> Swami: so NAT is still centralized?
18:37:03 <Swami> SumitNaiksatam: Yes SNAT is centralized, but for any floating ip it is still distributed.
18:37:32 <SumitNaiksatam> Swami: thanks, sorry for being slow, you had explained this before during the meeting
18:38:17 <Swami> SumitNaiksatam: What we can do is take the existing services and come up with a Use case on how it will be handled with the centralized and distribtued mode.
18:38:19 <SumitNaiksatam> Swami kanzhe: so in the distributed case, can we expect the service backend be expected to figure out how the distribution occurs
18:38:35 <Swami> Then we can discuss how the Framework will help deploy those services.
18:38:47 <SumitNaiksatam> Swami kanzhe: based on the service_context?
18:39:10 <Swami> SumitNaiksatam: yes the service_context.
18:40:13 <Swami> SumitNaiksatam: For next week we can plan on walking through the use-case.
18:40:49 <kanzhe> SumitNaiksatam: this is a good use case for service insertion. Swami: agree.
18:40:49 <s3wong> Swami: sounds good
18:41:12 <SumitNaiksatam> Swami kanzhe: can you guys set something up before the next week’s meeting?
18:41:33 <SumitNaiksatam> and whoever else is interested
18:41:34 <Swami> SumitNaiksatam: Yes I will work on that Use case with either You are kanzhe.
18:41:41 <SumitNaiksatam> Swami: thanks!
18:42:03 <Swami> SumitNaiksatam: Also one other information.
18:42:06 <SumitNaiksatam> Swami: and for bringing this up…sorry it took us two weeks to get this
18:42:20 <SumitNaiksatam> Swami: although you requested that this be discussed three weeks back
18:42:25 <SumitNaiksatam> for the record! :-)
18:42:27 <kanzhe> SumitNaiksatam: what is the venue? An IRC meeting before the next week's meeting?
18:42:29 <SumitNaiksatam> Swami: go ahead
18:42:46 <Swami> For the Certificate handling for all the services, should this be discussed in this meeting or is there another team for that.
18:42:47 <SumitNaiksatam> kanzhe: lets decide offline, i think we need a higher bandwidth channel
18:43:06 <kanzhe> SumitNaiksatam: sounds good.
18:43:07 <SumitNaiksatam> Swami: ah, you had asked that before as well
18:43:25 <SumitNaiksatam> Swami: i dont have any objections to discusisng it in this meeting
18:43:43 <Swami> I also discussed briefly about this with enikanorov.
18:44:02 <SumitNaiksatam> Swami: we are probably out of time this week, but lets circle back on this for the next week’s meeting
18:44:11 <SumitNaiksatam> everyone just one more topic
18:44:17 <Swami> Right now both LBaaS and VPNaaS needs some framework within the Neutron to support Certificates.
18:44:26 <SumitNaiksatam> Swami: sure
18:44:38 <SumitNaiksatam> #topic Adv Services logistics
18:44:43 <SumitNaiksatam> hope everyone is still around
18:44:46 <SumitNaiksatam> enikanorov: ?
18:44:47 <Swami> SumitNaiksatam: Thanks we can take this next week, I don't want to block your FWaaS meeting.
18:44:57 <SumitNaiksatam> so this thought just occured to me
18:45:00 <s3wong> SumitNaiksatam: this meeting needs to be at least 90 minutes long :-)
18:45:05 <SumitNaiksatam> based on Swami’s request
18:45:09 <SumitNaiksatam> s3wong: :-)
18:45:09 <enikanorov> i'm here still
18:45:18 <SumitNaiksatam> enikanorov: good
18:45:29 <SumitNaiksatam> so we have lots of things to discuss here
18:45:40 <SumitNaiksatam> under the advance services requirements agenda
18:45:52 <enikanorov> what's 'logistics' is about?
18:45:54 <SumitNaiksatam> we need a way to channelize this feedback and prioritize it
18:46:19 <SumitNaiksatam> enikanorov: probably bad choice of words, i meant process for channelizing feedback
18:46:31 <SumitNaiksatam> #undo
18:46:32 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2515590>
18:46:35 <enikanorov> ok
18:46:54 <SumitNaiksatam> #topic Advanced Services common requirements process and prioritization
18:47:12 <SumitNaiksatam> i think at this point we are not having enough core participation in this meeting
18:47:42 <SumitNaiksatam> and hence i am concerned that what we are discussing here does not have enough of a representation on the core team side
18:48:05 <SumitNaiksatam> does anyone have thoughts on this?
18:48:49 <SumitNaiksatam> One thing i can think off is having a standing item on this topic “Advanced Services common requirements” in the neutron IRC
18:49:21 <pcm> +1
18:49:24 <SridarK> SumitNaiksatam: +1 i think this is a good way to get more attention
18:49:25 <SumitNaiksatam> currently there is hardly any time given to advanced services in the neutron IRC
18:49:25 <banix> SumitNaiksatam: agree with the premise.
18:49:27 <Swami> SumitNaiksatam: Yes that would work out.
18:49:29 <Swami> +1
18:49:31 <kanzhe> SumitNaiksatam: That would be a good start.
18:49:35 <SumitNaiksatam> ok
18:49:39 <SumitNaiksatam> enikanorov: what do you think?
18:49:39 <s3wong> SumitNaiksatam: sure +1
18:50:10 <SumitNaiksatam> we should check with nachi as well
18:50:20 <SumitNaiksatam> enikanorov: there?
18:50:23 <enikanorov> i'll support this idea
18:50:28 <SumitNaiksatam> enikanorov: ok
18:50:29 <banix> and the API group?
18:50:44 <SumitNaiksatam> we should not expect to get too much time
18:50:58 <SumitNaiksatam> but just enough to highlight our high priority items
18:51:12 <SumitNaiksatam> that way we can get on the radar
18:51:32 <SumitNaiksatam> ok, enikanorov, lets try to reach out to nachi, and try to work through this
18:51:48 <SumitNaiksatam> #topic Open Discussion
18:51:51 <enikanorov> sure
18:51:55 <SumitNaiksatam> anythin more for today?
18:51:58 <SumitNaiksatam> enikanorov: thanks
18:52:34 <SumitNaiksatam> okay i think its been a fairly long meeting
18:52:44 <SumitNaiksatam> thanks all for joining and hanging in there
18:52:47 <banix> bye
18:52:52 <SumitNaiksatam> bye all!
18:52:58 <s3wong> bye!
18:53:01 <SumitNaiksatam> #endmeeting