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 to overstate how much
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 the best approach to dy
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 and
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 dependency on Barbican?
> What
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) that
> would be ops-bran
t 8:52 AM, Clayton O'Neill 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 Mid-Cycle.
>>
>> As an operator I got a lot out
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 the
On Thu, Jan 7, 2016 at 10:44 AM, Mike Bayer wrote:
> On 01/07/2016 07:39 AM, Clayton O'Neill wrote:
>> On Thu, Jan 7, 2016 at 2:49 AM, Roman Podoliaka
>> wrote:
>>> In each child process eventlet WSGI server calls accept() in a loop to
>>> get a client soc
+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 [mailto:emil...@redhat
+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 they were
>> hosted by Puppetlabs namespace.
+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 of code recently, to
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 real "spec" for INI
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 to grandfather any ex
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 to
On Wed, Nov 11, 2015 at 9:50 AM, Clayton O'Neill 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
> defaults in all
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 and
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
> yet and we're testin
+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 specific to our
> modules
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 ver
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
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 upstream
+1
On Tue, Jul 28, 2015 at 9:00 AM, Sebastien Badia 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
>
On Wed, Jul 15, 2015 at 6:11 PM, Mike Dorman 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 envision that long te
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
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
wrote:
> Matt Fischer wrote:
>
>> +1 from me for deprecation.
>>
>> I'd also like to know or have an official poli
Makes sense to drop them to me.
On Wed, Jun 10, 2015 at 7:20 PM, Emilien Macchi 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).
>
> If anyone is
>>> Flavio
>>>
>>> [0] https://review.openstack.org/#/c/138184/
>>>
>>>
>>>> Regards
>>>> Malini
>>>>
>>>> -Original Message-
>>>> From: Flavio Percoco [mailto:fla...@redhat.com]
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
prop
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 ra
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
you
On Thu, Apr 16, 2015 at 2:10 PM, Richard Raseley
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 them) of what the
On Thu, Apr 16, 2015 at 10:50 AM, Emilien Macchi 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
around this to expect
32 matches
Mail list logo
