Re: [openstack-dev] [all] [tc] Technical Committee Vision draft

2017-04-14 Thread Florian Haas
On Fri, Apr 14, 2017 at 12:55 PM, Jeremy Stanley wrote: > It's intentionally ambitious, yes, because we want to inspire and be > inspired to great achievements. I generally don't think that that approach works for a large community, except in the rare cases of where you have

Re: [openstack-dev] [all] [tc] Technical Committee Vision draft

2017-04-14 Thread Florian Haas
On Wed, Apr 5, 2017 at 11:46 AM, Thierry Carrez wrote: > Hi everyone, > > Last year in Ann Arbor, a group of OpenStack community members > (including 6 current TC members) attended a Servant Leadership training > at ZingTrain organized by Colette Alexander and funded by the

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-17 Thread Florian Haas
On Fri, Oct 17, 2014 at 9:53 AM, Jastrzebski, Michal michal.jastrzeb...@intel.com wrote: -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

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Florian Haas
(5) Let monitoring and orchestration services deal with these use cases and have Nova simply provide the primitive API calls that it already does (i.e. host evacuate). That would arguably lead to an incredible amount of wheel reinvention for node failure detection, service failure

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Florian Haas
On Thu, Oct 16, 2014 at 5:04 AM, Russell Bryant rbry...@redhat.com wrote: On 10/15/2014 05:07 PM, Florian Haas wrote: On Wed, Oct 15, 2014 at 10:03 PM, Russell Bryant rbry...@redhat.com wrote: Am I making sense? Yep, the downside is just that you need to provide a new set of flavors for ha

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Florian Haas
On Thu, Oct 16, 2014 at 9:25 AM, Jastrzebski, Michal michal.jastrzeb...@intel.com wrote: In my opinion flavor defining is a bit hacky. Sure, it will provide us functionality fairly quickly, but also will strip us from flexibility Heat would give. Healing can be done in several ways, simple

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Florian Haas
On Thu, Oct 16, 2014 at 11:01 AM, Thomas Herve thomas.he...@enovance.com wrote: This still doesn't do away with the requirement to reliably detect node failure, and to fence misbehaving nodes. Detecting that a node has failed, and fencing it if unsure, is a prerequisite for any recovery

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Florian Haas
On Thu, Oct 16, 2014 at 1:59 PM, Russell Bryant rbry...@redhat.com wrote: On 10/16/2014 04:29 AM, Florian Haas wrote: (5) Let monitoring and orchestration services deal with these use cases and have Nova simply provide the primitive API calls that it already does (i.e. host evacuate

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Florian Haas
On Thu, Oct 16, 2014 at 4:31 PM, Steve Gordon sgor...@redhat.com wrote: Running compute nodes as baremetal extensions of a different Corosync/Pacemaker cluster (presumably the one that manages the other Nova services) would potentially be an option, although vendors would need to buy into

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Florian Haas
On Thu, Oct 16, 2014 at 7:03 PM, Adam Lawson alaw...@aqorn.com wrote: Be forewarned; here's my two cents before I've had my morning coffee. It would seem to me that if we were seeking some level of resiliency against host failures (if a host fails, evacuate the instances that were hosted on

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Florian Haas
On Thu, Oct 16, 2014 at 7:48 PM, Jay Pipes jaypi...@gmail.com wrote: While one of us (Jay or me) speaking for the other and saying we agree is a distributed consensus problem that dwarfs the complexity of Paxos You've always had a way with words, Florian :) I knew you'd like that one. :) ,

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-16 Thread Florian Haas
On Thu, Oct 16, 2014 at 9:40 PM, Russell Bryant rbry...@redhat.com wrote: On 10/16/2014 02:40 PM, Adam Lawson wrote: Question: is host HA not achievable using the programs we have in place now (with modification of course)? If not, I'm still a champion to see it done within our four walls.

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-15 Thread Florian Haas
On Wed, Oct 15, 2014 at 7:20 PM, Russell Bryant rbry...@redhat.com wrote: On 10/13/2014 05:59 PM, Russell Bryant wrote: Nice timing. I was working on a blog post on this topic. which is now here: http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/ I am absolutely

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-15 Thread Florian Haas
On Wed, Oct 15, 2014 at 9:58 PM, Jay Pipes jaypi...@gmail.com wrote: On 10/15/2014 03:16 PM, Florian Haas wrote: On Wed, Oct 15, 2014 at 7:20 PM, Russell Bryant rbry...@redhat.com wrote: On 10/13/2014 05:59 PM, Russell Bryant wrote: Nice timing. I was working on a blog post on this topic

Re: [openstack-dev] [Nova] Automatic evacuate

2014-10-15 Thread Florian Haas
On Wed, Oct 15, 2014 at 10:03 PM, Russell Bryant rbry...@redhat.com wrote: Am I making sense? Yep, the downside is just that you need to provide a new set of flavors for ha vs non-ha. A benefit though is that it's a way to support it today without *any* changes to OpenStack. Users are

Re: [openstack-dev] [ceilometer] Exposing Ceilometer alarms as SNMP traps

2014-04-25 Thread Florian Haas
Hi Eric, On Thu, Apr 24, 2014 at 7:02 PM, Eric Brown bro...@vmware.com wrote: I'm pretty familiar with SNMP as I have worked with it for a number years. I know Telcos like it, but I feel its a protocol that is near end of life. It hasn't kept up on security guidelines. SNMPv1 and v2c are

[openstack-dev] [ceilometer] Exposing Ceilometer alarms as SNMP traps

2014-04-24 Thread Florian Haas
Hello everyone, I'd just like to throw something out there for discussion. Please note that I've CC'd the operators list to reach a wider audience (including the would-be users of the feature I'm about to discuss), but this is rather firmly a development issue, so it would be great if we could

Re: [openstack-dev] [ceilometer] Exposing Ceilometer alarms as SNMP traps

2014-04-24 Thread Florian Haas
[Dropping -operators from CC list] On Thu, Apr 24, 2014 at 2:55 PM, Julien Danjou jul...@danjou.info wrote: On Thu, Apr 24 2014, Florian Haas wrote: There are interesting side issues here, by the way, such as the fact that Ceilometer alarms currently have no concept of severity, which

Re: [openstack-dev] [ceilometer] Exposing Ceilometer alarms as SNMP traps

2014-04-24 Thread Florian Haas
On Thu, Apr 24, 2014 at 4:20 PM, Julien Danjou jul...@danjou.info wrote: On Thu, Apr 24 2014, Florian Haas wrote: So for any inheriting subclass, the notify method signature is defined such that action needs to be a URL. That doesn't make a whole lot of sense for anything other than a ReSTful

Re: [openstack-dev] [oslo][db] Mysql traditional session mode

2014-01-24 Thread Florian Haas
On Thu, Jan 23, 2014 at 7:22 PM, Ben Nemec openst...@nemebean.com wrote: On 2014-01-23 12:03, Florian Haas wrote: Ben, thanks for taking this to the list. Apologies for my brevity and for HTML, I'm on a moving train and Android Gmail is kinda stupid. :) I have some experience

Re: [openstack-dev] [oslo][db] Mysql traditional session mode

2014-01-24 Thread Florian Haas
On Fri, Jan 24, 2014 at 4:30 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Fri, Jan 24, 2014 at 3:29 AM, Florian Haas flor...@hastexo.com wrote: On Thu, Jan 23, 2014 at 7:22 PM, Ben Nemec openst...@nemebean.com wrote: On 2014-01-23 12:03, Florian Haas wrote: Ben, thanks

Re: [openstack-dev] [oslo][db] Mysql traditional session mode

2014-01-23 Thread Florian Haas
Ben, thanks for taking this to the list. Apologies for my brevity and for HTML, I'm on a moving train and Android Gmail is kinda stupid. :) On Jan 23, 2014 6:46 PM, Ben Nemec openst...@nemebean.com wrote: A while back a change (https://review.openstack.org/#/c/47820/) was made to allow