17:03:08 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:03:08 <openstack> Meeting started Wed Mar 19 17:03:08 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:12 <openstack> The meeting name has been set to 'networking_advanced_services'
17:03:29 <SumitNaiksatam> cgoncalves: lets check after the meeting on how to change ical
17:03:33 <SumitNaiksatam> Meeting agenda: #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices
17:04:03 <SumitNaiksatam> as we discussed last time there are many topics of interest for this forum
17:04:20 <SumitNaiksatam> please feel free to add the topics of interest to the wiki page ^^^
17:04:27 <SumitNaiksatam> and we can accordingly prioritize
17:04:47 <SumitNaiksatam> i just picked an agenda for today based on the discussions during the week (and past meeting)
17:04:56 <s3wong> SumitNaiksatam: Are the topics priortized on the wiki page now?
17:05:02 <SumitNaiksatam> but definitely open to suggestions
17:05:07 <cgoncalves> SumitNaiksatam: I would add the chaining thing I talked with you yesterday but I'll have to leave in 25m
17:05:18 <SumitNaiksatam> s3wong: the topics of discussion are not necessarily in order of priority
17:05:19 <s3wong> i.e., meaning that "Group Policy requirements" has the highest priority :-)
17:05:30 <SumitNaiksatam> s3wong: ha...you wish :-)
17:05:49 <SumitNaiksatam> cgoncalves: sure, that becomes part of the chaining discussion
17:05:58 <banix> May be we are on the "next meeting"?
17:06:18 <SumitNaiksatam> banix: "next meeting" as in today's meeting
17:06:19 <banix> I mean the entry for the next meeting is for this meeting
17:06:24 <banix> yes
17:06:27 <SumitNaiksatam> #topic Service context
17:06:35 <SumitNaiksatam> #link https://review.openstack.org/#/c/62599
17:06:55 <SumitNaiksatam> so last week we tried to get everyone upto speed with this
17:07:18 <SumitNaiksatam> the above patch proposes the notion of the service context
17:07:30 <SumitNaiksatam> wanted to check if you had a chance to think over this
17:08:07 <SumitNaiksatam> it seems like this is a small first step to achieve the other things we want to with services
17:08:14 <SumitNaiksatam> this might not be sufficient though
17:08:34 <banix> yes, with the current available options for a context being: port, network, subnet, router
17:08:39 <SumitNaiksatam> (we can come to the not sufficient part in the next agenda topic)
17:08:51 <SumitNaiksatam> banix: ok
17:09:00 <s3wong> SumitNaiksatam: not really gone through the code yet, but the current definition of service context seems like a good first step
17:09:19 <SumitNaiksatam> s3wong: yes sure, i think it might be difficult to glean the intent from the code
17:09:45 <SumitNaiksatam> the google doc was trying to capture the intent: #link https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
17:10:08 <SumitNaiksatam> ok anyone have different thoughts on this?
17:10:56 <SumitNaiksatam> if not, can we comment on the above review?
17:11:18 <SumitNaiksatam> that way we can hopefully have the service_context notion available early in Juno and we can build on it
17:11:20 <banix> I think the google doc referenced in the link above ^^^ is a good place for different parts of the services framework
17:11:27 <SumitNaiksatam> banix: ok
17:11:38 <s3wong> SumitNaiksatam: will review the code - though not happening during this meeting...
17:11:50 <SumitNaiksatam> s3wong: sure :-)
17:12:19 <SumitNaiksatam> ok so let's move on to the next topic
17:12:38 <SumitNaiksatam> #topic Base Service definition
17:12:42 <banix> yes will look more closely; my only comments were related to the policy work which we will cover later.
17:12:52 <SumitNaiksatam> banix: yes sure
17:13:03 <SumitNaiksatam> #link https://github.com/openstack/neutron/blob/master/neutron/services/service_base.py
17:13:37 <SumitNaiksatam> some of us met yesterday in person (those who are local in the bay area)
17:13:55 <SumitNaiksatam> and were brainstorming on discussion from the last IRC meeting
17:14:20 <s3wong> SumitNaiksatam: what is this service_base thing? seems to depend on service type framework?
17:14:39 <SumitNaiksatam> s3wong: yeah, getting there - trying to expelling the context
17:15:08 <SumitNaiksatam> we were reaching the realization that the service_context itself might not be enough to support "user defined" chaining
17:16:07 <SumitNaiksatam> by "user defined" chaining i mean the point that was raised by s3wong banix and others last time, that one should be able to create a chain from any collection of available services
17:16:40 <SumitNaiksatam> and not be limited to those defined in as a service-type/flavor
17:17:10 <SumitNaiksatam> to support this it would require that each service provide information about where it plugs into the topolocy
17:17:15 <SumitNaiksatam> *topology
17:17:43 <SumitNaiksatam> using this information, the chain provider can chain these services
17:18:11 <SumitNaiksatam> however, today's base service definition (link above) does not have any notion of this
17:18:46 <SumitNaiksatam> ideally, something like "get_service_attachment_ports" kind of an api
17:18:56 <SumitNaiksatam> thoughts?
17:19:08 <SridarK> SumitNaiksatam:  so just as one would pick a flavor - we also want to be able to pick a chain
17:19:45 <SumitNaiksatam> SridarK: this is the case where the chain is constructed by the user, not based on chain defined as a flavor
17:19:54 <enikanorov__> SumitNaiksatam: that makes sense. it also means that service's driver api should have such method as well.
17:19:59 <SridarK> ok got it
17:20:04 <s3wong> SumitNaiksatam: seems like we may need tenants with their own service to have APIs to fill out a service context for their own service?
17:20:06 <banix> each service or each service driver
17:20:22 <enikanorov__> because attachment ports could be different for diff drivers
17:20:39 <SumitNaiksatam> enikanorov__ banix: i am referring to the logical neutron port as the attachment point
17:21:03 <SumitNaiksatam> which can be returned by the service plugin (it might perhaps depend on the driver)
17:21:18 <enikanorov__> i think it does depends on the driver
17:21:30 <SumitNaiksatam> the assumption is that the chain provider can map the attachment point (neutron port) to the backend realization
17:21:51 <s3wong> SumitNaiksatam: do we expect the chain provider to do traffic steering (to the next service in chain, for example)
17:22:14 <s3wong> or that the service themselves would send traffic to the next element by querying the chain for where the next service is?
17:22:27 <cgoncalves> SumitNaiksatam: I haven't put enough though on the implementation part, but this neutron network service chain and service context could get deprecated in favor of a generic chaining mechanism where we define chains were not based on neutron network services but on neutron ports, as neutron network services are accessible as neutron ports. this way we could mix network services and machines in chains
17:22:36 <SumitNaiksatam> enikanorov__: well, i am saying that the API is on the service, to satisfy it, might require driver participation
17:22:49 <SumitNaiksatam> s3wong: i would imagine its the former
17:23:22 <enikanorov__> ok
17:23:29 <banix> SumitNaikasatam: makes sense
17:23:42 <SumitNaiksatam> cgoncalves: in the group yesterday we discussed your proposal for neutron ports
17:24:02 <SumitNaiksatam> cgoncalves: that is neutron ports to specify a service chain
17:24:14 <SumitNaiksatam> cgoncalves: however that does not seem to be the right user facing abstraction
17:24:42 <SumitNaiksatam> cgoncalves: it requires the user to understand how each service is instantiated
17:24:55 <SumitNaiksatam> cgoncalves: there are other ways to satisfy to your use case
17:24:58 <SumitNaiksatam> banix: ok
17:25:26 <SumitNaiksatam> enikanorov__: what are your thoughts on introducing this API in the service base class?
17:25:52 <enikanorov__> i'm fine with that, however I need to understand how this maps to flavors
17:25:54 <enikanorov__> i can explain
17:26:09 <SumitNaiksatam> enikanorov__: go ahead
17:26:30 <enikanorov__> given that actual service provider (driver) will be a result of scheduling based on flavor
17:26:54 <cgoncalves> SumitNaiksatam: how would users have to understand how each service is instantiated? services would be instantiated on a neutron port and nothing more. it would then be up to the user to strategically place the service where he wants (e.g., in between two other neutron ports)
17:26:54 <enikanorov__> that becomes a requirement that driver publishes it's capability of support for certain chain type
17:27:25 <cgoncalves> SumitNaiksatam: but that we can discuss off meeting
17:27:40 <enikanorov__> so basically service context and then get_attachment_ports should match driver's capabilities
17:28:14 <enikanorov__> i hope i get all that right :)
17:28:26 <banix> cgoncalves: please let us know if there are any pointers to your proposal so we can review (after the meeting in my case)
17:28:48 <s3wong> enikanorov__: wouldn't that mean that all the chains have to be pre-defined by OpenStack community? because otherwise drivers can't know what the available chain types are?
17:29:27 <enikanorov__> s3wong: i believe that was the initial proposal, to have predefined chains. and we've discussed that on previous meeting
17:29:35 <SumitNaiksatam> enikanorov__ s3wong: i think the chain provider should know of the service constructs, but the service should not have to know of the chain construct
17:29:50 <cgoncalves> banix: I've started today writing proposal on a google doc. I'll share with you all as soon as it gets some form to discuss
17:30:01 <SumitNaiksatam> cgoncalves: thanks
17:30:02 <cgoncalves> folks, I will have to leave now. will catch up with the meeting log later today
17:30:09 <banix> cgoncalves: thanks
17:30:21 <s3wong> cgoncalves: have fun
17:30:35 <cgoncalves> thank you all!
17:30:44 <SumitNaiksatam> enikanorov__: in the predefined case the chain provider is performing the insertion
17:30:49 <banix> SumitNaiksatam: +1 wrt having user defined chains
17:31:07 <enikanorov__> that seems to be difficult
17:31:11 <SumitNaiksatam> enikanorov__: so yeah, the above discussion is not as relevant
17:31:40 <SumitNaiksatam> enikanorov__: ok let me reword that, the chain provider provides the service_context for insertion
17:31:40 <s3wong> I agree with SumitNaiksatam here - services should not have notion of chains, while chains should know about services
17:32:12 <banix> yup
17:32:13 <enikanorov__> if chain provider does the insertion, will not it require it to support particular drivers of particular services?
17:32:29 <SumitNaiksatam> enikanorov__: i clarified above ^^^
17:32:30 <enikanorov__> I probably don't understand this completely
17:32:39 <enikanorov__> oh, yep, thanks
17:32:42 <enikanorov__> that makes sense
17:32:48 <SumitNaiksatam> enikanorov__: yeah my bad
17:33:27 <SumitNaiksatam> ok so in the "user defined" chain case, the chain provider is not in the best position to provide the service context
17:33:35 <SumitNaiksatam> for each service
17:34:12 <s3wong> SumitNaiksatam: isn't service context always provided by the service?
17:34:13 <banix> can it drive the required context from a source/destination context?
17:34:15 <SumitNaiksatam> so the thinking is that it would rely on the service to provide the details of how the insertion happened, and then use that information to do the steering
17:35:07 <SumitNaiksatam> s3wong: so we are saying the user or the chain provider provides the service_context (except in cases when its a "user defined" chain)
17:35:43 <SumitNaiksatam> banix: good point, it seems difficult for the chain provider to do this when the nature of services is not know before hand
17:36:15 <SumitNaiksatam> banix: so in the workflow for the "user defined" chain will probably not even have the source and destination chain context
17:36:34 <SumitNaiksatam> banix: each service will be created (with service context) individually
17:36:52 <banix> SumitNaiksatam: ok
17:36:54 <SumitNaiksatam> banix: like how you would create a stand alone service (with service_context)
17:36:55 <s3wong> SumitNaiksatam: when a service is instantiated, user/service-itself should clarify the insertion points
17:37:02 <SumitNaiksatam> s3wong: yeah
17:37:29 <s3wong> in that case, much of the information needed for service context is filled up at that point
17:37:30 <SumitNaiksatam> banix: and then the user creates the "user defined" chain merely stating which services he wants to be part of that chain
17:38:22 <SumitNaiksatam> however, at this point the "user defined" chain provider kicks in, and needs to be able to steer the traffic between the different services
17:38:46 <SumitNaiksatam> and hence it needs to know from each service, where it has attached in the network
17:39:13 <SumitNaiksatam> note that the service_context, and the actual attachment/insertion point are slightly different
17:39:29 <SumitNaiksatam> service_context is a sort of hint to express the intent
17:39:31 <banix> SumitNaiksatam: Let's see if I understand this
17:39:58 <SumitNaiksatam> each service implementation/provider/driver has its own way of actually inserting
17:40:22 <SumitNaiksatam> banix: go ahead
17:40:58 <banix> I was thinking along the line that for a user defined chain, the chain provider will set the insertion context for the services. Does that make sense?
17:41:32 <s3wong> banix: how so? how does the chain provider know where to insert the service?
17:42:10 <SumitNaiksatam> banix: the point s3wong is making is that, when you know what the service is going to be, you can bake that into the implementation
17:42:17 <banix> It has to be given some context but not contexts for all the individual services
17:42:24 <SumitNaiksatam> banix: that -> insertion
17:42:48 <SumitNaiksatam> banix: but when you don't know the composition of the chain, its difficult to do
17:43:24 <banix> yes unless the chain provider knows certain types of services
17:43:56 <SumitNaiksatam> banix: exactly, hence the earlier suggestion to have templates/flavors for chains
17:43:57 <banix> and can support them in a chain: meaning it know how to chain certain types of services.
17:43:57 <enikanorov__> btw, is my understanding correct that chain providing actually does the steering? I mean that it operates on already created services that are already somehow plugged into a network, right?
17:44:05 <s3wong> banix: in that case we are restricting users to bring in a service that is not yet supported by Neutron
17:44:38 <banix> well, we could be somewhere in between :)
17:44:39 <SumitNaiksatam> enikanorov__: yes on the first part, different people have different understanding on the latter part
17:44:48 <s3wong> enikanorov__: that was my question above too - but SumitNaiksatam indicates that service insertion point != chain attachment points
17:45:09 <SumitNaiksatam> ok folks, i want to give enikanorov__ a chance for the flavors update as well
17:45:36 <SumitNaiksatam> the chain part is a  difficult discussion on IRC
17:45:41 <enikanorov__> not much to update. I am actually working on PoC code that will illustrate the proposal
17:45:41 <banix> yes please go ahead
17:46:00 <SumitNaiksatam> we can circle back to this topic
17:46:08 <enikanorov__> e.g. it will have an extension, db part and a test plugin with drivers where service could be requested by capabilities
17:46:09 <s3wong> enikanorov__: nice
17:46:13 <SumitNaiksatam> #topic Flavors update
17:46:20 <SumitNaiksatam> enikanorov__: nice
17:46:34 <SumitNaiksatam> enikanorov__: so what approach are you taking for the PoC
17:47:01 <SumitNaiksatam> as currently documented in the wiki: #link https://wiki.openstack.org/wiki/Neutron/FlavorFramework?
17:47:01 <enikanorov__> well, currently i'm thinking about flavor as a set of 'tags'
17:47:17 <enikanorov__> probably that is the simplest to implement
17:47:48 <SumitNaiksatam> enikanorov__: define "tags"
17:47:53 <SumitNaiksatam> as in labels?
17:48:21 <enikanorov__> currently thinking about k:v pairs as tags
17:48:51 <SumitNaiksatam> enikanorov__: ok
17:49:00 <enikanorov__> so a flavor will be something like {'quality': 'good', 'topology': 'ha'}
17:49:20 <s3wong> enikanorov__: so what happens if more than one driver can satisfy all the tags?
17:49:32 <enikanorov__> s3wong: that goes to scheduling algorithm
17:49:44 <enikanorov__> and it chooses. it may be random
17:49:49 <SridarK> enikanorov__: beyond scheduling we can also specify a vendor ?
17:50:09 <enikanorov__> SridarK: that is a first requirement to implement existing workflow with providers
17:50:11 <SumitNaiksatam> SridarK: i think vendor could be one of the "tags"
17:50:19 <enikanorov__> so vendor is just a tag
17:50:22 <enikanorov__> yep
17:50:26 <SridarK> ok
17:50:34 <SumitNaiksatam> enikanorov__: what are the required fields in the flavor definition?
17:50:53 <enikanorov__> service_type, name, tags
17:51:07 <SumitNaiksatam> enikanorov__: tags could be empty, right?
17:51:09 <enikanorov__> tags are in a form of string concatenated from pairs k:v, k:v
17:51:14 <enikanorov__> hmm
17:51:28 <enikanorov__> yes, why not
17:51:43 <SumitNaiksatam> enikanorov__: no i mean, you need to spec that out clearly
17:52:10 <SumitNaiksatam> enikanorov__: if it cannot be empty, then it means there is a mandatory field in there
17:52:14 <SumitNaiksatam> enikanorov__: right?
17:52:25 <enikanorov__> i mean that i didn't think about it specifically, but right now i cant' think of what prevents us from having empty tags in a flavor
17:52:27 <SumitNaiksatam> enikanorov__: i am not proposing that, i think it could be empty
17:52:36 <SumitNaiksatam> enikanorov__: yes
17:52:52 <SumitNaiksatam> enikanorov__: essentially we are saying that the tags are completely service dependent
17:53:16 <SumitNaiksatam> enikanorov__: do we need to identify any parameters that are common across services?
17:53:21 <enikanorov__> well, since tags are written in a free form
17:53:28 <SumitNaiksatam> Kanzhe hemanthravi: welcome :-)
17:53:30 <enikanorov__> it's admin's responsibility to make it consistent
17:53:37 <enikanorov__> that's my opinion
17:53:49 <SumitNaiksatam> enikanorov__: no i mean apart from the tags
17:53:55 <hemanthravi> sumitnaiksatam: thought the irc was at 11...my mistake
17:54:00 <Kanzhe> sorry, I went on a wrong meeting.
17:54:08 <SumitNaiksatam> hemanthravi Kanzhe: np :-)
17:54:22 <enikanorov__> apart from tags i see flavor name, and service type
17:54:25 <s3wong_> Kanzhe hemanthravi: was wondering where you guys were :-)
17:54:29 <enikanorov__> nothing else
17:54:43 <SridarK> enikanorov__: Is the plan to target J1 or early J2 ?
17:54:44 <SumitNaiksatam> enikanorov__: where service_type is a predefined constant?
17:55:01 <enikanorov__> SumitNaiksatam: yes, service type is predefined
17:55:06 <hemanthravi> had an older advsvc invite on my cal :)
17:55:10 <enikanorov__> SridarK: J1
17:55:28 <SridarK> enikanorov__: Thanks that will help
17:55:40 <SumitNaiksatam> enikanorov__: there was a suggestion to include service_context as part of flavor
17:55:47 <SumitNaiksatam> enikanorov__: i am not necessarily in favor of that
17:56:14 <enikanorov__> hm, that's something i need to understand. service context is not a very user-friendly abstraction IMO
17:56:17 <SumitNaiksatam> enikanorov__: but wanted to check what is the current thinking
17:56:34 <SumitNaiksatam> enikanorov__: agree, service_context need not be user facing
17:56:47 <s3wong_> SumitNaiksatam: by including service context in flavor, then the service driver effectively limit how the service can be inserted into the chain - not necessarily a bad thing
17:56:49 <SumitNaiksatam> enikanorov__: it can be derived based on other user friendly tags
17:57:01 <SumitNaiksatam> s3wong_: possibly
17:57:34 <SumitNaiksatam> enikanorov__ s3wong_: i guess since tags are free form, a particular implementation might decide to expose service_context to the user
17:57:49 <SumitNaiksatam> not necessary that the user has to populate it
17:58:04 <Kanzhe> enikanorov__: agree that serviceContext is not user friendly. However, the need for a insertionContext is immediate for every services.
17:58:17 <banix> Need two minutes before we end the meeting: we may need to change the time or IRC channel
17:58:21 <s3wong_> Kanzhe: agreed
17:58:38 <banix> got a message from tax indicating there is a conflict on meeting-3
17:58:49 <enikanorov__> Kanzhe: i think service context is not directly related to a flavor
17:58:51 <SumitNaiksatam> banix: ah
17:58:56 <enikanorov__> for isntance
17:58:57 <banix> Nova bug scrub meeting is every Wednesday at 16:30 UTC
17:58:57 <Kanzhe> We refine the proposal to make it as user friendly as possible, not postpone the effort.
17:58:57 <s3wong_> banix: tax? :-)
17:59:06 <SumitNaiksatam> i did not see any conflicts when we reserved
17:59:17 <banix> ttx
17:59:23 <SumitNaiksatam> they may have changed the time
17:59:28 <hemanthravi> 10 am on meeting-3 is the right time?
17:59:30 <enikanorov__> Kanzhe: flavor may declare that service supports routed insertion (with tag 'router': 'yes', for example)
17:59:50 <banix> how about going to 17:30?
17:59:51 <s3wong_> perhaps moving it an hour later? ML2 is the hour earlier, so conflict there for a lot of folks
17:59:51 <enikanorov__> and the insertion context is something that is used on background
17:59:53 <SumitNaiksatam> #topic meeting day/time
18:00:17 <SumitNaiksatam> banix: we have the fwaas meeting scheduled at 18.00 UTC
18:00:22 <SumitNaiksatam> although we are not having it today
18:00:31 <Kanzhe> enikanorov__: Routed insertion may address most of the use case for LB, but limits other type of services
18:00:33 <banix> could it be because it was 16:30 we didn't notice the conflict?
18:00:35 <banix> i see
18:01:06 <SumitNaiksatam> ok we have reached to the hour
18:01:19 <SumitNaiksatam> lets discuss meeting day/time between us
18:01:20 <enikanorov__> Kanzhe: i meant that user doesn't specify insertion context, it's chain provider that passes context to a service
18:01:34 <enikanorov__> if service declared such support via capability
18:01:35 <SumitNaiksatam> lets continue the discussion, an hour is proving to be too short
18:01:46 <SumitNaiksatam> we can move over to -neutron
18:01:50 <SumitNaiksatam> #endmeeting