On Tue, Nov 1, 2016 at 7:19 AM, Satyanarayana Patibandla
wrote:
> We are planning for a new Openstack large deployment ( Around 25 K VMs). For
> external routing we want to use DVR for instances with floating IP and
> Network node L3 agent for instances with private
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
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
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
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
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)
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
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
ow we can help support you and get the necessary dev
>> support to get this resolved sooner than later. I totally agree with you
>> that this should be backported to at least Liberty.
>>
>> Please let me know how I and other can help!
>>
>> —Joe
>>
>>
Summary: Liberty OVS agent restarts are better, but still need work.
See: https://bugs.launchpad.net/neutron/+bug/1514056
As many of you know, Liberty has a fix for OVS agent restarts such
that it doesn’t dump all flows when starting, resulting in a loss of
traffic. Unfortunately, Liberty
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
+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
+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
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
+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
I believe this is coming in Liberty, based on this talk:
https://www.openstack.org/summit/tokyo-2015/videos/presentation/get-your-instance-by-name-integration-of-nova-neutron-and-designate
On Thu, Nov 19, 2015 at 7:10 AM, Davíð Örn Jóhannsson
wrote:
> I've been looking into
On Wed, Nov 18, 2015 at 4:24 PM, Erik McCormick
wrote:
> > 2) More technically we'll need to address the challenge of local
> > sound, how to we ensure all the mostly spontaious talk in a large work
> > session makes it to remote participants. Passing a mic is a bit
On Tue, Nov 17, 2015 at 12:56 PM, JJ Asghar wrote:
> Yep, that's the can o'worms I was talking about. I was thinking that we
> could just steal this .rubocop.yml[1], as it's a "sane" default for us
> at Chef. If you take a look at it you'll see its pretty simple which is
> what
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
I think it’s a good idea. I think scripts and such that don’t pass the
listing tools can go into the contrib repos and if they get cleaned up then
they can move over to the regular ones.
I don’t actually like some of the PEP8 and bashate rules, but I’d rather
have a consistent style than have
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
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
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
As many of you know, Liberty includes a bug fix for OVS L2 agent dropping
all flows when it starts up. Since this is a bug, I’d like to see this
back ported to Kilo if possible.
We’re planning to do an upgrade to the latest stable/kilo because of the
Nova NUMA issue anyway and we’re still using
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
>
+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
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
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
ion.
On Mon, Sep 14, 2015 at 7:18 AM, Flavio Percoco <fla...@redhat.com> wrote:
> On 09/09/15 21:46 -0400, Clayton O'Neill wrote:
>
>> I'd be glad to see the backwards compatibility parts go in. I got bitten
>> by
>> this earlier this week and ended up switching my s
I'd be glad to see the backwards compatibility parts go in. I got bitten
by this earlier this week and ended up switching my scripts over to using
the python-openstackclient library to work around it.
On Wed, Sep 9, 2015 at 6:41 PM, Nikhil Komawar
wrote:
> Hi all,
>
> We
We're using nodepool for our internal CI process and find it to be a great
tool. We've recently made a change to our development environment build
tools to allow us to test VRRP load balancing and overlay networking inside
of instances. We use Vagrant for building those dev environments and
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
+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
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
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 rich...@raseley.com
wrote:
Matt Fischer wrote:
+1 from me for deprecation.
I'd also like to know or have an
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).
]
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
]
Sent: Monday, June 08, 2015 11:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: openstack-operators@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
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
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
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
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
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
Thanks Tom! Are there any details regarding hotel accommodations?
It's not official, but several us from Time Warner Cable are staying at
http://www.thewindsorsuites.com/ which appears to be fairly close and
reasonably priced for the area.
___
45 matches
Mail list logo