Open Stack

I've been thinking a lot about these use cases too. As was previously suggested, I think a session in Paris in this topic would be immensely beneficial. Is there somewhere we can officially log a room or some such for further discussion?

- Joe

> On Oct 15, 2014, at 9:04 PM, Russell Bryant <rbryant at redhat.com> wrote:
> 
>> On 10/15/2014 05:07 PM, Florian Haas wrote:
>> On Wed, Oct 15, 2014 at 10:03 PM, Russell Bryant <rbryant at redhat.com> wrote:
>>>> Am I making sense?
>>> 
>>> Yep, the downside is just that you need to provide a new set of flavors
>>> for "ha" vs "non-ha".  A benefit though is that it's a way to support it
>>> today without *any* changes to OpenStack.
>> 
>> Users are already very used to defining new flavors. Nova itself
>> wouldn't even need to define those; if the vendor's deployment tools
>> defined them it would be just fine.
> 
> Yes, I know Nova wouldn't need to define it.  I was saying I didn't like
> that it was required at all.
> 
>>> This seems like the kind of thing we should also figure out how to offer
>>> on a per-guest basis without needing a new set of flavors.  That's why I
>>> also listed the server tagging functionality as another possible solution.
>> 
>> This still doesn't do away with the requirement to reliably detect
>> node failure, and to fence misbehaving nodes. Detecting that a node
>> has failed, and fencing it if unsure, is a prerequisite for any
>> recovery action. So you need Corosync/Pacemaker anyway.
> 
> Obviously, yes.  My post covered all of that directly ... the tagging
> bit was just additional input into the recovery operation.
> 
>> Note also that when using an approach where you have physically
>> clustered nodes, but you are also running non-HA VMs on those, then
>> the user must understand that the following applies:
>> 
>> (1) If your guest is marked HA, then it will automatically recover on
>> node failure, but
>> (2) if your guest is *not* marked HA, then it will go down with the
>> node not only if it fails, but also if it is fenced.
>> 
>> So a non-HA guest on an HA node group actually has a slightly
>> *greater* chance of going down than a non-HA guest on a non-HA host.
>> (And let's not get into "don't use fencing then"; we all know why
>> that's a bad idea.)
>> 
>> Which is why I think it makes sense to just distinguish between
>> HA-capable and non-HA-capable hosts, and have the user decide whether
>> they want HA or non-HA guests simply by assigning them to the
>> appropriate host aggregates.
> 
> Very good point.  I hadn't considered that.
> 
> -- 
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev