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