Le 21/01/2014 15:28, Day, Phil a écrit :
I think there is clear water between this and the existing aggregate based
isolation. I also think this is a different use case from reservations. It's
*mostly* like a new scheduler hint, but because it has billing impacts I think
it
needs to be more than just that - for example the ability to request a
dedicated instance is something that should be controlled by a specific role.
I agree with that, that's another scheduler filter with extra scheduler hint,
plus a notification message on the AMQP queue thanks to an handler. That's
not role of Nova but Ceilometer to handle billable items and meters
consolidation.
That said, AWS dedicated instances are backed by VPC, so that's not fairly
identical from what you propose here. Here the proposal is more likely
making me thinking of AWS "reserved" instances without a contractual
period.
IMHO, this model is interesting but hard to use for operators, because they
don't have visibility on the capacity. Anyway, if Nova would provide this
feature, Climate would be glad using it (and on a personal note, I would be
glad contributing to it).
I think VPC in AWS is more of a network construct that anything to do with
specific hosts - (i.e the difference between running nova-net or neutron in
flat mode vs vlan or vxlan mode).
"Dedicated instances" in the AWS terminology are for VPC tenants and are
not subject to a contractual period. "Reserved instances" are actually a
billing model (with a period of either 1y or 3yrs) for charging a
certain number of instances with discounted rates and a one-time fee.
So, yes, dedicated instances in AWS are what we could call a "private
cloud" with internal networking (a personal CIDR), so that's why I said
that your proposal is more likely related to AWS reserved instances
model (without a term reservation)
I agree that it is hard for an operator to work out how to charge for this - in
effect it comes down to some sort of statistical model to work out what
additional premium you need to charge to recover the cost of the capacity that
is now not usable by other tenants. This kind of thing becomes easier at
scale than it is for very small systems. So some/many operators may decide
that they don't want to offer it (which is why it needs to be a specific
feature in my mind, even if that does mean a minor bump to the API version in
V3 and a new extension to provide the new option in V2 - sorry Jay). It
probably even merits its own specific quota value (max number of dedicated
instances). I'm not sure that its really that much harder to manage than any
other capacity issue though - for example if you define a flavor that occupies
Again, I was about designing this for Climate : provided the operator
specifies a max percentage of hosts to dedicate, that could do the work.
Perhaps you should take a look on the current Climate review [1] for
electing the hosts, we already thought about overprovisioning and
capacity planning. That's particularly why I'm thinking that capacity
planning needs reservations in place (explicitly defined by users, or
implicitely calculated) in order to do the maths.
-Sylvain
[1] :
https://review.openstack.org/#/c/54285/27/climate/plugins/oshosts/host_plugin.py
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
