Re: [openstack-dev] [puppet] rabbit/kombu settings deprecations

On Thu, Apr 16, 2015 at 10:50 AM, Emilien Macchi emil...@redhat.com wrote: We do our best now to backport what is backportable to stable/juno. This certainly has gotten much better, but I don't think it's 100% there yet either. It's just a ton of work and we probably need better tooling

Re: [openstack-dev] [puppet] rabbit/kombu settings deprecations

On Thu, Apr 16, 2015 at 2:10 PM, Richard Raseley rich...@raseley.com wrote: I am certainly sympathetic to your situation - having the world change beneath your feet is never a good place to be. =] It does seem, however, that there is a disconnect between your expectations (as I understand

[openstack-dev] [puppet] Managing config file values and parameter defaults

How to handle config file values, defaults and how they relate to manifest parameters was brought up in the weekly meeting up a few weeks ago. I promised to put something together. I've put written up my thoughts and my understanding of the other viewpoints presented there in an ether pad and

[openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova

We tested testing Kilo upgrades in our hardware dev environments last week and the second time through ran into this bug which right now is probably a show-stopper for us. https://bugs.launchpad.net/glance/+bug/1419823 The issue here is that the v1 Glance API allows you to create images with

Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova

] Sent: Monday, June 08, 2015 11:47 PM To: OpenStack Development Mailing List (not for usage questions) Cc: openstack-operat...@lists.openstack.org Subject: Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova On 08/06/15 11:46 -0400, Clayton O'Neill wrote: We tested testing

Re: [openstack-dev] [puppet] (officially) deprecate stable/{grizzly, havana} branches

I'd vote for stable -2. I think a number of people do an upgrade maybe once a year. I believe CERN just upgraded to juno recently. On Tue, Jun 16, 2015 at 1:36 PM, Richard Raseley rich...@raseley.com wrote: Matt Fischer wrote: +1 from me for deprecation. I'd also like to know or have an

Re: [openstack-dev] [puppet] drop monolithic plugins in neutron module

Makes sense to drop them to me. On Wed, Jun 10, 2015 at 7:20 PM, Emilien Macchi emil...@redhat.com wrote: Hi, Monolithic plugins have been dropped in Neutron tree since Juno, I think it's time to drop the code from puppet-neutron (I guess everyone is using ML2, at least I hope for them).

[openstack-dev] [puppet] RabbitMQ deprecation

I've spent some time trying to eliminate the number of deprecation warnings we have in preparation for our upgrade to Kilo. One of the ones that I got stuck on is the nova::rabbitmq::rabbitmq_class parameter. If this parameter is specified, and it is by default, then the class will include the

Re: [openstack-dev] [fuel][puppet] Fuel Library and upstream modules

Emilien, debtor looks like an interesting tool, thanks for the link. As far as tracking upstream branches from local forks and carrying local patches, we've had good luck with using the git-upstream tool on stack forge: https://github.com/stackforge/git-upstream It allows you to merge in

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

+1 On Tue, Jul 28, 2015 at 9:00 AM, Sebastien Badia s...@sebian.fr wrote: On Mon, Jul 27, 2015 at 03:06:56PM (-0400), Emilien Macchi wrote: I would like to open the vote to promote Yanis part of Puppet OpenStack core reviewers. Hi, Yes, of course! A big +1 Seb -- Sebastien Badia

[openstack-dev] [puppet] puppet-designate POC implementation of virtualenv and docker support.

Last year I put together a virtualenv patch for the Designate puppet module, but the patch was too invasive of a change and too opinionated to be practical to merge. I've taken another shot at this with the approach of implementing well defined hooks for various phases of the module. This should

Re: [openstack-dev] [puppet] puppet-designate POC implementation of virtualenv and docker support.

On Wed, Jul 15, 2015 at 6:11 PM, Mike Dorman mdor...@godaddy.com wrote: I have been meaning to ask you about this, so thanks for posting. I like the approach. Definitely a lot cleaner than the somewhat hardcoded dependencies and subscriptions that are in the modules now. Do you

Re: [openstack-dev] [puppet] Incompatible default parameters

I think the only people that would be affected by the puppet-openstack module default not matching the keystone default are people that are trying to retrofit puppet into an already running environment. Those people already have a ton of work laid out in front of them, so I’m ok with making it

Re: [openstack-dev] [puppet] ::db classes

On Wed, Nov 11, 2015 at 9:50 AM, Clayton O'Neill <clay...@oneill.net> wrote: > I discovered this issue last night and opened a bug on it ( > https://bugs.launchpad.net/puppet-tuskar/+bug/1515273). > > This effects most of the modules, and the short version of it is that the

[openstack-dev] [puppet] ::db classes

I discovered this issue last night and opened a bug on it ( https://bugs.launchpad.net/puppet-tuskar/+bug/1515273). This effects most of the modules, and the short version of it is that the defaults in all the ::db classes are wrong for max_pool_size and max_overflow. We’re setting test to 10

Re: [openstack-dev] [puppet] about $::os_service_default

What Matt said. I think we don’t need to explicitly support people that aren’t using distribution packages, we just want to try to avoid making harder things harder. I don’t see a need to go out of our way to support it. Anyone that isn’t using distro packages should be able to figure out how

Re: [openstack-dev] [puppet] Creating puppet-keystone-core and proposing Richard Megginson core-reviewer

+1 Big thanks for Rich for all the work he’s done so far. On Mon, Nov 2, 2015 at 3:34 AM, Adam Young wrote: > On 10/31/2015 10:55 AM, Emilien Macchi wrote: > > At the Summit we discussed about scaling-up our team. > We decided to investigate the creation of sub-groups

Re: [openstack-dev] [puppet] about $::os_service_default

What is the issue with logging? Can someone other than Yanis look into this? On Tue, Nov 3, 2015 at 8:57 AM, Emilien Macchi wrote: > I'm seeing a lot of patches using the new $::os_service_default. > > Please stop trying to using it at this time. The feature is not stable >

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

I agree that ideally, using a native ruby library would be better, but I also share Matt's concern. We'd need a commitment from more than one person to maintain the library if we went that route. I think the big advantages I see with the ruby client would be: - Potentially better performance

Re: [openstack-dev] [puppet] Config support for oslo.config.cfg.MultiStrOpt

For puppetlabs-inifile that’s a bigger question. For our purposes the answer is “whatever ConfigParser does”. On Wed, Dec 2, 2015 at 10:32 PM, Cody Herriges wrote: > Martin, > > I see no reason this shouldn't just be pushed into puppetlabs-inifile. I > can't actually find a

Re: [openstack-dev] [puppet] proposing Cody Herriges part of Puppet OpenStack core

+1 On Tue, Dec 8, 2015 at 4:15 PM, Matt Fischer wrote: > +1 > > On Tue, Dec 8, 2015 at 2:07 PM, Rich Megginson > wrote: > >> On 12/08/2015 09:49 AM, Emilien Macchi wrote: >> >> Hi, >> >> Back in "old days", Cody was already core on the modules, when

Re: [openstack-dev] [puppet] proposing Sofer Athlan Guyot part of puppet-keystone core team

+1 from me. On Thu, Dec 3, 2015 at 3:05 PM, Emilien Macchi wrote: > Hi, > > For some months, Puppet OpenStack group has been very lucky to have > Sofer working with us. > He became a huge contributor to puppet-keystone, he knows the module > perfectly and wrote insane amount

Re: [openstack-dev] [puppet] proposing Alex Schultz part of core team

+1 On Tue, Jan 5, 2016 at 1:15 PM, Potter, Nathaniel < nathaniel.pot...@intel.com> wrote: > I'm not a core, but Alex has been very helpful to me in the past and I > think he's definitely earned it, +1. > > Thanks, > Nate > > -Original Message- > From: Emilien Macchi

Re: [openstack-dev] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

On Thu, Jan 7, 2016 at 10:44 AM, Mike Bayer <mba...@redhat.com> wrote: > On 01/07/2016 07:39 AM, Clayton O'Neill wrote: >> On Thu, Jan 7, 2016 at 2:49 AM, Roman Podoliaka <rpodoly...@mirantis.com> >> wrote: >>> In each child process eventlet WSGI server

Re: [openstack-dev] [puppet] weekly meeting #59

On Tue, Nov 17, 2015 at 4:38 PM, Cody Herriges wrote: > Now that the standard is $::os_service_default does it mean that current > changes up for review with parameters set to the string ' DEFAULT>' should be changed to $::os_service_default before merge? > The decision was

Re: [openstack-dev] [Puppet] Suggestions for Dynamic enabling of SRIOV nic agent

I would probably create a custom fact to identify which ones have sriov capable NICs and use that to selectively enable installation of the correct packages, setup aggregates, etc. On Fri, Jun 24, 2016 at 7:19 AM, Sanjay Upadhyay wrote: > Hello Folks, > > Wondering what is

Re: [openstack-dev] [all] A proposal to separate the design summit

On Mon, Feb 29, 2016 at 4:32 AM, Thierry Carrez wrote: > That was considered... and I would not necessarily be against it, but I > would like to understand what the benefit would be. Tom advocated for > keeping it as a separate event (or a set of regional separated events)

Re: [openstack-dev] [all] A proposal to separate the design summit

I think this is a great proposal, but like Matt I’m curious how it might impact the operator sessions that have been part of the Design Summit and the Operators Mid-Cycle. As an operator I got a lot out of the cross-project designs sessions in Tokyo, but they were scheduled at the same time as

Re: [openstack-dev] [all] A proposal to separate the design summit

wrote: > >> On Feb 22, 2016, at 8:52 AM, Clayton O'Neill <clay...@oneill.net> wrote: >> >> I think this is a great proposal, but like Matt I’m curious how it >> might impact the operator sessions that have been part of the Design >> Summit and the Operators Mi

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

On Wed, Apr 13, 2016 at 10:26 AM, rezroo wrote: > Hi Kevin, > > I understand that this is how it is now. My question is how bad would it be > to wrap the Barbican client library calls in another class and claim, for > all practical purposes, that Magnum has no direct

[openstack-dev] [puppet] Stepping down from puppet core

I’d like to step down as a core reviewer for the OpenStack Puppet modules. For the last cycle I’ve had very little time to spend reviewing patches, and I don’t expect that to change in the next cycle. In addition, it used to be that I was contributing regularly because we were early upgraders

Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

On Fri, Sep 9, 2016 at 12:05 PM, Emilien Macchi wrote: > However, I think it's time to pass the PTL torch for Ocata cycle. > Don't worry, I'll still be around and bother you when CI is broken ;-) > > Again, a big thank you for those who work with me, I think it’s impossible