Open Stack

Hi Stephen,

Thanks for your exhaustive comments!
Some more replies from me inline.

Have a good evening,
Salvatore


On 16 July 2014 00:05, Stephen Balukoff <sbalukoff at bluebox.net> wrote:

> Hi Salvatore and Eugene,
>
> Responses inline:
>
> On Tue, Jul 15, 2014 at 12:59 PM, Salvatore Orlando <sorlando at nicira.com>
> wrote:
>
>> I think I've provided some examples in the review.
>>
>
> I was hoping for specific examples. The discussion I've seen so far has
> been vague enough that it's difficult to see what people mean. It's also
> possible you gave specific examples but these were buried in comments on
> previous revisions (one of my biggest gripes with the way Gerrit works. :P
> ) Could you please give a specific example of what you mean, as well as how
> it simplifies the user experience?
>
> However, the point is mostly to simplify usage from a user perspective -
>> allowing consumers of the neutron API to use the same flavour object for
>> multiple services.
>>
>
> Actually, I would argue the having a single flavor valid for several
> different services complicates the user experience (and vastly complicates
> the operator experience). This is because:
>
> * Flavors are how Operators will provide different service levels, or
> different feature sets for similar kinds of service. Users interested in
> paying for those services are likely to be more confused if a single flavor
> lists features for several different kinds of service.
> * Billing becomes more incomprehensible when the same flavor is used for
> multiple kinds of service. Users and Operators should not expect to pay the
> same rate for a "Gold" FWaaS instance and "Gold" VPNaaS instance, so why
> complicate things by putting them under the same flavor?
> * Because of the above concerns, it's likely that Operators will only
> deploy service profiles in a flavor for a single type of service anyway.
> But from the user's perspective, it's not apparent when looking at the list
> of flavors, which are valid for which kinds of service. What if a user
> tries to deploy a LBaaS service using a flavor that only has FWaaS service
> profiles associated with it? Presumably, the system must respond with an
> error indicating that no valid service profiles could be found for that
> service in that flavor. But this isn't very helpful to the user and is
> likely to lead to increased support load for the Operator who will need to
> explain this.
> * A single-service flavor is going to be inherently easier to understand
> than a multi-service flavor.
> * Single-service flavors do not preclude the ability for vendors to have
> multi-purpose appliances serve multiple roles in an OpenStack cloud.
>

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!



>
>
>> 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!


>
>
>> 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.


> * 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.


> * 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?



>
> 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.

>
> 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 <enikanorov at 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.

>
>
>> 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.


>
>
>
>> 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.


>
>  Thanks,
> Stephen
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/b8734932/attachment.html>