All,
Currently OpenStack does not have a built-in HA mechanism for tenant
instances which could restore virtual machines in case of a host
failure. Openstack assumes every app is designed for failure and can
handle instance failure and will self-remediate, but that is rarely
the case for the very
All,
Currently OpenStack does not have a built-in HA mechanism for tenant
instances which could restore virtual machines in case of a host
failure. Openstack assumes every app is designed for failure and can
handle instance failure and will self-remediate, but that is rarely
In short, what we'll need from nova is to have 100% reliable
host-health monitor and equally reliable rebuild/evacuate mechanism
with fencing and scheduler. In heat we need scallable and reliable
event listener and engine to decide which action to perform in given
situation.
I tend to agree that that shouldn't be placed in nova. As it happens I'm
working on very same thing (hello Russell :)). My current candidate is heat.
Convergence will be in my opinion great place to do it
(https://review.openstack.org/#/c/95907/). It's still in state of planning, but
we'll
-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com]
Sent: Thursday, October 16, 2014 5:04 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Automatic evacuate
On 10/15/2014 05:07 PM, Florian Haas wrote:
On Wed, Oct 15, 2014 at 10:03
-Original Message-
From: Florian Haas [mailto:flor...@hastexo.com]
Sent: Thursday, October 16, 2014 10:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Automatic evacuate
On Thu, Oct 16, 2014 at 9:25 AM, Jastrzebski
Guys, I don't think we want to get into this cluster management mud. You say
let's
make observer...and what if observer dies? Do we do observer to observer? And
then
there is split brain. I'm observer, I've lost connection to worker. Should I
restart a worker?
Maybe I'm one who lost connection
: Thursday, November 13, 2014 3:49 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] Using Job Queues for timeout ops
On 13/11/14 09:31, Jastrzebski, Michal wrote:
Guys, I don't think we want to get into this cluster management mud.
You say let's make observer
-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: Thursday, November 13, 2014 8:00 PM
To: openstack-dev
Subject: Re: [openstack-dev] [Heat] Using Job Queues for timeout ops
Excerpts from Zane Bitter's message of 2014-11-13 09:55:43 -0800:
On 13/11/14 09:58,
-Original Message-
From: Joshua Harlow [mailto:harlo...@outlook.com]
Sent: Thursday, November 13, 2014 10:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Heat] Using Job Queues for timeout ops
On Nov 13, 2014, at 10:59 AM,
W dniu 11/27/2014 o 5:15 AM, Angus Salkeld pisze: On Thu, Nov 27, 2014
at 12:20 PM, Zane Bitter zbit...@redhat.com
mailto:zbit...@redhat.com wrote:
A bunch of us have spent the last few weeks working independently on
proof of concept designs for the convergence architecture.
-Original Message-
From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
Sent: Friday, November 28, 2014 8:33 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Heat] Rework auto-scaling support in Heat
Dear all,
Auto-Scaling is an important feature supported
Hello,
After discussions, we've spotted possible gap in versioned objects: backporting
of too-new versions in RPC.
Nova does that by conductor, but not every service has something like that. I
want to propose another approach:
1. Milestone pinning - we need to make single reference to versions
W dniu 5/4/2015 o 8:21 AM, Angus Salkeld pisze: On Thu, Apr 30, 2015 at 9:25
PM, Jastrzebski, Michal
michal.jastrzeb...@intel.com mailto:michal.jastrzeb...@intel.com wrote:
Hello,
After discussions, we've spotted possible gap in versioned objects:
backporting of too-new
W dniu 5/4/2015 o 11:50 AM, Angus Salkeld pisze: On Mon, May 4, 2015 at 6:33
PM, Jastrzebski, Michal
michal.jastrzeb...@intel.com mailto:michal.jastrzeb...@intel.com wrote:
W dniu 5/4/2015 o 8:21 AM, Angus Salkeld pisze: On Thu, Apr 30,
2015 at 9:25 PM, Jastrzebski, Michal
Hello,
I wanted to start discussion about versioned objects backporting for
conductor-less projects.
In Vancouver we discussed compatibility mode, which works like that:
1. We define one version for every object we use, this means adding base
object, for example:
Class HeatObject:
Hello guys,
As for TripleO+Upgrades, Kolla is one of ways to help with that. Keep in mind
that package upgrades also means dependency upgrades, and that can break things
unless we upgrade whole stack at once. No downtime upgrades will basically mean
that we need to decouple upgrade process to
Hello,
I have looked at this code and it seems pretty solid. I'm not sure if it will
be ready for governance as-is, there are few things I think have to be
addressed before (for example I'm not sure if ansible can be dependency due to
its license). Having said that I'd be happy to see it in
Hello,
Since we have little actual logic, and ansible itself is pretty pluggable by
its very nature, backporting should be quite easy and would not affect existing
deployment much. We will make sure that it will be safe to have stable/liberty
code and will keep working at all times. I agree
Thanks everyone!
I really appreciate this and I hope to help to make kolla even better project
than it is right now (and right now it's pretty cool;)). We have great
community, very diverse and very dedicated. It's pleasure to work with all of
you and let's keep up with great work in following
20 matches
Mail list logo
