Re: [openstack-dev] [Climate] Questions and comments

Patrick Petit patrick.pe...@bull.net wrote on 10/07/2013 07:02:36 AM: Hi Mike, There are actually more facets to this. Sorry if it's a little confusing :-( Climate's original blueprint https:// wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api was about physical host

Re: [openstack-dev] [Heat] HOT Software configuration proposal

. cheers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Patrick Petit Cloud Computing Principal Architect, Innovative Products Bull, Architect of an Open World TM

Re: [openstack-dev] [Heat] HOT Software configuration proposal

/listinfo/openstack-dev -- Patrick Petit Cloud Computing Principal Architect, Innovative Products Bull, Architect of an Open World TM Tél : +33 (0)4 76 29 70 31 Mobile : +33 (0)6 85 22 06 39 http://www.bull.com ___ OpenStack-dev mailing list OpenStack

Re: [openstack-dev] [Heat] HOT Software configuration proposal

Sorry, I clicked the 'send' button too quickly. On 10/24/13 11:54 AM, Patrick Petit wrote: Hi Clint, Thank you! I have few replies/questions in-line. Cheers, Patrick On 10/23/13 8:36 PM, Clint Byrum wrote: Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700: Dear Steve and All

[openstack-dev] Fwd: [OpenStackfr] Organisation, mailing-list...

Neary dne...@redhat.com, Patrick Petit patrick.pe...@bull.net, Sylvain Bauza sylv...@bauza.org, Christophe Sauthier christophe.sauth...@objectif-libre.com, Thierry Carrez thie...@openstack.org, Dave Neary dne...@gnome.org, Raphael Ferreira r.ferre...@enovance.com, Yannick Foeillet

[openstack-dev] [Heat] autoscaling question

Dear All, I'd like to have some confirmation about the mechanism that is going to be used to inform Heat's clients about instance create and destroy in an auto-scaling group. I am referring to the wiki page at https://wiki.openstack.org/wiki/Heat/AutoScaling. I assume, but I may be wrong,

[openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

probably enough as a starting point. I propose we iterate on this first and see where this is taking us. Best regards, Patrick -- Patrick Petit Cloud Computing Principal Architect, Innovative Products Bull, Architect of an Open World TM Tél : +33 (0)4 76 29 70 31 Mobile : +33 (0)6 85 22 06 39 http

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

the reservations must be available at the exact time the lease becomes effective. Thank you, DIna. On Mon, Aug 5, 2013 at 1:22 PM, Julien Danjou jul...@danjou.info mailto:jul...@danjou.info wrote: On Fri, Aug 02 2013, Patrick Petit wrote: 3. The proposal specifies that a lease can

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

on heuristics. A dedicated (e.g. IPMI) module of the Resource Manager for hosts reservation would subscribe as listener to those events. On Thu, Aug 8, 2013 at 8:18 PM, Patrick Petit patrick.pe...@bull.net mailto:patrick.pe...@bull.net wrote: Hi Nikolay, Relying on Heat for orchestration

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

, Aug 8, 2013 at 8:18 PM, Patrick Petit patrick.pe...@bull.net mailto:patrick.pe...@bull.net wrote: Hi Nikolay, Relying on Heat for orchestration is obviously the right thing to do. But there is still something in your design approach that I am having

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

is useful too and if so can you propose another implementation variant for it? Thank you. On Mon, Aug 12, 2013 at 1:55 PM, Patrick Petit patrick.pe...@bull.net mailto:patrick.pe...@bull.net wrote: On 8/9/13 3:05 PM, Nikolay Starodubtsev wrote: Hello, Patrick! We have several

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

. On Tue, Aug 13, 2013 at 4:23 PM, Patrick Petit patrick.pe...@bull.net mailto:patrick.pe...@bull.net wrote: Hi Nikolay, Please see comments inline. Thanks Patrick On 8/12/13 5:28 PM, Nikolay Starodubtsev wrote: Hi, again! Partick, I'll try to explain why do we

Re: [openstack-dev] [Climate] Questions and comments

@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Patrick Petit Cloud Computing Principal Architect, Innovative Products Bull, Architect of an Open World TM Tél : +33 (0)4 76 29 70 31 Mobile : +33 (0)6 85 22 06 39 http://www.bull.com

Re: [openstack-dev] [Ceilometer][Gnocchi] question on integration with time-series databases

On 18 Jun 2015 at 04:44:18, gordon chung (g...@live.ca) wrote: On 17/06/2015 12:57 PM, Chris Dent wrote:  On Tue, 16 Jun 2015, Simon Pasquier wrote:    I'm still struggling to see how these optimizations would be implemented  since the current Gnocchi design has separate backends for indexing

Re: [openstack-dev] [Fuel][Plugins] Feedback

Hi Additional comments inside. Thanks Patrick On 28 Jul 2015 at 18:33:34, Sheena Gregson (sgreg...@mirantis.com) wrote: Hey Sergii –   This is excellent feedback, thank you for taking the time to provide your thoughts.   #1 I agree that the documentation lag is challenging – I’m not sure

Re: [openstack-dev] [Fuel][Plugins] Feedback

On 29 Jul 2015 at 14:41:48, Sheena Gregson (sgreg...@mirantis.com) wrote: Hey Sergii –   I don’t know if I agree with the statement that it’s bad practice to mix core and plugin functionality.  From a user standpoint, if I’m trying to deploy something like Contrail, I would like to see all of

Re: [openstack-dev] [Fuel][Plugins] Plugins on separate launchpad projects

for each plugin or one individual project for several plugins when it makes sense to regroupe them under one umbrella like LMA toolchain as stated earlier.   Sheena   From: Patrick Petit [mailto:ppe...@mirantis.com] Sent: Saturday, July 25, 2015 12:25 PM To: Igor Kalnitsky; OpenStack Development

[openstack-dev] [Fuel][Plugins] Plugins on separate launchpad projects

project itself in addition to making it cluttered with stuffs that unrelated to Fuel. Can you please tell me what’s your thinking about this? Thanks Patrick --  Patrick Petit Mirantis France __ OpenStack Development Mailing

Re: [openstack-dev] [Fuel][Plugins] Plugins on separate launchpad projects

24, 2015 at 8:27 PM, Patrick Petit ppe...@mirantis.com wrote: Hi There, I have been thinking that it would make a lot of sense to have separate launchpad projects for Fuel plugins. The main benefits I foresee…. - Fuel project will be less of a bottleneck for bug triage and it should be more

[openstack-dev] [Fuel][Plugins] Plugin deployment questions

Hi There, There are situations where we’d like to deploy only Fuel plugins in an environment. That’s typically the case with Elasticsearch and InfluxDB plugins of LMA tools. Currently it’s not possible because you need to at least have one controller. What exactly is making that limitation? How

Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions

ce architecture to perform destructive tests on it. Requirement to install controller is an excessive burden in that case. Thanks, Dmitry 2015-10-19 13:44 GMT+03:00 Patrick Petit <ppe...@mirantis.com>: Hi There, There are situations where we’d like to deploy only Fuel plugins in an enviro

Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions

On 21 Oct 2015 at 12:21:57, Igor Kalnitsky (ikalnit...@mirantis.com) wrote: We can make bidirectional dependencies, just like our deployment tasks do. Just to make sure we are on the same page… We don’t want to be in a situation where a role needs to know about the its reverse dependencies.

Re: [openstack-dev] [kolla] Introduction of Heka in Kolla

On 12 Jan 2016 at 13:24:26, Kwasniewska, Alicja (alicja.kwasniew...@intel.com) wrote: Unfortunately I do not have any experience in working or testing Heka, so it’s hard for me to compare its performance vs Logstash performance. However I’ve read that Heka possess a lot advantages over

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

On 15 Jan 2016 at 14:43:39, Michał Jastrzębski (inc...@gmail.com) wrote: Yeah that's true. We did all of openstack systems but we didn't  implement infra around yet. I'd guess most of services can log either  to stdout or file, and both sources should be accessible by heka.  Also, I'd be surprised

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

are not standard. Patrick Thanks, Igor [1]: https://review.openstack.org/#/c/243240/ On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <ppe...@mirantis.com> wrote: > Fuelers, > > As Simon said, we already have a log centralisation solution for MOS > delivered as a Fuel plugins k

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

into those services and only then, enter into the regular OpenStack provisioning mode. On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit <ppe...@mirantis.com> wrote:  >  > On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com)  > wrote:  >  > Hey Roman,  > 

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

On 11 March 2016 at 15:45:57, Simon Pasquier (spasqu...@mirantis.com) wrote: Thanks for kicking off the discussion! On Thu, Mar 10, 2016 at 8:30 AM, Mike Scherbakov wrote: Hi folks, in order to make a decision whether we need to support example plugins, and if

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

Fuelers, As Simon said, we already have a log centralisation solution for MOS delivered as a Fuel plugins known as StackLight / LMA toolset. And so objectively, there is no need to have log management in Nailgun anymore. To go one step further we suggested several times to have a StackLight