Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140121/b6d3bb8e/attachment.html>