17:30:35 <mestery> #startmeeting Networking Advanced Services
17:30:35 <openstack> Meeting started Fri Jun 27 17:30:35 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:30:38 <openstack> The meeting name has been set to 'networking_advanced_services'
17:30:45 <mestery> #topic Flavor Framework Conclusions
17:31:03 <mestery> Hopefully by now most people ahve read both proposals from enikanorov and markmcclain.
17:31:10 <SumitNaiksatam> mestery: yes
17:31:20 <mestery> What I'd like to see here is we come to an agreement on these which moves us forward for Juno.
17:31:22 <SumitNaiksatam> markmcclain: thanks for posting yours
17:31:27 <mestery> markmcclain: Yes, thanks for posting that!
17:31:34 <dougwig> hi
17:31:45 <SumitNaiksatam> mestery: +1
17:31:53 <markmcclain> sorry it took so long.. connectivity in west montana wasn't so good :)
17:32:24 <mestery> I think banix and enikanorov made some good attempts at summarizing hte key differences between the proposals in comments on markmcclain's spec.
17:32:38 <mestery> I think first of all, we're all in agreement we want flavors in Juno, right? :)
17:32:51 <SumitNaiksatam> mestery: yes! :-)
17:32:54 <enikanorov> yes
17:32:56 <garyduan> yes
17:33:01 <SumitNaiksatam> mestery: +2, A
17:33:11 <banix> yes
17:33:24 <markmcclain> yes
17:33:25 <mestery> I also think we need to move forward quickly on this, given where we're at and the time left, so something simple which can grwo in future releases makes sense.
17:33:40 <mestery> After saying all that, where should we start on coming to a conclusion here? :)
17:34:15 <markmcclain> yes time is critical here
17:34:23 <enikanorov> the approaches are quite different, to me it doesn't seem that one is simpler then the other
17:34:47 <enikanorov> so basically it's about doing something that could be easily extended later
17:34:52 <SumitNaiksatam> should we first looks for things which are obvious and we certainly want to do as a first iteration?
17:35:03 <SumitNaiksatam> *look
17:35:23 <markmcclain> SumitNaiksatam: yes that was make approach when I stepped back last week to look at the problem anew
17:35:26 <mestery> enikanorov: Agreed, something simple for now which allows for expansion in the future.
17:35:33 <SumitNaiksatam> markmcclain: great!
17:35:33 <markmcclain> s/make/my/
17:36:07 <SumitNaiksatam> so we have been all talking about differences, what are the common things between the two proposals?
17:36:18 <SumitNaiksatam> is the user facing API consistent across the two
17:36:27 <enikanorov> SumitNaiksatam: yes
17:36:33 <enikanorov> it's flavor_id on the service instance
17:36:46 <enikanorov> but that's integration part, I'd say
17:37:04 <SumitNaiksatam> enikanorov markmcclain: so what the user sees as a part of the flavor definition is the same across both the proposals?
17:37:16 <enikanorov> SumitNaiksatam: that's no so similar
17:37:22 <SumitNaiksatam> (i have read the proposals, but just want to make sure that we are all on teh same page here)
17:37:27 <markmcclain> yeah we agree on attaching flavor_id to the logical service and also once it's bound dispatching calls directly to driver
17:37:38 <enikanorov> in markmcclain's proposal user sees description, in my proposal user sees tags as more formal contract
17:38:04 <SumitNaiksatam> markmcclain enikanorov: can we potentially add tags later as a second iteration enhancement?
17:38:11 <markmcclain> enikanorov is correct, my proposal also exposes the set of API extensions available for a flavor (ie TLS, L7)
17:38:25 <markmcclain> SumitNaiksatam: yes
17:38:28 <enikanorov> extension list is questionable, imo
17:38:29 <mestery> SumitNaiksatam: +1
17:38:32 <SumitNaiksatam> markmcclain: ok cool
17:38:40 <enikanorov> why do coarse grained when we later move to fine grained?
17:38:47 <sbalukoff> I think it's less questionable than tags. :P
17:39:15 <enikanorov> the problem is that most drivers going to implement all extensions
17:39:33 <enikanorov> if two drivers implement SSL, but different cyphers
17:39:36 <enikanorov> ...
17:39:43 <enikanorov> that's where tags help
17:39:50 <dougwig> or the description.
17:39:52 <enikanorov> that just one example of many
17:39:53 <SumitNaiksatam> enikanorov: i think the claim is that coarse grain is currently simpler to achieve in Juno, but does not leave out the eventual path towards fine grained
17:40:02 <mestery> SumitNaiksatam: +1
17:40:04 <xgerman> +1
17:40:09 <SumitNaiksatam> markmcclain: is that an accurate assessment?
17:40:11 <enikanorov> considering implementation - it's not
17:40:14 <markmcclain> We can always formalize the contract over time
17:40:47 <enikanorov> also, each author sees implementation of his proposal to be simpler :)
17:40:55 <SumitNaiksatam> enikanorov: :-)
17:40:58 <garyduan> I also agree tag will be difficult to control
17:41:01 <enikanorov> the next thing is driver profiles
17:41:08 <mestery> enikanorov: human nature :)
17:41:13 <enikanorov> where metadata seem to be the same tags as in my proposal
17:41:31 <garyduan> but I'd like to understand more how metadata works
17:41:49 <garyduan> enikanorov: +1
17:41:52 <banix> enikanorov: would it be conceptually possible to think of profiles as a set of tags?
17:41:59 <markmcclain> so metadata is a dict of driver specific parameters passed at driver init time
17:42:03 <enikanorov> banix: yes, i think it's close
17:42:07 <mestery> banix: That's kind of what I was thinking as well
17:42:34 <enikanorov> so the problem for operator then that he needs to know driver specific details
17:42:35 <markmcclain> the metadata is really designed to toggle behavior in a driver to match the profile's description/sla
17:42:37 <banix> so can we agree on using the spec as teh vehicle for carrying the info, tags or metadata?
17:42:42 <mandeep> banix: That is what I was thinking as well
17:42:42 <sbalukoff> markmcclain: the idea being that drivers won't necessarily share the same specific parameters
17:42:46 <dougwig> it could be just a set of tags, or it could configure the driver slightly different for each flavor (simple example, you tell driver A to use backend hosts 1-2 for flavor X and hosts 3-10 for flavor Y).
17:42:50 <sbalukoff> even if they are implementing the same "feature"
17:43:03 <markmcclain> enikanorov: operators already know that info because most go through selection process when purchasing equipment
17:43:15 <markmcclain> sbalukoff: +1
17:43:26 <enikanorov> markmcclain: right, but metadata should really be bound to implementation, e.g. code
17:43:27 <markmcclain> dougwig: yes
17:43:30 <garyduan> markmcclain: metadata is created by admin,right?
17:43:40 <enikanorov> it's not purely ask-API-create-flavor
17:44:07 <enikanorov> so it really requires introspection into how it's done on the inside
17:44:17 <markmcclain> enikanorov: no it is configuration options or it could even be a pointer of where to read in config file
17:44:20 <enikanorov> you can't just pass anything
17:44:23 <markmcclain> garyduan: yes
17:44:35 <enikanorov> yep, the pointer of where to read is better
17:45:03 <sbalukoff> enikanorov: Why can't you just pass anything?
17:45:06 <markmcclain> enikanorov: the operator does not have to read the code, just understand the init options a vendor might offer
17:45:14 <enikanorov> but then it's just the same as to use tag from a flavor to do the same
17:45:22 <garyduan> markmcclain: does driver need to expose anything?
17:45:26 <mestery> markmcclain: This is similar to what they'd need to put in a config file when using the driver, right?
17:45:27 <enikanorov> sbalukoff: because it makes no sense for the driver
17:45:28 <markmcclain> ie pass ha=true at initialization time to ensure the backends creates pairs
17:45:52 <enikanorov> markmcclain: ok, that's a tag. and it's on a profile
17:46:00 <pgpus> whynot have two ways of specifiying service parameters tagOr metadata and point to a location where you can find key,vals or whateber minimum per service
17:46:01 <markmcclain> garyduan: no drivers should not need to be aware of flavors at this time
17:46:02 <sbalukoff> enikanorov: It does if the driver knows how to interpret the metadata passed to it. :P
17:46:04 <enikanorov> so why not to put it on Flavor so user see it, formally?
17:46:04 <markmcclain> mestery: yes
17:46:17 <markmcclain> pgpus: two ways = confusion
17:46:18 <ijw> I think the issue will be with tags that you have no formal description of what the tag means.  Clearly it means a function is supported, but how do you document what that means in practice?
17:46:34 <xgerman> ijw +1
17:46:36 <mestery> markmcclain: that makes sense to me.
17:46:38 <SumitNaiksatam> ijw: but that problem is not solved
17:46:51 <SumitNaiksatam> ijw: we now have the operator figure that out
17:47:00 <sbalukoff> ijw: +1
17:47:03 <ijw> It's not the operator that cares: it's the tenant.
17:47:13 <ijw> Extensions are self-documenting but per enikanorov's point they can't possibly catch nuances.
17:47:18 <enikanorov> tags are self-descriptive via their names
17:47:20 <markmcclain> enikanorov: it's not put on flavor because that exposes specific details of the implementation backend and may not be the same for multilple vendors
17:47:24 <s3wong> ijw: but operators are the one exposing metadata here, right?
17:47:43 <ijw> s3wong: yes, but wouldn't you like those tags to be cross-operator?
17:47:56 <garyduan> I'd agree operator should define the tag or metadata
17:48:00 <sbalukoff> s3wong: I don't think tenants get to see the metadata
17:48:01 <enikanorov> markmcclain: yes, that's why specific details are kept in driver's config
17:48:10 <markmcclain> ijw: standardizing the set of tags and letting everyone implement will take time
17:48:12 <sbalukoff> s3wong: So that's not actually exposed to the tenant.
17:48:13 <enikanorov> while on flavors only generic stuff like 'HA: True' is set
17:48:13 <ijw> I mean, surely the point here is 'I want a service X supporting Y' and whoever I ask it of I get a service that suits my purposes.
17:48:17 <garyduan> if he/she says the driver support L7, the drivers supports L7
17:48:27 <ijw> markmcclain: yup - I'm not really solving your problem, I'm trying to define it
17:48:28 <s3wong> ijw: if tags are exposed by drivers, then driver-tags would be cross-operator
17:48:33 <SumitNaiksatam> ok, can i summarize from a user facing API perspective, that the main difference between the two proposals is that in markmcclain’s proposal the meta-information is not exposed to the user, the operator configures that
17:48:40 <SumitNaiksatam> where as in enikanorov’s proposal
17:48:49 <SumitNaiksatam> it gets exposed as tags within the flavor
17:48:50 <ijw> s3wong: only if drivers agree what those tags mean, and that's the definition issue I'm referring ot.
17:49:04 <markmcclain> SumitNaiksatam: correct
17:49:07 <enikanorov> tags are implementation-agnostic definitions of the service
17:49:09 <SumitNaiksatam> and the user can choose the flavors based on the tags
17:49:16 <s3wong> sbalukoff: right, but operator would need to set metadata as part of what features drivers can expose, thus a manual process
17:49:20 <enikanorov> so no impl details sneak into flavor
17:49:31 <SumitNaiksatam> markmcclain: ok
17:49:47 <SumitNaiksatam> enikanorov markmcclain: hence my earlier suggestion, can we add tags as a second iteration enhancement
17:49:55 <s3wong> ijw: that has always been the question on enikanorov 's proposal - that we as community would have to define some common tags per service type
17:50:00 <SumitNaiksatam> enikanorov markmcclain: that way we can have the best of both proposals
17:50:08 <sbalukoff> s3wong: Defining what products an operator wants to offer is going to be a manual process in any case. ;)
17:50:12 <banix> SumitNaiksatam: right. so the difference is granulaity of what tenant sees; markmcclain shows well defined limitted number of extensions enikanorov shows fine grained properties
17:50:15 <ijw> s3wong: and if they're common tags, are they not attributes of the implementation?
17:50:16 <SumitNaiksatam> enikanorov markmcclain: we can start with somethin “simpler”
17:50:20 <markmcclain> SumitNaiksatam: right tags can be added later once we have standard set
17:50:33 <mestery> markmcclain SumitNaiksatam: +1
17:50:45 <SumitNaiksatam> enikanorov: does that seem reasonable?
17:50:47 <mestery> I think we need something simple for Juno at this stage.
17:50:50 <s3wong> ijw: yes, they would be
17:51:00 <enikanorov> i have a couple more questions
17:51:20 <enikanorov> one is do we really need driver entry poins in driver profile?
17:51:36 <enikanorov> i think current provider framework can be used for this purpose
17:51:37 <garyduan> enikanorov: same question here
17:51:41 <pgpus> every service needs to be managed by driver so why not just expose managment parameter and leave alone vwndor variations and just provide basic defalt services we have like FW,LB, VPN etc
17:51:44 <s3wong> sbalukoff: that's a fair point :-)
17:51:47 <SumitNaiksatam> enikanorov: one sec
17:51:56 <banix> enikanorov: let’s see if we can get an agreement on the API as SumitNaiksatam was suggesting
17:52:00 <SumitNaiksatam> lets all first have agreement on the tenant facing API
17:52:04 <SumitNaiksatam> banix: yeah
17:52:20 <SumitNaiksatam> we will get to the admin side of the API in a but
17:52:22 <SumitNaiksatam> bit
17:52:29 <mandeep> SumitNaiksatam: +1
17:52:32 <SumitNaiksatam> enikanorov markmcclain mestery: what say?
17:52:38 <enikanorov> well, not having tags on the flavor actually creates another question i was going to ask
17:52:51 <mestery> SumitNaiksatam: I think we're close on this front, so yes.
17:52:57 <markmcclain> I think from user perspective yes
17:53:28 <SumitNaiksatam> mestery markmcclain: cool
17:53:33 <SumitNaiksatam> enikanorov: whats your question
17:53:49 <enikanorov> do we really need to associate flavor with driver profile
17:54:01 <enikanorov> but it seems that if no tags - we have to do that
17:54:12 <enikanorov> but scheduling would not make much sense then
17:54:16 <markmcclain> enikanorov: right there has to be some kind of association layer
17:54:36 <banix> enikanorov: yes. need the association. will still have a list of possible choices
17:54:36 <enikanorov> because from flavor perspective there's no hint to use when choosing from associated profiles
17:54:39 <markmcclain> which enables an operator to make a flavor to several possible backend implementation options
17:54:49 <s3wong> enikanorov: it is a list of driver profile though, not really one to one mapping, so some sort of scheduling still needed, right?
17:55:01 <enikanorov> but what would be the criteria other than random choice?
17:55:05 <pgpus> Take the case of nova flavor did we really tie it to the drivers there?
17:55:05 <markmcclain> enikanorov: german has pointed out that I had left weight off as an initial metric of the list
17:55:09 <SumitNaiksatam> enikanorov: perhaps in the first iteration this will be limited without the hints/tags
17:55:16 * markmcclain pushed update with that
17:55:29 <SumitNaiksatam> markmcclain: do you agree ^^^?
17:55:30 <enikanorov> yep, i've seen update with weight, but...
17:55:38 <enikanorov> what does it solve?
17:55:51 <enikanorov> are you going to get max weight each time?
17:55:59 <markmcclain> s3wong: yes there is a selection call to bind flavor to a driver
17:56:00 <ijw> Right, so to be clear, the question is: a tenant has requirements that are met by several available service implementations: what should happen.  Is that right?
17:56:12 <enikanorov> weight is actually a hardcoded kind of tag
17:56:32 <markmcclain> enikanorov: enables operator control to say set a preference that backend A should be preferred over backend B
17:56:44 <enikanorov> *implementation A over B
17:56:46 <sbalukoff> enikanorov: Not the same kind of tag that's in your proposal
17:56:55 <enikanorov> sbalukoff: the same, indeed
17:57:07 <markmcclain> pgpus: nova can still bind because of extra data for flavor
17:57:09 <enikanorov> markmcclain: but how impl B is ever chosen?
17:57:18 <enikanorov> it it's weight is lower
17:57:42 <markmcclain> enikanorov: depends on selection algorithm
17:57:50 <markmcclain> I've also intentionally kept it simple too
17:58:05 <markmcclain> because I think that making a really good one is a great future BP :)
17:58:12 <enikanorov> well, that's important, because simplest is random choice
17:58:14 <garyduan> for example, round-robin in first release
17:58:22 <s3wong> enikanorov: where there is no more resources for backend A?
17:58:26 <ijw> No, actually simplest is offering the tenant the choice.
17:58:27 <enikanorov> weighting scheduler need to consider capacity or something
17:58:32 <enikanorov> s3wong: exactly
17:58:36 <sbalukoff> Or weighted round robin
17:58:43 <sbalukoff> Or weighted random choice.
17:58:44 <SumitNaiksatam> enikanorov: i think its okay to have limitations in the first release
17:58:57 <SumitNaiksatam> as long as we know what they are, and we have path towards evolution
17:59:03 <mandeep> ijw: The tenant should have no view of resources, only logical entities after they have been scheduled
17:59:08 <SumitNaiksatam> in this case the path is to to incoroporate tags
17:59:09 <mestery> Folks: Scheduling needs to be dirt simple for Juno or this won't land, that's the reality at this point.
17:59:12 <xgerman> mandeep +1
17:59:15 <pgpus> can you sggest what extra data for flvor is equivalent for neutron to tie it to neutron plugins? is it metadata/
17:59:16 <garyduan> if driver A has no resource, it can be feedback to plugin and select the next one
17:59:19 <mestery> I don't want to rathole on scheduling here either.
17:59:25 <enikanorov> i mean that's just a workarounds for the fact that 'naked flavor' is not a scheduling hint
17:59:40 <sbalukoff> mestery: Good point.
17:59:40 <mandeep> mestery: +1
17:59:47 <markmcclain> mestery: +1 scheduling is for Paris :)
17:59:50 <mestery> markmcclain: :P
17:59:59 <SumitNaiksatam> ok lets get an agreement here
18:00:02 <SumitNaiksatam> hang folks
18:00:07 <SumitNaiksatam> * hang on
18:00:14 <SumitNaiksatam> i think its okay to have limitations in the first release
18:00:14 <mestery> SumitNaiksatam: Whew, had me worried there ;)
18:00:21 <enikanorov> as for something simple - I remember avishay's patch where he enabled driver to choose it's configuration based on provider name
18:00:24 <SumitNaiksatam> as long as we know what they are, and we have path towards evolution
18:00:36 <enikanorov> that's actually very close to what is called driver profile
18:00:37 <mestery> SumitNaiksatam: +1
18:00:38 <SumitNaiksatam> in this case the path is to to incoroporate tags
18:00:46 <SumitNaiksatam> as a future iteration
18:00:52 <SumitNaiksatam> enikanorov markmcclain: can we agree?
18:01:01 <SumitNaiksatam> this is in the context of the user/tenant facing API
18:01:17 <markmcclain> SumitNaiksatam: +1
18:01:28 <SumitNaiksatam> markmcclain: great, enikanorov?
18:01:29 <enikanorov> yep, as simple first step we may just introduce flavors layer on top of providers
18:01:34 <pgpus> you service profile's path and that service prpofile will have tags?
18:01:35 <SumitNaiksatam> enikanorov: i know this is not ideal
18:01:42 <SumitNaiksatam> enikanorov markmcclain: nice
18:01:45 <enikanorov> may be with just 1:1 and no scheduling and such
18:01:55 <SumitNaiksatam> enikanorov: nice
18:01:59 <enikanorov> markmcclain: how does it sounds?
18:02:12 <enikanorov> then we could flush out what we really want from driver profiles
18:02:31 <markmcclain> enikanorov: operators need more than 1:1
18:02:36 <enikanorov> markmcclain: sure
18:02:50 <sbalukoff> markmcclain: +1
18:02:54 <enikanorov> but at least we'll get user-facing api more or less stable
18:03:08 <enikanorov> and then extend this with other more advanced features
18:03:36 <enikanorov> in terms of implementation that seems to be the simplest. plus migration is also simple, as well as operators workflow
18:04:08 <markmcclain> so service profiles are must
18:04:29 <enikanorov> that's solvable with providers
18:04:30 <markmcclain> because the mutli-vendor requirement why we started the who flavor discussion in the first place
18:05:06 <garyduan> I have questions about profile, but I want to wait until we get there :-)
18:05:37 <enikanorov> markmcclain: so i agree, i'm just saying someone already impemented the idea very close to driver profiles
18:05:51 <enikanorov> that coudl be reused and merged with flavors
18:05:52 <pgpus> OK lets take a sample service profile for existing FW,LB,VPN as see if this makes sense
18:05:59 <dougwig> enikanorov: sounds like you're agreeing about profiles, just not where to put them?
18:06:19 <enikanorov> markmcclain: so we both get rid of provider attribute on the service instance, plus not too much changing the existing flow
18:06:59 <enikanorov> dougwig: i'm not opposed to profiles, just honestly it is possible right now with very small changes in the code
18:07:04 <pgpus> What should a fw profile conatin like neutron firewall-list
18:07:04 <pgpus> neutron firewall-policy-list
18:07:04 <pgpus> neutron firewall-rule-list
18:07:22 <enikanorov> that's however has another issues listed in markmcclain's proposal in the beginning, but with flavor layer it is solvable
18:07:49 <garyduan> pgpus: firewall itself is the service instance
18:08:11 <banix> sounds like we have reached an agreement. right?
18:08:30 <pgpus> will flavor and proivder type be able to express these in profiles in terms of some unit of measure to say like weight vwe discussed for user to undertsand which profile they pickup?
18:08:48 <mestery> banix: Seems like it.
18:08:57 <markmcclain> I think so
18:09:04 <markmcclain> the one contention seems to be profiles
18:09:21 <markmcclain> which are a evolved form of providers
18:09:27 <enikanorov> markmcclain: I'm for using current workflow with keeping it in conf
18:09:42 <enikanorov> at least for now
18:10:03 <enikanorov> with flavors we are able to solve issues of providers
18:10:05 <sbalukoff> I think there a benefits to keeping providers in the DB and not in conf.
18:10:11 <sbalukoff> Er... not in conf files.
18:10:17 <garyduan> enikanorov: are you saying 1:1 mapping between profile and driver?
18:10:35 <enikanorov> profile:driver is N:1
18:10:42 <enikanorov> driver may have multiple profiles
18:10:54 <pgpus> we will have to re-invent like ml2 an mlProfile
18:11:03 <garyduan> that my question,
18:11:31 <garyduan> Mark's spec says, metadata can be used by driver to behave differently
18:11:35 <mandeep> enikanorov: it is more likely n:m - same profile may be provided by multiple drivers as well
18:11:52 <SumitNaiksatam> mandeep: +1
18:11:58 <markmcclain> enikanorov: my only concern about keeping current provider conf is there's no operator control
18:12:04 <sbalukoff> mandeep: Not if metadata is driver-specific
18:12:09 <enikanorov> mandeep: that's more complex. not sure that would be easy with storing profiles in config
18:12:16 <SumitNaiksatam> sbalukoff: that is just a special case
18:12:25 <enikanorov> markmcclain: the control of what?
18:12:27 <mandeep> SumitNaiksatam: exactly
18:12:30 <s3wong> mandeep: oh really? if so, how is metadata passed - because that needs to be driver specific?
18:12:32 <SumitNaiksatam> sbalukoff: mandeep’s suggestion for n:m includes that
18:12:36 <markmcclain> which provider is selected
18:12:38 <SumitNaiksatam> sbalukoff: n or m is 1!
18:12:52 <enikanorov> markmcclain: how's it different from your proposal besides the fact that it is configured in conf, not by API?
18:13:14 <markmcclain> the original reason we started with flavors months ago was the operator need for multi-vendor/multi-driver for same SLA
18:13:22 <SumitNaiksatam> folks, sorry for interrupting
18:13:33 <SumitNaiksatam> have we moved on from the user/tenant facing API discussion?
18:13:38 <sbalukoff> SumitNaiksatam: No, what I mean is, if the metadata in the profile is only meant to be interpreted by one driver, then that profile can only apply to one driver.  Are y'all suggesting the metadata might be not driver-specific?
18:13:45 <markmcclain> SumitNaiksatam: yes
18:13:46 <SumitNaiksatam> sorry for repeating this over and over again
18:13:55 <enikanorov> markmcclain: as we discussed, flavors associated with providers, which ae actually a driver profile
18:13:56 <markmcclain> so I think we have agreement on user API
18:13:59 <SumitNaiksatam> markmcclain: ok cool
18:14:05 <s3wong> sbalukoff: that was my question above as well... to me it seems n:1
18:14:07 <SumitNaiksatam> mestery: can we summarize the agreement?
18:14:12 <mandeep> s3wong: I expect that common profiles (say providing cookie rewriting), will be implemented by multiple backends. That is whjat allows you to reschedule a tenant to a new backend transparently
18:14:13 <enikanorov> SumitNaiksatam: yep, i think so as well
18:14:18 <banix> SumitNaiksatam: i think the only remaining question is driver in profile or not issue
18:14:25 <SumitNaiksatam> enikanorov markmcclain: perhaps you can summarize
18:14:34 <mestery> SumitNaiksatam: Yes, lets have enikanorov markmcclain summarize :)
18:14:52 <markmcclain> so there's agreement that the user will select a flavor
18:15:01 <enikanorov> that's for sure :)
18:15:05 <SumitNaiksatam> :-)
18:15:12 <markmcclain> flavor definition will include list of API extensions
18:15:33 <markmcclain> the API extensions will be used to activate logic in teh server for configuring the logical model
18:15:46 <enikanorov> not sure we need that...
18:15:56 <SumitNaiksatam> markmcclain: the list of API extensions is in a user friendly form?
18:16:05 <enikanorov> if API extension is not used for scheduling, then why have it?
18:16:12 <markmcclain> SumitNaiksatam: about as friendly as our current /extensions endpoint :)
18:16:39 <markmcclain> enikanorov: not all flavors will implement every API extension
18:16:44 <SumitNaiksatam> markmcclain: ok may be i misunderstood that part, but i can go back to the spec
18:17:03 <enikanorov> markmcclain: right, admin will need to write this in the description
18:17:19 <garyduan> markmcclain: extension list seems informational to me
18:17:31 <markmcclain> enikanorov, garyduan: it is
18:17:31 <enikanorov> that's the same as with API aspects
18:17:46 <markmcclain> mainly because the extensions should be defined in our API spec
18:17:47 <garyduan> markmcclain: OK
18:18:05 <enikanorov> markmcclain: also, the problem i see with this is the usage
18:18:18 <markmcclain> ie the user knows that if TLS is enable these extra child resources are available for a service
18:18:32 <markmcclain> enikanorov: what is the usage issue?
18:18:42 <enikanorov> markmcclain: so say instance ID1 doesn't suport L7. user calls L7 on instance with ID1, API layer need to goo to DB and find out which extensions are enabled
18:18:59 <enikanorov> to decide whether to forward rest call
18:19:04 <enikanorov> or to reply with 404 or 400
18:19:36 <enikanorov> if that's what you're proposing, then it's not easy to do. but if we're not doing this, then we don't need extension list as a separate attribute
18:19:45 <markmcclain> enikanorov: yep for service extensions that will be required
18:20:02 <markmcclain> not every backend may implement an extension
18:20:14 <enikanorov> yep, just raise unimplemented
18:20:17 <markmcclain> also if we don't do this how do vendor differentiate?
18:20:41 <markmcclain> enikanorov: except that as an operator
18:20:43 <dougwig> how is a user going to call L7 on something that doesn't support it unless the operator has misconfigured their flavors/profiles?
18:20:44 <enikanorov> they differentiate. on user-facing side, flavor descriptions are different
18:21:10 <enikanorov> dougwig: well, user just calls... it should get reasonable error
18:21:22 <enikanorov> 'not implemented' seems reasonable to me
18:22:00 <markmcclain> enikanorov: an operator may want to make a driver that offers more features to a flavor that offers no features
18:22:04 <markmcclain> s/no/few/
18:22:13 <enikanorov> i'm saying that extension list as an attribute is not extendible, if we want to declare API aspects in the future
18:22:27 <sbalukoff> enikanorov: That's true... but I guess I'm still not following why markmcclain's proposal wouldn't be able to do that? What is the usage problem here?
18:22:28 <markmcclain> enikanorov: it is extensible
18:22:58 <mandeep> markmcclain: As a generic neutron question, we have the same issue of exposing APIs exposed by a driver to the tenant (say for ML2), so should we be exposing API extensions from drivers in a generic way, not in a service flavor specific way?
18:23:00 <sbalukoff> "That's true" was meant to apply to the 'not implemented' error comment you said above.
18:23:24 <enikanorov> i guess that's not about APIs exposed by drivers
18:23:33 <enikanorov> it's about core service API that driver may not support
18:23:39 <markmcclain> the operator ensures the deployed backends have support and then add extension to the list if they choose
18:24:01 <enikanorov> anyway, flavor-based discpatching seems the complexity we would like to avoid
18:24:06 <markmcclain> enikanorov: if we keep the core service API small then everyone should be able to support it
18:24:29 <markmcclain> enikanorov: flavor based dispatching is not that difficult of a problem
18:24:54 <enikanorov> i'd say it's not a step-1 task
18:25:00 <markmcclain> mainly because the mechanics of dispatching usually involve retrieving teh flavor info
18:25:34 <pgpus> can we describe falvor info for one service say fw to understand heer?
18:26:01 <enikanorov> firewall has no extensions, i guess
18:26:10 <enikanorov> garyduan: is that so?
18:26:12 <markmcclain> pgpus: mind if I talk lbaas example case?
18:26:13 <pgpus> OK lets take LB
18:26:15 <garyduan> no ext.
18:26:23 <enikanorov> so is vpn, i guess
18:26:26 <sbalukoff> Well, there's also the problem of an extension "mostly" being supported:  For example, if a particular implementation can support most of L7 in LBaaS, but there are one of two things it doesn't support within the L7 functionality, can it report that a given configuration is not implemented?
18:27:17 <markmcclain> sbalukoff: right
18:27:58 <enikanorov> sbalukoff: that may make sense for particular not supported attr. like unsupported cypher of certificate or something
18:28:03 <pgpus> pool, member, protocol say http supported but not https does it make sense?
18:28:17 <mestery> Folks, where are we at here? We're at an hour, and I'd like to ensure we wrap this up at some point. :)
18:28:17 <sbalukoff> enikanorov: Yes
18:28:28 <enikanorov> pgpus: there's not way with extension list to say 'i don't support https protocol'
18:28:38 <pgpus> OK so flavor can be L7LBsimplehttp types
18:29:00 <sbalukoff> mestery: Sorry for throwing a monkey-wrench into the clockwork. :P
18:29:05 <enikanorov> pgpus: that goes down to a vervose description
18:29:21 <mestery> We can't sit here all day discussing this, I'm sure most of us have backlogs that are huge at this point. :)
18:29:40 <enikanorov> that's my point, extension list is not helping much, not to say dispatching based on it is not necessary
18:29:42 <mestery> So moving forward, is there anything else that isn't agreed on? I lost track to be honest. :)
18:29:54 <pgpus> OK I am trying to understand flavor in terms of am I drinking a Darjeeling tea or a colombian cofee
18:29:58 <markmcclain> how to map flavor to driver is the point of contention
18:30:00 <enikanorov> mestery: that's still about user api
18:30:01 <SumitNaiksatam> the last i remember, markmcclain was summarizing what we agreed on
18:30:01 <LouisF> can we get a merged  proposal with examples to review?
18:30:05 <markmcclain> but I really don't think it is that far off
18:30:10 <s3wong> mestery: I think we are still on APIs - since we have disagreement on extensions
18:30:19 <enikanorov> markmcclain: let's do it the way you proposed
18:30:28 <enikanorov> at least for now
18:30:34 <enikanorov> it's hidden from user anyway
18:30:52 <markmcclain> enikanorov: right and then we can add advance capabilities as follow up work
18:31:07 <mestery> markmcclain: +1
18:31:11 <mestery> enikanorov: +1
18:31:12 <sbalukoff> +1
18:31:12 <markmcclain> this will also break the dependency bottleneck the adv services are experiencing
18:31:22 <mestery> markmcclain: HUGE +1
18:31:24 <sbalukoff> Yes!
18:31:27 <garyduan> one more question
18:31:32 <sbalukoff> Damn.
18:31:35 <sbalukoff> ;)
18:31:37 <garyduan> meta data in profile
18:31:43 <banix> so the optimism of the other day was well founded :)
18:31:46 <sbalukoff> It's drier specific!
18:31:58 <sbalukoff> driver
18:31:59 <garyduan> how is it used to make driver work differently?
18:32:12 <markmcclain> garyduan: it's a vendor choice
18:32:27 <markmcclain> a vendor could create a driver that require no additional metadata
18:32:41 <markmcclain> so the operator would leave the field blank
18:32:49 <sbalukoff> That is, vendor defines what metadata should look like and what the driver will understand, operator decides which metadata to put in there to enable which features.
18:32:51 * markmcclain envisions there will be vendors who do exactly that
18:33:06 <garyduan> vendor defines what meta data should look like ?
18:33:09 <garyduan> where?
18:33:14 <sbalukoff> And thus, vendors can differentiate, and operators control their product offerings.
18:33:23 <markmcclain> garyduan: in their docs on how to deploy their solution
18:33:29 <banix> mestery: i think converging to one spec as LouisF suggested would be great
18:33:42 <garyduan> Ok. It's an external process.
18:33:48 <markmcclain> garyduan: yes
18:33:49 <sbalukoff> Yes!
18:33:52 <garyduan> I agree
18:34:03 <SumitNaiksatam> banix: i agree, one spec would be good
18:34:11 <garyduan> then, multiple driver instances?
18:34:19 <mandeep> banix: +1
18:34:20 <s3wong> garyduan: yeah, we talked about that a bit earlier too (as I had with sbalukoff) - that metadata is a manual process for operators
18:34:48 <garyduan> Do we do dynamic loading?
18:34:53 <mestery> markmcclain enikanorov: We need to move to one spec and continue the discussion there.
18:34:54 <garyduan> of vendor driver?
18:35:03 <mestery> At this point, I'm going to end this meeting (or pass chair to someone else).
18:35:08 <markmcclain> garyduan: yes dynamic loading via entrypoint
18:35:10 <mestery> enikanorov markmcclain: ^^^ Sound ok?
18:35:14 <markmcclain> mestery: I've got a hard stop too
18:35:25 <mestery> OK, lets move to one spec and continue the conversation there.
18:35:27 <sbalukoff> Thanks, y'all!
18:35:46 <mestery> I think at this point we're at "implementation detaiuls" anyways, and we coudl all stay here the rset of the day talking it feels like. :)
18:35:51 <SumitNaiksatam> enikanorov markmcclain: thanks for indulging in this discussion
18:35:54 <mestery> Thanks for joining folks!
18:35:54 <s3wong> SumitNaiksatam: so we can skip talking about flavor during next week's adv service meeting? :-)
18:35:56 <mestery> sbalukoff: +1
18:35:59 <enikanorov> markmcclain: salv-orlando would not be happy to do dynamic loading. at least he was no-no about that
18:36:02 <SumitNaiksatam> s3wong: :-)
18:36:12 <mestery> #endmeeting