On Mon, Oct 13, 2014 at 1:32 PM, Adam Lawson <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 > Direct: +1 916-246-2072 > > > On Mon, Oct 13, 2014 at 1:26 PM, Adam Lawson <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 >> Direct: +1 916-246-2072 >> >> >> On Sat, Sep 27, 2014 at 12:32 AM, Clint Byrum <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> 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 >>> > > Unsubscribe : >>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> > > >>> >> >> > > _______________________________________________ > 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
