I think Adam is talking about this bp: https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically
For now, we're using Nagios probe/event to trigger the Nova evacuate command, but I think it's possible to do that in Nova if we can find a good way to define the trigger policy. On 14/10/14 10:15, Joe Gordon wrote: > > > On Mon, Oct 13, 2014 at 1:32 PM, Adam Lawson <alaw...@aqorn.com > <mailto:alaw...@aqorn.com>> wrote: > > Looks like this was proposed and denied to be part of Nova for > some reason last year. Thoughts on why and is the reasoning > (whatever it was) still applicable? > > > Link? > > > > > */ > Adam Lawson/* > > AQORN, Inc. > 427 North Tatnall Street > Ste. 58461 > Wilmington, Delaware 19801-2230 > Toll-free: (844) 4-AQORN-NOW ext. 101 > International: +1 302-387-4660 <tel:%2B1%20302-387-4660> > Direct: +1 916-246-2072 <tel:%2B1%20916-246-2072> > > > On Mon, Oct 13, 2014 at 1:26 PM, Adam Lawson <alaw...@aqorn.com > <mailto:alaw...@aqorn.com>> wrote: > > [switching to openstack-dev] > > Has anyone automated nova evacuate so that VM's on a failed > compute host using shared storage are automatically moved onto > a new host or is manually entering /nova compute <instance> > <host>/ required in all cases? > > If it's manual only or require custom Heat/Ceilometer > templates, how hard would it be to enable automatic evacuation > within Novs? > > i.e. (within /etc/nova/nova.conf) > auto_evac = true > > Or is this possible now and I've simply not run across it? > > */ > Adam Lawson/* > > AQORN, Inc. > 427 North Tatnall Street > Ste. 58461 > Wilmington, Delaware 19801-2230 > Toll-free: (844) 4-AQORN-NOW ext. 101 > International: +1 302-387-4660 <tel:%2B1%20302-387-4660> > Direct: +1 916-246-2072 <tel:%2B1%20916-246-2072> > > > On Sat, Sep 27, 2014 at 12:32 AM, Clint Byrum > <cl...@fewbar.com <mailto:cl...@fewbar.com>> wrote: > > So, what you're looking for is basically the same old IT, > but with an > API. I get that. For me, the point of this cloud thing is > so that server > operators can make _reasonable_ guarantees, and > application operators > can make use of them in an automated fashion. > > If you start guaranteeing 4 and 5 nines for single VM's, > you're right > back in the boat of spending a lot on server > infrastructure even if your > users could live without it sometimes. > > Compute hosts are going to go down. Networks are going to > partition. It > is not actually expensive to deal with that at the > application layer. In > fact when you know your business rules, you'll do a better > job at doing > this efficiently than some blanket "replicate all the > things" layer might. > > I know, some clouds are just new ways to chop up these > fancy 40 core > megaservers that everyone is shipping. I'm sure OpenStack > can do it, but > I'm saying, I don't think OpenStack _should_ do it. > > Excerpts from Adam Lawson's message of 2014-09-26 20:30:29 > -0700: > > 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" <cl...@fewbar.com > <mailto:cl...@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 : openst...@lists.openstack.org > <mailto:openst...@lists.openstack.org> > > > Unsubscribe : > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto: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 -- Cheers & Best regards, Fei Long Wang (王飞龙) -------------------------------------------------------------------------- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
