Open Stack

On 13 December 2013 06:13, Keith Basil <kbasil at redhat.com> wrote:
> On Dec 11, 2013, at 3:42 PM, Robert Collins wrote:

>>> My question is - can't we help them now? To enable users to use our app even
>>> when we don't have enough smartness to help them 'auto' way?
>>
>> I understand the question: but I can't answer it until we have *an*
>> example that is both real and not deliverable today. At the moment the
>> only one we know of is HA, and thats certainly an important feature on
>> the nova scheduled side, so doing manual control to deliver a future
>> automatic feature doesn't make a lot of sense to me. Crawl, walk, run.
>
> Maybe this is a valid use case?
>
> Cloud operator has several core service nodes of differing configuration
> types.
>
> [node1]  <-- balanced mix of disk/cpu/ram for general core services
> [node2]  <-- lots of disks for Ceilometer data storage
> [node3]  <-- low-end "appliance like" box for a specialized/custom core service
>              (SIEM box for example)
>
> All nodes[1,2,3] are in the same deployment grouping ("core services)".  As such,
> this is a heterogenous deployment grouping.  Heterogeneity in this case defined by
> differing roles and hardware configurations.
>
> This is a real use case.
>
> How do we handle this?

Ok, so node1 gets flavor A, node2 gets flavor B, node3 gets flavor C.

We have three disk images, one with general core services on it
(imageA), one with ceilometer backend storage (imageB), one with SIEM
on it (imageC).
And we have three service groups, one that binds imageA to {flavors:
[FlavorA], count:1}, one that binds imageB to {flavors:[FlavorB],
count:1}, one that binds imageC to {flavors:[FlavorC], count:1}

Thats doable by the plumbing today, without any bypass of the Nova scheduler.

FlavorB might be the same as the flavor for gluster boxes for
instance, in which case you'll get commonality - if one fails, we can
schedule onto another.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud