Folks, Initial implementation is here: https://review.openstack.org/#/c/105982/ It's pretty much complete (in terms of code parts) but may require some adjustments and of course fixes.
I'm working on the client to test this end-to-end. Thanks, Eugene. P.S. Almost got it under 1k lines! On Thu, Jul 17, 2014 at 7:36 AM, Stephen Balukoff <sbaluk...@bluebox.net> wrote: > Hi Salvatore! > > Thank you for reading through my book-length e-mail and responding to all > my points! > > Unfortunately, I have more responses for you, inline: > > On Wed, Jul 16, 2014 at 4:22 PM, Salvatore Orlando <sorla...@nicira.com> > wrote: > >> Hi Stephen, >> >> Thanks for your exhaustive comments! >> > > I'm always happy to exhaust others with my comments. ;) > > >> I think your points are true and valid for most cloud operators; besides >> the first all the point you provided indeed pertain operators and vendors. >> However you can't prove, I think, the opposite - that is to say that no >> cloud operator will find multi-service flavors useful. At the end of the >> day Openstack is always about choice - in this case the choice of having >> flavours spanning services or flavours limited to a single service. >> This discussion however will just end up slowly drifting into the realm >> of the theoretical and hypotethical and therefore won't bring anything good >> to our cause. Who know, in a few post we might just end up calling godwin's >> law! >> > > That's certainly true. But would you be willing to agree that both the > model and logic behind single-service_type flavors is likely to be simpler > to implement, troubleshoot, and maintain than multi-service_type flavors? > > If you agree, then I would say: Let's go with single-service_type flavors > for now so that we can actually get an implementation done by Juno (and > thus free up development that is currently being blocked by lack of > flavors), and leave the more complicated multi-service_type flavors for > some later date when there's a more obvious need for them. > > For what it's worth, I'm not against multi-service_type flavors if someone > can come up with a good usage scenario that is best solved using the same. > But I think it's more complication than we want or need right now, and > shooting for it now is likely to ensure we wouldn't get flavors in time for > Juno. > > > >> There are other considerations which could be made, but since they're >>>> dependent on features which do not yet exist (NFV, service insertion, >>>> chaining and steering) I think there is no point in arguing over it. >>>> >>> >>> Agreed. Though, I don't think single-service flavors paint us into a >>> corner here at all. Again, things get complicated enough when it comes to >>> service insertion, chaining, steering, etc. that what we'll really need at >>> that point is actual orchestration. Flavors alone will not solve these >>> problems, and orchestration can work with many single-service flavors to >>> provide the illusion of multi-service flavors. >>> >> >> Don't take it the wrong way - but this is what I mean by "theoretical and >> hypothetical". I agree with you. I think that's totally possible. But there >> are so many pieces which are yet missing from the puzzle that this >> discussion is probably worthless. Anyway, I started it, and I'm the one to >> be punished for it! >> > > Hah! Indeed. Ok, I'll stop speculating down that path for now, eh. ;) > > >> In conclusion I think the idea makes sense, and is a minor twist in the >>>> current design which should not either make the feature too complex neither >>>> prevent any other use case for which the flavours are being conceived. For >>>> the very same reason however, it is worth noting that this is surely not an >>>> aspect which will cause me or somebody else to put a veto on this work >>>> item. >>>> >>> >>> I don't think this is a minor twist in the current design, actually: >>> * We'll have to deal with cases like the above where no valid service >>> profiles can be found for a given kind of flavor (which we can avoid >>> entirely if a flavor can have service profiles valid for only one kind of >>> service). >>> >> >> Point taken, but does not require a major change to the design since a >> service flavour like this should probably be caught by a validation >> routine. Still you'd need more pervasive validation in different points of >> the API. >> > > ... which sounds like significantly more complication to me. But at this > point, we're arguing over what a "minor twist" is, which is not likely to > lead to anywhere useful... > > >> * When and if tags/capabilities/extensions get introduced, we would >>> need to provide an additional capabilities list on the service profiles in >>> order to be able to select which service profiles provide the capabilities >>> requested. >>> >> >> Might be... but I don't see how that would be worse with multiple service >> types, especially if profiles are grouped by type. >> > > Presumably, with single-service_type flavors, all service profiles > associated with the flavor should be capable of providing all the features > advertised as being provided by the flavor (first in the 'description' and > possibly later programmatically via an extensions list). This means we > don't have to check to see whether a service profile associated with the > flavor can provide for all the extensions advertised in the flavor > description because by creating the association, the operator is implying > it can. > > >> * The above point makes things much more complicated when it comes to >>> scheduling algorithms for choosing which service profile to use when >>> multiple can meet the need for a given service. What does 'weight' mean if >>> all but two low-weight service profiles get eliminated as not suitable? >>> >> >> I'm really not following you. Sorry about my ignorance. Isn't this >> something you would need to address even in the case you have a flavour >> with multiple service profiles all for the same service type, as the spec >> currently mandates? >> > > No, I'm probably simply not making my point clearly. What I mean is > probably best illustrated by an example: > > Suppose I'm using service profile weights in my scheduling algorithm to > determine which service profile will get used when a user requests an > instance of an advanced service using the flavor framework. > > For a single-service_type flavor, let's say I have the following service > profiles: > > "Profile A" => weight 30 > "Profile B" => weight 50 > "Profile C" => weight 20 > > I don't have to mention the type of service in the above profiles because > it's implied by the service_type attribute of the flavor. Given the above > weights, it's clear to see that if a user requests a service instance, > there's a 50% chance it'll be a "Profile B" instance. Then, later, when the > Operator looks at the relative split of services as deployed by users, she > should expect to see a "30 / 50 / 20" percentage split. A "5 / 90 / 5" > split would be a solid indication that "something is wrong" that the > operator needs to look into. (Maybe "Profile A" deployments fail silently > 75% of the time, or maybe users have figured out that they hate "profile C" > instance types and keep deploying / destroying instances until they land on > a "profile B" instance.) > > Now, doing the same exercise for a multi-service_type flavor, let's say we > have the following service profiles: > > "Profile X" => service_types = [LBaaS, VPNaaS], weight = 30 > "Profile Y" => service_types = [LBaaS, VPNaaS], weight = 50 > "Profile Z" => service_types = [FWaaS, VPNaaS], weight = 20 > > Given the above: > * If a user tries to deploy an LBaaS instance, it's less obvious that the > instance will have a 62.5% chance of ending up on Profile Y, and a 37.5% > chance of ending up on Profile X. > * It's also less obvious that even though "Profile Z" has a low weight, if > the user wants a FWaaS instance, there's a 100% chance it'll end up on > Profile Z. > * From the Operator's perspective, it's no longer obvious that a "5 / 90 / > 5" split of services on this flavor indicates "something is wrong." In > fact, it's much more difficult to determine this. > > Does this example make sense to you? > > >> >> >> >>> >>> Another aspect to consider is how the flavours will work when the >>>> advanced service type they refer to is not consumable through the neutron >>>> API, which would be the case with an independent load balancing API >>>> endpoint. But this is probably another story. >>>> >>> >>> As far as I'm aware, flavors will only ever apply to advanced services >>> consumable through the Neutron API. If this weren't the case, what's the >>> point of having a flavor describing the service at all? If you're talking >>> about Octavia here-- well, our plan is to have Octavia essentially be an >>> other load balancer vendor, interfaced through a driver in the Neutron >>> LBaaS extension. (This is also why so many developers interested in seeing >>> Octavia come to light are spending all their time right now improving >>> Neutron LBaaS-- we want it to be feature-rich enough in Juno for us to be >>> able to actually do interesting things with Octavia without having to >>> resort to building our own independent API endpoint if at all possible.) If >>> Octavia ever splits off and has its own API endpoint, it would need to >>> implement something like the Neutron flavor framework itself-- and in this >>> case, what we decide to do there should not affect the Neutron flavor >>> framework at all (or visa versa). >>> >> >> This is a bit off topic, and again I am at fault for driving you there. >> The thing is that I've spoken with several people, and they've all got >> different opinions regarding where Load Balancing should go in the medium >> term. These range from a completely standalone service to what you've just >> mentioned here. >> My opinion, which is probably irrelevant, is that I'm supportive of the >> load balancing effort evolving independently from the rest of neutron and >> staying loosely coupled with it. However, I believe that there should a >> single API endpoint for all the network services. In other words a single >> neutron API offering all service to consumer and different standalone >> services providing those service at control/data plane. >> > > Eh-- let's cross that bridge when we get there, eh. I think it will become > more obvious as projects like Octavia gain maturity whether they should be > split off and become completely independent, be loosely coupled, or simply > remain a "vendor" of Neutron LBaaS. :) How "flavors" get handled in these > scenarios is part of that discussion-- but that discussion probably isn't > relevant right now. > > >> >>> If you want to provide the illusion of two different top-level services >>> / API endpoints having the same "flavor," then I would say, "that's what >>> orchestration is for." >>> >> >> Totally agree on this point. >> >>> >>> On Tue, Jul 15, 2014 at 2:07 PM, Eugene Nikanorov < >>> enikano...@mirantis.com> wrote: >>> >>> Hi Stephen, >>>> >>>> So, as was discussed, existing proposal has some aspects which better >>>> to be postponed, like extension list on the flavor (instead of tags). >>>> >>> >>> Agreed-- I think we need to more fully flesh out how extension list / >>> tags should work here before we implement it. But this doesn't prevent us >>> from rolling forward with a "version 1" of flavors so that we can start to >>> use some of the benefits of having flavors (like the ability to use >>> multiple service profiles with a single driver/provider, or multiple >>> service profiles for a single kind of service). >>> >>> >>>> Particularly that idea has several drawbacks: >>>> - it makes public API inflexible >>>> - turning features on/off is not what flavors should be doing, it's a >>>> task for policy framework and not flavors >>>> - flavor-based rest call dispatching is quite complex solution giving >>>> no benefits for service plugins >>>> >>> >>> I'm confused as to what you mean by "that idea" here. Are you taking >>> about the "extension list"? If this is the case, I agree that that aspect >>> needs to be refined and should probably be postponed if possible. >>> >> >> I was under the impression that the extension list was a set of neutron >> extensions supported by all the service providers in the flavour. This >> could probably be enforced as an API level constraint. >> > > I don't think there's much agreement on what the extension list should > actually be at the present time (honestly, it seem close enough to the > 'tags' proposal in Eugene's original spec that I keep mistaking one for the > other). This is one of the reasons I'm in favor of deferring that > discussion until version 2 of flavors, and simply working with the > free-form 'description' field for now which is informational but shouldn't > be considered programmatically consumable. > > >> >>> >>>> While this is not explicitly written in proposal - that's what implied >>>> there. >>>> I think that one is a major blocker of the proposal right now, it >>>> deserves future discussion and not essential to the problem flavors are >>>> supposed to solve. >>>> >>> >>> Yes, I think there are many benefits we can get out of the flavor >>> framework without having to have an extensions list / tags at this >>> revision. But I'm curious: Did we ever define what we were actually trying >>> to solve with flavors? Maybe that's the reason the discussion on this has >>> been all of the place: People are probably making assumptions about the >>> problem we're trying to solve and we need to get on the same page about >>> this. >>> >> >> That is what I've been saying for over a year. Whatever you call it >> "service type", "service provider" or "flavour" it appears that's >> impossible to find two persons who think about it in the same way. >> > > Haha! Great! Well, when it comes to proposals like this, I prefer to think > of them in terms of "what problem are we trying to solve" and then limiting > scope so we can actually produce something before the cold death of the > universe. > > So! With that in mind, I agree with what Eugene said on this: > > The original problem has several aspects: > 1) providing users with some information about what service implementation > they get (capabilities) > 2) providing users with ability to specify (choose, actually) some > implementation details that don't relate to a logical configuration > (capacity, insertion mode, HA mode, resiliency, security standards, etc) > 3) providing operators a way to setup different modes of one driver > 4) providing operators to seamlessly change drivers backing up existing > logical configurations (now it's not so easy to do because logical config > is tightly coupled with provider/driver) > > The proposal we're discussing right is mostly covering points (2), (3) and > (4) which is already a good thing. > So for now I'd propose to put 'information about service implementation' > in the description to cover (1) > > > If there are problems people are trying to solve with flavors that are not > among the above 4 points, I would suggest that these either become a part > of a later revision of flavors, or simply get discussed as a new entity > entirely (depending on what people are after). > > Anyone have objections to this? > > (Sorry for the abruptness on my part on this: We really need to get > flavors into Juno because we have features of LBaaS which are probably > going to depend on it. I realize I've been dominating this discussion > because of the time pressure here, but I really am interested in learning > whether flavors as proposed in the spec right now provide useful > functionality to the other Neutron Advanced Services, other than LBaaS.) > > > >> Other than that, I personally don't have much disagreements on the >>>> proposal. >>>> >>>> The question about service type on the flavor is minor IMO. We can >>>> allow it to be NULL, which would mean multiservice flavor. >>>> However, multiservice flavors may put some minor requirements to driver >>>> API (that's mainly because of how flavor plugin interacts with service >>>> plugins) >>>> >>> >>> Yes, I think single-service flavors is almost certainly going to be a >>> simpler thing to implement, too-- and if we want to get flavors in for Juno >>> (which I know *we* really want to do), then I think reducing the complexity >>> here is probably a good idea, at least for the first revision. >>> >> >> Yes. At the end of the day I have no problem with going with single >> service flavours. Mostly because it will be already a win if we manage to >> bind this framework to a single advanced service in the juno release cycle. >> > > Yay! That's the goal: Get this into Juno! And it seems to me like a good > first step toward multi-service_type flavors, if we as a group decide > that's where we want to go. > > Thanks, > Stephen > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
