Open Stack

On Mon, Oct 13, 2014 at 1:32 PM, Adam Lawson <alawson at 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 <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
>>> > >
>>>
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141013/5fe20711/attachment.html>