<div dir="ltr">Hi, <span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Eugene,</span><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">What are the parameters that will be part of flavor definition? As I am thinking of it now, the parameter could be performance and capacity related, for example, throughput, max. session number and so on; or capability related, for example, HA, L7 switching.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Compared to # of CPU and memory size in Nova flavor, these parameters don't seem to have exact definitions across different implementations. Or, you think it is not something we need worry about. It's totally operator's decision of how to rate different drivers?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Thanks,</span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Gary</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 10:19 PM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jay,<div><br></div><div>Thanks for looking into this.<br><div class="gmail_extra"><br><div class="gmail_quote">
<div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br></div></div>
1) I'm not entirely sure that a provider attribute is even necessary to<br>
expose in any API. What is important is for a scheduler to know which<br>
drivers are capable of servicing a set of attributes that are grouped<br>
into a "flavor".<br></blockquote></div><div>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. </div><div class="">
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) I would love to see the use of the term "flavor" banished from<br>
OpenStack APIs. Nova has moved from flavors to "instance types", which<br>
clearly describes what the thing is, without the odd connotations that<br>
the word "flavor" has in different languages (not to mention the fact<br>
that flavor is spelled flavour in non-American English).<br>
<br>
How about using the term "load balancer type", "VPN type", and "firewall<br>
type" instead?<br></blockquote></div><div>Oh... I don't have strong opinion on the name of the term.</div><div>"Flavor" was used several time in our discussions and is short.</div><div>"*Instance* Type" however seems also fine. Another option is probably a "Service Offering".</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3) I don't believe the FlavorType (public or internal) attribute of the<br>
flavor is useful. We want to get away from having any vendor-specific<br>
attributes or objects in the APIs (yes, even if they are "hidden" from<br>
the normal user). See point #1 for more about this. A scheduler should<br>
be able to match a driver to a request simply by matching the set of<br>
required capabilities in the requested flavor (load balancer type) to<br>
the set of capabilities advertised by the driver.<br></blockquote></div><div>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.</div>
<div>That could be also solved by having different names live you suggested above: "Lb type", "VPN type", etc. </div><div>On other hand that would be similar objects with different names - does it make much sense?</div>
<div><br></div><div>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.</div>
<div class="">
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4) A minor point... I think it would be fine to group the various<br>
"types" into a single database table behind the scenes (like you have in<br>
the Object model section). However, I think it is useful to have the<br>
public API expose a /$servie-types resource endpoint for each service<br>
itself, instead of a generic /types (or /flavors) endpoint. So, folks<br>
looking to set up a load balancer would call GET /balancer-types, or<br>
call neutron balancer-type-list, instead of calling<br>
GET /types?service=load-balancer or neutron flavor-list<br>
--service=load-balancer<br></blockquote></div><div>I'm fine with this suggestion.</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
5) In the section on Scheduling, you write "Scheduling is a process of<br>
choosing provider and a backend for the resource". As mentioned above, I<br>
think this could be changed to something like this: "Scheduling is a<br>
process of matching the set of requested capabilities -- the flavor<br>
(type) -- to the set of capabilities advertised by a driver for the<br>
resource". That would put Neutron more in line with how Nova handles<br>
this kind of thing.<br></blockquote></div><div>I agree, I actually meant this and nova example is how I think it should work.</div><div>But more important is what is the result of scheduling.</div><div>We discussed that yesterday with Mark and I think we got so the point where we could not find agreement for now.</div>
<div>In my opinion the result of scheduling is binding resource to the driver (at least)</div><div>So further calls to the resource go to the same driver because of that binding.</div><div>That's pretty much the same how agent scheduling works.</div>
<div> </div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>