Open Stack

> 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.

Why do you want to transform pCloud into AWS dedicated instances? As I see 
it,
pCloud is for requesting physical hosts (HostFlovors as in pcloud wiki) on 
which
users can create their own instances (theoretically in unlimited number). 
Therefore it should be charged per physical server
(HostFlavor), not by instances. It is completely different from AWS 
dedicated instances
which is charged per instance. IMO, pcloud resembles Godrid Dedicated 
Server, not
AWS Dedicated Instance.

If you want to provide AWS dedicated instances  typed service, then it would 
not be
Pcloud, nor it is a continuation of the WholeHostAllocaiton blueprint, which 
,
IMO, is damned well designed. It'll be just another scheduler job. Well, I 
did not say
that it's not worth pursuing ; I just say that WholeHostAllocation is worth 
being
kept pcloud.

> 	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).
>

How about using migration for releasing compute hosts for new allocation? In 
standard
configuration, admin would use LoadBalancing for his computes. Thus if we 
don't have
a dedicated resources pool (this comes back to aggregate configuration), 
then all hosts
would be used, which leaves no host empty for hosting dedicated instances.

> 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.

Agreed. The billing is rather the problem here. Nova can handle this all 
right, but how
this new functionality cope with the billing model. Basically, which 
information is
recorded, and where.

>
> 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.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev