Open Stack

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?


*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 <alawson at 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 <clint at 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" <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-dev/attachments/20141013/e2ee8239/attachment.html>