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 <rbry...@redhat.com> wrote: > >> On 10/15/2014 05:07 PM, Florian Haas wrote: >> On Wed, Oct 15, 2014 at 10:03 PM, Russell Bryant <rbry...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
