Open Stack

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 <alawson at aqorn.com
> <mailto: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 <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 <alawson at aqorn.com
>     <mailto: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 <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
>         <clint at fewbar.com <mailto: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
>             <mailto: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
>             <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141014/795aac11/attachment-0001.html>