Open Stack

Generally speaking that's true when you have full control over how you
deploy applications as a consumer. As a provider however, cloud resiliency
is king and it's generally frowned upon to associate instances directly to
the underlying physical hardware for any reason. It's good when instances
can come and go as needed, but in a production context, a failed compute
host shouldn't take down every instance hosted on it. Otherwise there is no
real abstraction going on and the cloud loses immense value.
On Sep 26, 2014 4:15 PM, "Clint Byrum" <clint at fewbar.com> wrote:

> Excerpts from Adam Lawson's message of 2014-09-26 14:43:40 -0700:
> > Hello fellow stackers.
> >
> > I'm looking for discussions/plans re VM continuity.
> >
> > I.e. Protection for instances using ephemeral storage against host
> failures
> > or auto-failover capability for instances on hosts where the host suffers
> > from an attitude problem?
> >
> > I know fail-overs are supported and I'm quite certain auto-fail-overs are
> > possible in the event of a host failure (hosting instances not using
> shared
> > storage). I just can't find where this has been addressed/discussed.
> >
> > Someone help a brother out? ; )
>
> I'm sure some of that is possible, but it's a cloud, so why not do things
> the cloud way?
>
> Spin up redundant bits in disparate availability zones. Replicate only
> what must be replicated. Use volumes for DR only when replication would
> be too expensive.
>
> Instances are cattle, not pets. Keep them alive just long enough to make
> your profit.
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140926/869c6f1b/attachment.html>