+1 from me, long overdue!
On May 28, 2015, at 9:42 AM, Kyle Mestery mest...@mestery.com wrote:
Folks, I'd like to propose Assaf Muller to be a member of the Neutron core
reviewer team. Assaf has been a long time contributor in Neutron, and he's
also recently become my testing
On Apr 24, 2015, at 6:17 AM, Luke Gorrie l...@tail-f.com wrote:
Question regarding your candidacy:
If I recall correctly you have spoken in favor of face to face discussions at
mid-cycle meetings as a practical way to set priorities and move things
forward. What are your current
On Apr 23, 2015, at 9:14 AM, Chris Dent chd...@redhat.com wrote:
What can and should the TC at large, and you specifically, do to ensure
quality improves for the developers, end-users and operators of
OpenStack as a full system, both as a project being developed and a
product being used?
My name is Maru Newby, and I am announcing my candidacy for the
Technical Committee (TC) election.
tl;dr;
I'm a relative unknown outside of Neutron, but I've been helping to drive
high-level change in that project. I would welcome the opportunity to bring my
energy and dedication to OpenStack
On Apr 10, 2015, at 11:04 AM, Boris Pavlovic bo...@pavlovic.me wrote:
Hi,
I believe that specs are too detailed and too dev oriented for managers,
operators and devops.
They actually don't want/have time to write/read all the stuff in specs and
that's why the communication between
On Apr 2, 2015, at 3:26 AM, Thierry Carrez thie...@openstack.org wrote:
Maru Newby wrote:
[...] Many of us in the Neutron
community find this taxonomy restrictive and not representative
of all the work that makes the project possible.
We seem to be after the same end goal. I just
On Apr 2, 2015, at 9:02 AM, Thierry Carrez thie...@openstack.org wrote:
Maru Newby wrote:
On Apr 2, 2015, at 3:26 AM, Thierry Carrez thie...@openstack.org wrote:
What we need to do instead is reviving the drivers concept (we can
rename it maintainers if you really like that term), separate
On Apr 1, 2015, at 6:09 AM, Jeremy Stanley fu...@yuggoth.org wrote:
And here is the crux of the situation, which I think bears
highlighting. These empowered groups are (or at least started out
as) nothing more than an attempt to map responsibilities onto the
ACLs available to our projects
On Apr 1, 2015, at 1:47 PM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-04-01 12:00:53 -0700 (-0700), Maru Newby wrote:
Given how important trust and relationships are to the functioning
of individual projects, I think we’re past the point where we
should allow our tooling
On Apr 1, 2015, at 2:52 AM, Thierry Carrez thie...@openstack.org wrote:
- Some people are core reviewers and maintainers (or drivers, to reuse
the openstack terminology we already have for that)
- Some people are core reviewers only (because they can't commit 90% of
their work time to work
On Mar 25, 2015, at 4:22 PM, Monty Taylor mord...@inaugust.com wrote:
On 03/25/2015 05:50 PM, Maru Newby wrote:
I am excited by the release of YAPF [1], a gofmt-like too for python.
I think it has the potential to simplify style enforcement, and as
much as I appreciate our current hacking
I am excited by the release of YAPF [1], a gofmt-like too for python. I think
it has the potential to simplify style enforcement, and as much as I appreciate
our current hacking checks, I’d be much happier not requiring developers to
manually conform to them. Maybe we can consider automation
tl;dr; As per a discussion in Paris [1], development of Neutron's
API tests is moving from the Tempest repo to the Neutron repo.
If you are developing API tests for Neutron in Tempest, please be
advised that, effective immediately, your efforts should be
directed towards the Neutron repo.
The
+1 from me, Ihar has been doing great work and it will be great to have him
finally able to merge!
On Mar 4, 2015, at 11:42 AM, Kyle Mestery mest...@mestery.com wrote:
I'd like to propose that we add Ihar Hrachyshka to the Neutron core reviewer
team. Ihar has been doing a great job
There have been a couple of patches [1] [2] proposed to neutron recently that
could impact our support for Xen+OVS, but I don’t see an easy way for us to
validate such changes. I’m not aware of a 3rd party CI job that runs against
Xen, and I don’t know of any active contributors able to
, I’ve cross-posted to the user list as you suggest.
On Tue, Mar 3, 2015 at 12:50 PM, Maru Newby ma...@redhat.com wrote:
There have been a couple of patches [1] [2] proposed to neutron recently that
could impact our support for Xen+OVS, but I don’t see an easy way for us to
validate
be a
large deployment out there with resources willing to at least test changes
even if they don't have any upstream development resources.
On Tue, Mar 3, 2015 at 12:50 PM, Maru Newby ma...@redhat.com wrote:
There have been a couple of patches [1] [2] proposed to neutron recently that
could
+1 to Doug’s addition. He’s been a workhorse in moving lbaas and the services
split forward and his being able to finally merge code in the main repo should
be a boon to our merge velocity.
Many thanks to Sumit for his long-serving dedication as a core reviewer. I
hope to see him return to
As per a recent exchange on #openstack-neutron, I’ve been asked to present my
views on this effort. What follows is in no way intended to detract from the
hard work and dedication of those undertaking it, but I think that their energy
could be better spent.
At nova’s juno mid-cycle in July,
On Jan 8, 2015, at 3:54 PM, Sean Dague s...@dague.net wrote:
On 01/08/2015 06:41 PM, Maru Newby wrote:
As per a recent exchange on #openstack-neutron, I’ve been asked to present
my views on this effort. What follows is in no way intended to detract from
the hard work and dedication
On Dec 12, 2014, at 1:40 PM, Sean Dague s...@dague.net wrote:
On 12/12/2014 01:05 PM, Maru Newby wrote:
On Dec 11, 2014, at 2:27 PM, Sean Dague s...@dague.net wrote:
On 12/11/2014 04:16 PM, Jay Pipes wrote:
On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:
On Dec 11, 2014, at 1:04 PM
:
On 12/12/2014 01:05 PM, Maru Newby wrote:
On Dec 11, 2014, at 2:27 PM, Sean Dague s...@dague.net wrote:
On 12/11/2014 04:16 PM, Jay Pipes wrote:
On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:
On Dec 11, 2014, at 1:04 PM, Jay Pipes jaypi...@gmail.com
wrote:
On 12/11/2014 04:01 PM
On Dec 11, 2014, at 2:27 PM, Sean Dague s...@dague.net wrote:
On 12/11/2014 04:16 PM, Jay Pipes wrote:
On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:
On Dec 11, 2014, at 1:04 PM, Jay Pipes jaypi...@gmail.com wrote:
On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
On Dec 11, 2014, at
On Dec 9, 2014, at 7:04 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Tue, Dec 09, 2014 at 10:53:19AM +0100, Maxime Leroy wrote:
I have also proposed a blueprint to have a new plugin mechanism in
nova to load external vif driver. (nova-specs:
https://review.openstack.org/#/c/136827/
On Dec 7, 2014, at 10:51 AM, Gary Kotton gkot...@vmware.com wrote:
Hi Kyle,
I am not missing the point. I understand the proposal. I just think that it
has some shortcomings (unless I misunderstand, which will certainly not be
the first time and most definitely not the last). The thinning
Am I the only one wondering whether introducing arbitrary tagging into our
commit messages sets a bad precedent? Or was there a discussion on this topic
that I missed?
Maru
On Jun 17, 2014, at 2:27 PM, Sylvain Bauza sba...@redhat.com wrote:
Hi,
There is an action for creating a Gerrit
On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@huawei.com wrote:
Hi,
I’m not sure whether following issue is problematic, and both, our team do
some effort, so I submit two blueprints:
[1.] optimize dvr flows:
Currently, accurate ovs flows in terms of full mac are used to
On Oct 29, 2014, at 12:25 PM, Steve Gordon sgor...@redhat.com wrote:
- Original Message -
From: Maru Newby ma...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Am I the only one wondering whether introducing arbitrary
On Oct 29, 2014, at 1:36 PM, Hly henry4...@gmail.com wrote:
Sent from my iPad
On 2014-10-29, at 下午6:33, Maru Newby ma...@redhat.com wrote:
On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@huawei.com wrote:
Hi,
I’m not sure whether following issue is problematic, and both
On Oct 22, 2014, at 12:53 AM, Jakub Libosvar libos...@redhat.com wrote:
On 10/22/2014 02:26 AM, Maru Newby wrote:
We merged caching support for the metadata agent in juno, and backported to
icehouse. It was enabled by default in juno, but disabled by default in
icehouse to satisfy
We merged caching support for the metadata agent in juno, and backported to
icehouse. It was enabled by default in juno, but disabled by default in
icehouse to satisfy the stable maint requirement of not changing functional
behavior.
While performance of the agent was improved with caching
For legacy reasons, the Neutron test suite creates and destroys a db for each
test. There is a patch proposed to create the tables once and then ensure the
tables are wiped at the end of each test [1], providing a performance
improvement of ~10%. I was wondering if this is the best way to
On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com
wrote:
On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.com wrote:
On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi)
pkila...@cisco.com wrote:
On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote
On Aug 27, 2014, at 1:47 AM, Salvatore Orlando sorla...@nicira.com wrote:
TL; DR
A few folks are proposing to stop running tests for neutron advanced services
[ie: (lb|vpn|fw)aas] in the integrated gate, and run them only on the neutron
gate.
Reason: projects like nova are 100%
On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com
wrote:
On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote:
On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com
wrote:
On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com
in Neutron’s requirements.txt?
On 24 Aug 2014 10:43, Maru Newby ma...@redhat.com wrote:
On Aug 14, 2014, at 1:55 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:
Signed PGP part
FYI: I've uploaded a review for openstack/requirements to add the
upstream module into the list of potential
On Aug 24, 2014, at 5:14 PM, Henry Gessau ges...@cisco.com wrote:
Ihar Hrachyshka ihrac...@redhat.com wrote:
Now, maybe putting the module into requirements.txt is an overkill
(though I doubt it). In that case, we could be interested in getting
the info in some other centralized way.
Maru
Kevin Benton has proposed adding a runtime check for netns permission problems:
https://review.openstack.org/#/c/109736/
There seems to be consensus on the patch that this is something that we want to
do at runtime, but that would seem to run counter to the precedent that
host-specific issues
On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:
On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote:
On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 20/08/14
On Aug 20, 2014, at 6:28 PM, Salvatore Orlando sorla...@nicira.com wrote:
Some comments inline.
Salvatore
On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
I've read the proposal for incubator as described
On Aug 14, 2014, at 1:55 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:
Signed PGP part
FYI: I've uploaded a review for openstack/requirements to add the
upstream module into the list of potential dependencies [1]. Once it's
merged, I'm going to introduce this new requirement for Neutron.
On Aug 14, 2014, at 8:52 AM, Russell Bryant rbry...@redhat.com wrote:
On 08/14/2014 11:40 AM, David Kranz wrote:
On 08/14/2014 10:54 AM, Matt Riedemann wrote:
On 8/14/2014 3:47 AM, Daniel P. Berrange wrote:
On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote:
On Thu, Aug 14,
On Aug 13, 2014, at 10:32 PM, Michael Still mi...@stillhq.com wrote:
On Thu, Aug 14, 2014 at 2:48 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com wrote:
On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote:
Just
On Aug 13, 2014, at 11:11 AM, Kevin Benton blak...@gmail.com wrote:
Is the pylint static analysis that caught that error prone to false
positives? If not, I agree that it would be really nice if that were made
part of the tox check so these don't have to be fixed after the fact.
To me that
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
Hi.
One of the action items from the nova midcycle was that I was asked to
make nova's expectations of core reviews more clear. This email is an
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
Hi.
One of the action items from the nova midcycle was that I was asked to
make nova's expectations of core reviews more clear. This email is an
My apologies, I managed to break the thread here. Please respond to the thread
with subject 'Re: [openstack-dev] [nova][core] Expectations of core reviewers'
in preference to this one.
Maru
On Aug 13, 2014, at 9:01 AM, Maru Newby ma...@redhat.com wrote:
On Aug 13, 2014, at 2:57 AM
+1
Maru
On Aug 13, 2014, at 7:05 AM, Kyle Mestery mest...@mestery.com wrote:
Per this week's Neutron meeting [1], it was decided that offering a
rotating meeting slot for the weekly Neutron meeting would be a good
thing. This will allow for a much easier time for people in
Asia/Pacific
On Aug 8, 2014, at 10:56 AM, Kevin Benton blak...@gmail.com wrote:
There is an enforcement component to the group policy that allows you to use
the current APIs and it's the reason that group policy is integrated into the
neutron project. If someone uses the current APIs, the group policy
On Jul 17, 2014, at 8:12 AM, Kyle Mestery mest...@mestery.com wrote:
On Thu, Jul 17, 2014 at 6:42 AM, Thierry Carrez thie...@openstack.org wrote:
Kyle Mestery wrote:
As we're getting down to the wire in Juno, I'd like to propose we have
a weekly meeting on the nova-network and neutron parity
At the summit session last week for group-based policy, there were many
concerns voiced about the approach being undertaken. I think those concerns
deserve a wider audience, and I'm going to highlight some of them here.
The primary concern seemed to be related to the complexity of the approach
On May 22, 2014, at 11:03 AM, Maru Newby ma...@redhat.com wrote:
At the summit session last week for group-based policy, there were many
concerns voiced about the approach being undertaken. I think those concerns
deserve a wider audience, and I'm going to highlight some of them here
,
Armando
On 22 May 2014 11:38, Maru Newby ma...@redhat.com wrote:
On May 22, 2014, at 11:03 AM, Maru Newby ma...@redhat.com wrote:
At the summit session last week for group-based policy, there were many
concerns voiced about the approach being undertaken. I think those
concerns
is to recognize that the POC is best considered a prototype useful in informing
efforts to iterate in the open.
m.
On Thu, May 22, 2014 at 4:03 PM, Maru Newby ma...@redhat.com wrote:
On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com wrote:
Maru's concerns are that:
1
On May 21, 2014, at 1:59 PM, Kyle Mestery mest...@noironetworks.com wrote:
Neutron cores, please vote +1/-1 for the proposed addition of Carl
Baldwin to Neutron core.
+1 from me
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
The patch in question is doing an invasive runtime check [1] to determine
whether arp header modification is supported by ovs. I seem to remember a lack
of consensus on whether invasive runtime checks were acceptable around vxlan
detection, and I would appreciate confirmation from other cores
Memory usage due to plugin+mock leakage is addressed by the following patch:
https://review.openstack.org/#/c/92793/
I'm seeing residual (post-test) memory usage decrease from ~4.5gb to ~1.3gb
with 12 concurrent test runners. Of the 1.3gb, sqlalchemy is taking the lion
share at ~500mb, so
On Mar 26, 2014, at 12:59 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Tue, Mar 25, 2014 at 1:49 AM, Maru Newby ma...@redhat.com wrote:
On Mar 21, 2014, at 9:01 AM, David Kranz dkr...@redhat.com wrote:
On 03/20/2014 04:19 PM, Rochelle.RochelleGrober wrote:
-Original
On Mar 26, 2014, at 1:52 PM, Sean Dague s...@dague.net wrote:
On 03/25/2014 04:49 AM, Maru Newby wrote:
On Mar 21, 2014, at 9:01 AM, David Kranz dkr...@redhat.com wrote:
On 03/20/2014 04:19 PM, Rochelle.RochelleGrober wrote:
-Original Message-
From: Malini Kamalambal
that such tests could be
run either as part of today's real tempest runs or mocked in various ways
to allow component isolation or better performance. Maru Newby posted a patch
with an example of one way to do this but I think it expired and I don't have
a pointer.
I think the best place
+1
I think there should be naming standard for all reviews (e.g. [test] Jenkins,
[test-external] VMware) so that gerrit css can colorize automatic review
comments no matter the project.
m.
On Mar 7, 2014, at 2:08 AM, Chmouel Boudjnah chmo...@enovance.com wrote:
if peoples like this why
At the last 2 summits, I've suggested that API tests could be maintained in the
Neutron tree and reused by Tempest. I've finally submitted some patches that
demonstrate this concept:
https://review.openstack.org/#/c/72585/ (implements a unit test for the
lifecycle of the network resource)
On Feb 12, 2014, at 12:36 PM, Sean Dague s...@dague.net wrote:
On 02/12/2014 01:48 PM, Maru Newby wrote:
At the last 2 summits, I've suggested that API tests could be maintained in
the Neutron tree and reused by Tempest. I've finally submitted some patches
that demonstrate this concept
On Feb 12, 2014, at 1:59 PM, Sean Dague s...@dague.net wrote:
On 02/12/2014 04:25 PM, Maru Newby wrote:
On Feb 12, 2014, at 12:36 PM, Sean Dague s...@dague.net wrote:
On 02/12/2014 01:48 PM, Maru Newby wrote:
At the last 2 summits, I've suggested that API tests could be maintained
I'm afraid I missed this topic the first time around, and I think it bears
revisiting.
tl;dr: I think we should consider ensuring gate stability in the face of
resource-starved services by some combination of more intelligent test design
and better handling of resource starvation (for example,
I recently saw a case [1] where a misspelled assertion method
(asoptt_called_once_with vs assert_called_once_with) did not result in a test
failure because the object it was called on was created by mock.patch() without
any of the spec/spec_set/autospec parameters being set. Might it make
On Dec 13, 2013, at 8:06 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
On Fri, Dec 06, 2013 at 04:30:17PM +0900,
Maru Newby ma...@redhat.com wrote:
On Dec 5, 2013, at 5:21 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
On Wed, Dec 04, 2013 at 12:37:19PM +0900,
Maru Newby ma
As per Anita's email, we're not to approve anything until the following tox fix
merges: https://review.openstack.org/#/c/60825
Please keep an eye on the change, and once it merges, make sure that the
following patches merge before regular approval rules resume:
On Dec 10, 2013, at 4:47 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
On Tue, Dec 10, 2013 at 07:28:10PM +1300,
Robert Collins robe...@robertcollins.net wrote:
On 10 December 2013 19:16, Isaku Yamahata isaku.yamah...@gmail.com wrote:
Answering myself. If connection is closed, it
On Dec 5, 2013, at 4:43 PM, Édouard Thuleau thul...@gmail.com wrote:
There also another bug you can link/duplicate with #1192381 is
https://bugs.launchpad.net/neutron/+bug/1185916.
I proposed a fix but it's not the good way. I abandoned it.
Édouard.
Thank you for pointing this out!
m.
On Dec 10, 2013, at 6:36 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
On Mon, Dec 09, 2013 at 08:43:59AM +1300,
Robert Collins robe...@robertcollins.net wrote:
listening: when an agent connects after an outage, it first starts
listening, then does a poll for updates it missed.
Are
On Dec 11, 2013, at 8:39 AM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
On Wed, Dec 11, 2013 at 01:23:36AM +0900,
Maru Newby ma...@redhat.com wrote:
On Dec 10, 2013, at 6:36 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
On Mon, Dec 09, 2013 at 08:43:59AM +1300,
Robert Collins
Are any other projects interested in adding back the post-mortem debugging
support we lost in the move away from nose? I have a patch in review for
neutron and salv-orlando asked whether oslo might be the better place for it.
https://review.openstack.org/#/c/43776/
m.
On Dec 7, 2013, at 6:21 PM, Robert Collins robe...@robertcollins.net wrote:
On 7 December 2013 21:53, Isaku Yamahata isaku.yamah...@gmail.com wrote:
Case 3: Hardware failure. So an agent on the node is gone.
Another agent will run on another node.
If AMQP service is set up not to
On Dec 3, 2013, at 12:18 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Sun, Dec 1, 2013 at 7:04 PM, John Dickinson m...@not.mn wrote:
Just to add to the story, Swift uses X-Trans-Id and generates it in the
outer-most catch_errors middleware.
Swift's catch errors middleware is
On Dec 5, 2013, at 6:43 AM, Carl Baldwin c...@ecbaldwin.net wrote:
I have offered up https://review.openstack.org/#/c/60082/ as a
backport to Havana. Interest was expressed in the blueprint for doing
this even before this thread. If there is consensus for this as the
stop-gap then it is
On Dec 5, 2013, at 5:21 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
On Wed, Dec 04, 2013 at 12:37:19PM +0900,
Maru Newby ma...@redhat.com wrote:
In the current architecture, the Neutron service handles RPC and WSGI with a
single process and is prone to being overloaded
On Dec 6, 2013, at 1:09 AM, John Dickinson m...@not.mn wrote:
On Dec 5, 2013, at 1:36 AM, Maru Newby ma...@redhat.com wrote:
On Dec 3, 2013, at 12:18 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Sun, Dec 1, 2013 at 7:04 PM, John Dickinson m...@not.mn wrote:
Just to add
. I intend to submit a fix
that ensures that notifications are sent regardless of agent status, in any
case.
m.
Carl
On Tue, Dec 3, 2013 at 9:47 AM, Stephen Gran
stephen.g...@theguardian.com wrote:
On 03/12/13 16:08, Maru Newby wrote:
I've been investigating a bug that is preventing
On Dec 4, 2013, at 6:34 PM, Yair Fried yfr...@redhat.com wrote:
Hi
In tempest.conf, Is the parameter tenant_networks_reachable affected by
anything other than neutron using ip name-spaces (which is the default
setting) or not, and if not using it - if the tempest host is the same as the
I've been investigating a bug that is preventing VM's from receiving IP
addresses when a Neutron service is under high load:
https://bugs.launchpad.net/neutron/+bug/1192381
High load causes the DHCP agent's status updates to be delayed, causing the
Neutron service to assume that the agent is
I recently ran into this bug while trying to concurrently boot a large number
(75) of VMs:
https://bugs.launchpad.net/neutron/+bug/1160442
I see that the fix for the bug added configuration of SQLAlchemy QueuePool
parameters that should prevent the boot failures I was seeing. However, I
On Dec 4, 2013, at 1:47 AM, Stephen Gran stephen.g...@theguardian.com wrote:
On 03/12/13 16:08, Maru Newby wrote:
I've been investigating a bug that is preventing VM's from receiving IP
addresses when a Neutron service is under high load:
https://bugs.launchpad.net/neutron/+bug/1192381
child processes.
Carl
On Tue, Dec 3, 2013 at 9:47 AM, Stephen Gran
stephen.g...@theguardian.com wrote:
On 03/12/13 16:08, Maru Newby wrote:
I've been investigating a bug that is preventing VM's from receiving IP
addresses when a Neutron service is under high load:
https
On Dec 4, 2013, at 11:57 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Maru Newby's message of 2013-12-03 08:08:09 -0800:
I've been investigating a bug that is preventing VM's from receiving IP
addresses when a Neutron service is under high load:
On Dec 2, 2013, at 10:19 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Dec 2, 2013 3:39 AM, Maru Newby ma...@redhat.com wrote:
On Dec 2, 2013, at 2:07 AM, Anita Kuno ante...@anteaya.info wrote:
Great initiative putting this plan together, Maru. Thanks for doing
this. Thanks
hope that some additional individuals come forward to
help with this.
Thanks Maru, Salvatore and Armando,
Anita.
[0]
https://blueprints.launchpad.net/neutron/+spec/log-only-exceptional-conditions-as-error
On 11/30/2013 08:24 PM, Maru Newby wrote:
On Nov 28, 2013, at 1:08 AM, Salvatore
On Nov 30, 2013, at 1:00 AM, Sean Dague s...@dague.net wrote:
On 11/29/2013 10:33 AM, Jay Pipes wrote:
On 11/28/2013 07:45 AM, Akihiro Motoki wrote:
Hi,
I am working on adding request-id to API response in Neutron.
After I checked what header is used in other projects
header name varies
.
Salvatore
On 27 November 2013 17:50, Maru Newby ma...@redhat.com wrote:
Just a heads up, the console output for neutron gate jobs is about to get a
lot noisier. Any log output that contains 'ERROR' is going to be dumped into
the console output so that we can identify and eliminate
Keystone is almost finished replacing the term 'tenant' with 'project' (see
recent thread
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09709.html)
and we might want to think about how and when Neutron makes a similar
transition. It's an unlikely priority in the near term
The tenant isolation gates that have been failing so frequently seem to be
passing all of a sudden. I didn't see any merges that claimed to fix the
issue, so maybe this is just a lull due to a lower volume of gate jobs. If it
was intentional, though, I would appreciate knowing which patch or
...@gmail.com, Edgar Magana emag...@plumgrid.com, Maru Newby
ma...@redhat.com, Nachi Ueno na...@nttmcl.com, Salvatore Orlando
sorla...@nicira.com, Sumit Naiksatam sumit.naiksa...@bigswitch.com, Mark
McClain mark.mccl...@dreamhost.com, Gary Kotton gkot...@vmware.com,
Robert Kukura rkuk...@redhat.com
under review? Switching to
non multi-host under the current proposal involves reconfiguring and restarting
of an awful lot of agents, to say nothing of the db changes.
m.
On Tue, Aug 27, 2013 at 9:14 AM, Maru Newby ma...@redhat.com wrote:
On Aug 26, 2013, at 4:06 PM, Edgar Magana emag
On Aug 26, 2013, at 10:23 AM, Dean Troyer dtro...@gmail.com wrote:
On Mon, Aug 26, 2013 at 10:50 AM, Maru Newby ma...@redhat.com wrote:
Is anyone working on/planning on adding support for neutron to grenade? Or
is there any other automated upgrade testing going on for neutron?
We
On Aug 27, 2013, at 3:27 PM, Tom Fifield t...@openstack.org wrote:
On 27/08/13 15:23, Maru Newby wrote:
On Aug 26, 2013, at 9:39 PM, Yongsheng Gong gong...@unitedstack.com wrote:
First 'be like nova-network' is a merit for some deployments.
I'm afraid 'merit' is a bit vague for me
Is anyone working on/planning on adding support for neutron to grenade? Or is
there any other automated upgrade testing going on for neutron?
Thanks,
m.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On Aug 15, 2013, at 12:50 PM, Joe Gordon joe.gord...@gmail.com wrote:
•
On Thu, Aug 15, 2013 at 12:22 PM, Sam Harwell sam.harw...@rackspace.com
wrote:
I like to take a different approach. If my commit message is going to take
more than a couple lines for people to understand the
On Aug 16, 2013, at 2:12 AM, Robert Collins robe...@robertcollins.net wrote:
On 16 August 2013 20:15, Maru Newby ma...@redhat.com wrote:
This pattern has one slight issue, which is:
• Do not assume the reviewer has access to external web services/site.
In 6 months time when someone
Neutron has been in and out of the gate for the better part of the past month,
and it didn't slow the pace of development one bit. Most Neutron developers
kept on working as if nothing was wrong, blithely merging changes with no
guarantees that they weren't introducing new breakage. New bugs
99 matches
Mail list logo
