Open Stack

Le 21/01/2014 12:57, Day, Phil a écrit :
>>>> So, I actually don't think the two concepts (reservations and
>>>> "isolated instances") are competing ideas. Isolated instances are
>>>> actually not reserved. They are simply instances that have a
>>>> condition placed on their assignment to a particular compute node
>>>> that the node must only be hosting other instances of one or more
>>>> specified projects (tenants).
>>> I got your idea. This filter [1] already does most of the work,
>>> although it relies on aggregates and requires admin management. The
>>> main issue with isolated instances is that it requires kind of
>>> capacity planning for making sure you can cope with the load, that's
>>> why we placed the idea of having such a placement scheduler.
>>>
>>> [1] :
>>>
>> https://github.com/openstack/nova/blob/master/nova/scheduler/filters/a
>>> ggregate_multitenancy_isolation.py
>> Right, the difference between that and my proposed solution would be
>> there would be no dependency on any aggregate at all.
>>
>> I do understand your point about capacity planning in light of such scheduling
>> functionality -- due to the higher likelihood that compute nodes would be
>> unable to service a more general workload from other tenants.
>>
>> But I believe that the two concerns can be tackled separately.
>>
> Exactly - that's why I wanted to start this debate about the way forward for the Pcloud Blueprint, which was heading into some kind of middle ground.  As per my original post, and it sounds like the three of us are at least aligned I'm proposing to spilt this into two streams:
>
> i) A new BP that introduces the equivalent of AWS dedicated instances.
> 	User - Only has to specify that at boot time that the instance must be on a host used exclusively by that tenant.
> 	Scheduler - ether finds a hoist which matches this constraint or it doesn't.   No linkage to aggregates (other than that from other filters), no need for the aggregate to have been pre-configured
> 	Compute Manager - has to check the constraint (as with any other scheduler limit) and add the info that this is a dedicated instance to notification messages
> 	Operator - has to manage capacity as they do for any other such constraint (it is a significant capacity mgmt issue, but no worse in my mind that having flavors that can consume most of a host) , and work out how they want to charge for such a model (flat rate additional charge for first such instance, charge each time a new host is used, etc).
>
> 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).

> ii) Leave the concept of "private clouds within a cloud"  to something that can be handled at the region level.  I think there are valid use cases here, but it doesn’t make sense to try and get this kind of granularity within Nova.
>
>   
Agreed.

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev