Thanks for doing this. A couple of questions:
What were your rootwrap settings when running these tests? Did you just
have it calling sudo directly?
Also, you mention that this is only ~10% of the time spent during flow
reconfiguration. What other areas are eating up so much time?
Welcome to the Community.
If you do not know where to start, I'd suggest to read this wiki page .
Because you've mentioned Neutron, you can join #openstack-neutron channel on
Freenode and talk to other people there.
Kilo release is currently considered stable, so just bugfix are
On 18/01/16 07:22, Sirisha Guduru wrote:
> ³VolumeTypeList² for admin is enabled in the master release of openstack
> horizon, where an admin can see all the volume types listed in horizon.
> The same is not implemented in liberty. Can we back port the code from
> master to liberty to
I just realized that 1/18 is an official holiday in the US so I'm not sure how
many people will be available this time, I'll start the meeting and we can
always cut it short if there isn't a quorum.
Meeting on #openstack-meeting-alt at 1400 UTC (7:00AM MDT)
1) Spec & BPs & Patches -
Prior attempts to solve the MTU problem in neutron simply band-aid it or
become too complex from feature creep or edge cases that mask the primary
goal of a simple implementation that works for most deployments. So, I ran
some experiments to empirically determine the root cause of MTU problems in
³VolumeTypeList² for admin is enabled in the master release of openstack
horizon, where an admin can see all the volume types listed in horizon.
The same is not implemented in liberty. Can we back port the code from
master to liberty to meet the requirement or should it be implemented
On Fri, 2016-01-15 at 20:48 +0800, Thomas Goirand wrote:
> This isn't the first time I'm calling for it. Let's hope this time,
> I'll be heard.
> Randomly, contributors put their company names into source code. When
> they do, then effectively, this tells that a given source file
On Fri, 2016-01-15 at 15:38 +, Daniel P. Berrange wrote:
> On Fri, Jan 15, 2016 at 08:48:21PM +0800, Thomas Goirand wrote:
> > This isn't the first time I'm calling for it. Let's hope this time,
> > I'll
> > be heard.
> > Randomly, contributors put their company names into source code.
I am a newbie in an Open Stack developers community. I want to do some
modification in Devstack/kilo neutron part. Can anyone guide me how to test the
modification in the code part.
(1) Should I need to define my own module/class.
(2) Can I add some def in neutron code.
Updating the label code in django_openstack_auth isn't an option since
it would mean forking and maintaining our own copy of the library for
most likely one line of code.
Diana, any clue how would I go about overriding the label solely with
code placed in Horizon? Ideally we'd like to just place
Excerpts from Thomas Goirand's message of 2016-01-16 22:36:23 -0800:
> On 01/16/2016 10:16 PM, Jeremy Stanley wrote:
> > On 2016-01-16 12:14:20 +0800 (+0800), Thomas Goirand wrote:
> > [...]
> >> I've just asked this very point with the same example to the FTP
> >> masters. Let's see what they
As many of you know, Murano actions is the Murano way to do something
to applications that are already deployed using simple ReST API. For
example, health monitoring system may trigger an action on high CPU
load so that application could scale itself up.
However there are several
On Fri, Jan 15, 2016 at 12:48:51PM +, Chris Dent wrote:
> At yesterday's API Working Group meeting we decided it would be a
> good idea to send out a refresher on the existence of the group,
> its goals and activities. If you have interest in the improvement
> and standardization of
I'm sending out this mail to share the finding and discuss how to
improve with those interested in neutron ovs performance.
TL;DR: The native of_interface code, which has been merged recently
and isn't default, seems to consume less CPU time but gives a mixed
result. I'm looking into this for
This patch got approval long back(Jan 6) but due to Jenkins failure in the
merge pipeline of the Kilo branch, this patch was not merged.
Hence I request for an exception for this patch as this was not merged due
to Jenkins issue.
The Secret Of Success is
On Sat, Jan 16, 2016 at 5:34 AM, Harm Weites wrote:
> Hi guys,
> As Steven noted, activity from my side has dropped significantly, and with
> +2 comes a certain responsibility of at the very least keeping track of the
> codebase. Various reasons keep me from even doing that so
I am still in favor on associating the subnets to the LB and then not specify
them per node at all.
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Sunday, January 17, 2016 10:14 AM
To: OpenStack Development Mailing List (not for usage
On Sun, Jan 17, 2016 at 1:29 PM, Steven Dake (stdake)
> I read your response and the idea of incubators is interesting, but the
> risk there is we will end up with "two core teams" with different
> objectives, purpose, focus, and most importantly a lack of
This spec proposes a new Heat resource type - OS::Mistral::WorkflowExecution .
This new resource type will enable more control on execution of Mistral
workflows when deploying a service in heat.
Specifically it will provide feedback whether the execution succeeded or
failed, which is important
Subnet should be mandatory
The only thing this makes supporting load balancing servers which are not
running in the cloud more challenging to support.
But I do not see this as a huge user story (lb in cloud load balancing IPs
outside the cloud)
On 01/17/2016 05:29 AM, Steven Dake (stdake) wrote:
I read your response and the idea of incubators is interesting, but the
risk there is we will end up with "two core teams" with different
objectives, purpose, focus, and most importantly a lack of coordinated
efforts and thinking. I'd
Removing the clouds.yaml did not help. It causes the following error:
8:48:28.810 | SCREEN_LOGDIR:
2016-01-17 08:48:28.810 | log: /opt/stack/logs/g-reg.log.2016-01-17-004213
2016-01-17 08:48:31.857 | Waiting for g-api (openstack-server:9292) to
2016-01-17 08:49:33.081 | Named
I've created a review: https://review.openstack.org/#/c/268774/
On 1/8/16 3:45 PM, Thierry Carrez wrote:
Alexandre Levine wrote:
The ec2-api project is in gating and totally functional. We'll apply for
it to become OpenStack project very shortly. Next week in fact.
Since we're growing and if anything, more people will join kolla from
APAC (we already see few new faces this release), I'd vote for
re-introducing apac-friendly meeting. We'll need to do it anyway at
On 17 January 2016 at 03:26, Martin André
On 2016-01-17 14:36:23 +0800 (+0800), Thomas Goirand wrote:
> What I wrote is that I feel like the currently situation makes it
> very blurry for one to tell who is the copyright holder(s). I'm
> seeking a way to fix this.
I fail to see what's blurry about it. The contributors who feel
Mail list logo