Open Stack

On Fri, 2014-02-28 at 10:19 +0400, Eugene Nikanorov wrote:
>         
>         1) I'm not entirely sure that a provider attribute is even
>         necessary to
>         expose in any API. What is important is for a scheduler to
>         know which
>         drivers are capable of servicing a set of attributes that are
>         grouped
>         into a "flavor".
> Well, provider becomes read-only attribute and for admin only (jsut to
> see which driver actually handles the resources), not too much of API
> visibility. 

I'd very much prefer to keep the provider/driver name out of the public
API entirely. I don't see how it is needed.

>         2) I would love to see the use of the term "flavor" banished
>         from
>         OpenStack APIs. Nova has moved from flavors to "instance
>         types", which
>         clearly describes what the thing is, without the odd
>         connotations that
>         the word "flavor" has in different languages (not to mention
>         the fact
>         that flavor is spelled flavour in non-American English).
>         
>         How about using the term "load balancer type", "VPN type", and
>         "firewall
>         type" instead?
> Oh... I don't have strong opinion on the name of the term.
> "Flavor" was used several time in our discussions and is short.
> "*Instance* Type" however seems also fine. Another option is probably
> a "Service Offering".

OK.

>         3) I don't believe the FlavorType (public or internal)
>         attribute of the
>         flavor is useful. We want to get away from having any
>         vendor-specific
>         attributes or objects in the APIs (yes, even if they are
>         "hidden" from
>         the normal user). See point #1 for more about this. A
>         scheduler should
>         be able to match a driver to a request simply by matching the
>         set of
>         required capabilities in the requested flavor (load balancer
>         type) to
>         the set of capabilities advertised by the driver.
> ServiceType you mean? If you're talking about ServiceType then it
> mostly for the user to filter flavors (I'm using short term for now)
> by service type. Say, when user wants to create new loadbalancer,
> horizon will show only flavors related to the lb.
> That could be also solved by having different names live you suggested
> above: "Lb type", "VPN type", etc. 
> On other hand that would be similar objects with different names -
> does it make much sense?

No, I wasn't referring to ServiceType. I was referring to "FlavorType"
-- public or internal -- in your diagram. I don't believe this is
necessary, frankly.

> I'm not sure what you think 'vendor-specific' attributes are, I don't
> remember to have plan of exposing any kind of vendor-related
> parameters. The parameters that flavor represents are capabilities of
> the service in terms that user care about: latency, throughput,
> topology, technology, etc.

Yes, agreed. ++

>         4) A minor point... I think it would be fine to group the
>         various
>         "types" into a single database table behind the scenes (like
>         you have in
>         the Object model section). However, I think it is useful to
>         have the
>         public API expose a /$servie-types resource endpoint for each
>         service
>         itself, instead of a generic /types (or /flavors) endpoint.
>         So, folks
>         looking to set up a load balancer would call
>         GET /balancer-types, or
>         call neutron balancer-type-list, instead of calling
>         GET /types?service=load-balancer or neutron flavor-list
>         --service=load-balancer
> I'm fine with this suggestion.
>  
>         
>         5) In the section on Scheduling, you write "Scheduling is a
>         process of
>         choosing provider and a backend for the resource". As
>         mentioned above, I
>         think this could be changed to something like this:
>         "Scheduling is a
>         process of matching the set of requested capabilities -- the
>         flavor
>         (type) -- to the set of capabilities advertised by a driver
>         for the
>         resource". That would put Neutron more in line with how Nova
>         handles
>         this kind of thing.
> I agree, I actually meant this and nova example is how I think it
> should work.
> But more important is what is the result of scheduling.
> We discussed that yesterday with Mark and I think we got so the point
> where we could not find agreement for now.
> In my opinion the result of scheduling is binding resource to the
> driver (at least)
> So further calls to the resource go to the same driver because of that
> binding.
> That's pretty much the same how agent scheduling works.
>  
> By the way I'm thinking about getting rid of 'provider' term and using
> 'driver' instead. Currently 'provider' is just a user-facing
> representation of the driver. Once we introduce flavors/service
> types/etc, we can use term 'driver' for implementation means.

++

Best,
-jay