On Aug 8, 2014, at 10:56 AM, Kevin Benton 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 plugin
> will ma
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange 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
>> attempt at that
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange 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
>> attempt at that
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 wrote:
>
> On Aug 13, 2014, at 2:57 AM, Da
+1
Maru
On Aug 13, 2014, at 7:05 AM, Kyle Mestery 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 timezones, as well
On Aug 13, 2014, at 11:11 AM, Kevin Benton 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 particular p
On Aug 14, 2014, at 8:52 AM, Russell Bryant 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 wrote:
> On Thu, Aug 14, 2014 at 2:48 PM, Joe Gordon wrote:
>> On Wed, Aug 13, 2014 at 8:31 PM, Michael Still wrote:
>>> On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes wrote:
>>>
Just wanted to quickly weigh in with my thoughts on this important
>
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 s
On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam wrote:
> On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery wrote:
>> On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> On 20/08/14 18:28, Salvatore Orlando wrote:
Some comments
On Aug 20, 2014, at 6:28 PM, Salvatore Orlando wrote:
> Some comments inline.
>
> Salvatore
>
> On 20 August 2014 17:38, Ihar Hrachyshka wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Hi all,
>>
>> I've read the proposal for incubator as described at [1], and I have
>
On Aug 14, 2014, at 1:55 PM, Ihar Hrachyshka 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.
The only reason s
On Aug 24, 2014, at 5:14 PM, Henry Gessau wrote:
> Ihar Hrachyshka 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 is of the opinion that it
tron’s requirements.txt?
> On 24 Aug 2014 10:43, "Maru Newby" wrote:
>
> On Aug 14, 2014, at 1:55 PM, Ihar Hrachyshka wrote:
>
> > Signed PGP part
> > FYI: I've uploaded a review for openstack/requirements to add the
> > upstream module into the list of potentia
On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi)
wrote:
>
>
> On 8/23/14, 5:36 PM, "Maru Newby" wrote:
>
>>
>> On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam
>> wrote:
>>
>>> On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery
On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi)
wrote:
>
>
> On 8/26/14, 4:49 AM, "Maru Newby" wrote:
>
>>
>> On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi)
>> wrote:
>>
>>>
>>>
>>> On 8/23/14,
On Aug 27, 2014, at 1:47 AM, Salvatore Orlando 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% orthogonal to neutron
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 prov
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
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 unnecessary error logging.
Once we've cleaned things up, the presence of unexpected
ught earlier.
m.
>
> Salvatore
>
>
> On 27 November 2013 17:50, Maru Newby 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 co
eve this but I will be flying (wifi
> uncertain). I do 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-erro
On Nov 30, 2013, at 1:00 AM, Sean Dague 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 vari
On Dec 2, 2013, at 10:19 PM, Joe Gordon wrote:
>
> On Dec 2, 2013 3:39 AM, "Maru Newby" wrote:
> >
> >
> > On Dec 2, 2013, at 2:07 AM, Anita Kuno wrote:
> >
> > > Great initiative putting this plan together, Maru. Thanks for doing
> >
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 do
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
don'
On Dec 4, 2013, at 1:47 AM, Stephen Gran 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/
n more than one physical host in
> combination with multiple child processes.
>
> Carl
>
> On Tue, Dec 3, 2013 at 9:47 AM, Stephen Gran
> wrote:
> > On 03/12/13 16:08, Maru Newby wrote:
> >>
> >> I've been investigating a bug that is preventing VM'
On Dec 4, 2013, at 11:57 AM, Clint Byrum 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:
>>
>> https://bugs.launchpad.net/neutron/+bug/11
means that the problem of
dhcp notifications being dropped is little improved. 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
> wrote:
>> On 03/12/13 1
On Dec 4, 2013, at 6:34 PM, Yair Fried 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
> neutron ser
On Dec 3, 2013, at 12:18 AM, Joe Gordon wrote:
>
>
>
> On Sun, Dec 1, 2013 at 7:04 PM, John Dickinson 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 responsible for ensuring t
On Dec 5, 2013, at 6:43 AM, Carl Baldwin 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 there for the mer
On Dec 5, 2013, at 5:21 PM, Isaku Yamahata wrote:
> On Wed, Dec 04, 2013 at 12:37:19PM +0900,
> Maru Newby wrote:
>
>> In the current architecture, the Neutron service handles RPC and WSGI with a
>> single process and is prone to being overloaded such that agent heartbea
On Dec 6, 2013, at 1:09 AM, John Dickinson wrote:
>
> On Dec 5, 2013, at 1:36 AM, Maru Newby wrote:
>
>>
>> On Dec 3, 2013, at 12:18 AM, Joe Gordon wrote:
>>
>>>
>>>
>>>
>>> On Sun, Dec 1, 2013 at 7:04 PM, John Dickinson w
On Dec 7, 2013, at 6:21 PM, Robert Collins wrote:
> On 7 December 2013 21:53, Isaku Yamahata 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 lose notification, notifications will b
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 10, 2013, at 4:47 PM, Isaku Yamahata wrote:
> On Tue, Dec 10, 2013 at 07:28:10PM +1300,
> Robert Collins wrote:
>
>> On 10 December 2013 19:16, Isaku Yamahata wrote:
>>
>>> Answering myself. If connection is closed, it will reconnects automatically
>>> at rpc layer. See neutron.openst
On Dec 5, 2013, at 4:43 PM, Édouard Thuleau 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 wrote:
> On Mon, Dec 09, 2013 at 08:43:59AM +1300,
> Robert Collins wrote:
>
listening: when an agent connects after an outage, it first starts
listening, then does a poll for updates it missed.
>>>
>>> Are you suggesting that processing o
On Dec 11, 2013, at 8:39 AM, Isaku Yamahata wrote:
> On Wed, Dec 11, 2013 at 01:23:36AM +0900,
> Maru Newby wrote:
>
>>
>> On Dec 10, 2013, at 6:36 PM, Isaku Yamahata wrote:
>>
>>> On Mon, Dec 09, 2013 at 08:43:59AM +1300,
>>> Robert Collins
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:
https://review.openstack.org/#/c
On Dec 13, 2013, at 8:06 PM, Isaku Yamahata wrote:
> On Fri, Dec 06, 2013 at 04:30:17PM +0900,
> Maru Newby wrote:
>
>>
>> On Dec 5, 2013, at 5:21 PM, Isaku Yamahata wrote:
>>
>>> On Wed, Dec 04, 2013 at 12:37:19PM +0900,
>>> Maru Newby wrot
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 sense
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,
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)
htt
On Feb 12, 2014, at 12:36 PM, Sean Dague 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
>>
On Feb 12, 2014, at 1:59 PM, Sean Dague wrote:
> On 02/12/2014 04:25 PM, Maru Newby wrote:
>>
>> On Feb 12, 2014, at 12:36 PM, Sean Dague wrote:
>>
>>> On 02/12/2014 01:48 PM, Maru Newby wrote:
>>>> At the last 2 summits, I've suggested that API
Booting a Nova instance when Neutron is enabled is often unreliable due to the
lack of coordination between Nova and Neutron apart from port allocation.
Aaron Rosen and I have been talking about fixing this by having Nova perform a
check for port 'liveness' after vif plug and before vm boot. T
On Dec 7, 2014, at 10:51 AM, Gary Kotton 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 out is to have
On Dec 9, 2014, at 7:04 AM, Daniel P. Berrange 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/ and nova (rfc p
On Dec 11, 2014, at 2:27 PM, Sean Dague 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 wrote:
On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
>
> On Dec 11, 2014, at 8:00 AM, Henry
On Dec 12, 2014, at 1:40 PM, Sean Dague wrote:
> On 12/12/2014 01:05 PM, Maru Newby wrote:
>>
>> On Dec 11, 2014, at 2:27 PM, Sean Dague wrote:
>>
>>> On 12/11/2014 04:16 PM, Jay Pipes wrote:
>>>> On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:
&g
;>
>> On 12/12/14 22:40, Sean Dague wrote:
>>> On 12/12/2014 01:05 PM, Maru Newby wrote:
>>>>
>>>> On Dec 11, 2014, at 2:27 PM, Sean Dague wrote:
>>>>
>>>>> On 12/11/2014 04:16 PM, Jay Pipes wrote:
>>>>>> On 12/
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, th
> On Jan 8, 2015, at 3:54 PM, Sean Dague 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 w
+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 th
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 that
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 t
On May 21, 2014, at 1:59 PM, Kyle Mestery 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
http://lists.openstack.org/cg
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 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.
&g
e engineering
> principles, like modularity and loose decoupling of system components.
>
> I think we didn't have enough time during the summit to iron out some
> of the concerns voiced here, and it seems like the IRC meeting for
> Group Policy would not be the right venue to tr
.
As such, and as was agreed to in the irc meeting this morning, the way forward
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 wrote:
> On May 22, 2014,
+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 wrote:
> if peoples like this why don't we have it direct
separate project repository.
>>
>> Hopefully, the tests as designed could easily take a new configuration
>> directive and a short bit of work with OS QA will get the integrated FTs
>> working as well as the isolated ones.
>>
>> --Rocky
> This issue has been mu
On Mar 26, 2014, at 12:59 PM, Joe Gordon wrote:
>
>
>
> On Tue, Mar 25, 2014 at 1:49 AM, Maru Newby wrote:
>
> On Mar 21, 2014, at 9:01 AM, David Kranz wrote:
>
> > On 03/20/2014 04:19 PM, Rochelle.RochelleGrober wrote:
> >>
> >>> -Ori
On Mar 26, 2014, at 1:52 PM, Sean Dague wrote:
> On 03/25/2014 04:49 AM, Maru Newby wrote:
>>
>> On Mar 21, 2014, at 9:01 AM, David Kranz wrote:
>>
>>> On 03/20/2014 04:19 PM, Rochelle.RochelleGrober 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 the stable maint requirement of not changing functional
behavior.
While performance of the agent was improved with caching ena
On Oct 22, 2014, at 12:53 AM, Jakub Libosvar 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 sat
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 wrote:
> Hi,
>
> There is an action for creating a Gerrit dashboard to sh
On Oct 29, 2014, at 8:12 AM, Yangxurong 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 communicate
> among distr
On Oct 29, 2014, at 12:25 PM, Steve Gordon wrote:
> - Original Message -
>> From: "Maru Newby"
>> To: "OpenStack Development Mailing List (not for usage questions)"
>>
>>
>> Am I the only one wondering whether introducing arb
On Oct 29, 2014, at 1:36 PM, Hly wrote:
>
>
> Sent from my iPad
>
> On 2014-10-29, at 下午6:33, Maru Newby wrote:
>
>>
>> On Oct 29, 2014, at 8:12 AM, Yangxurong wrote:
>>
>>> Hi,
>>>
>>> I’m not sure whether following iss
On Jul 17, 2014, at 8:12 AM, Kyle Mestery wrote:
> On Thu, Jul 17, 2014 at 6:42 AM, Thierry Carrez 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 effort. I'd
>>> like to start t
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 p
I'd like to reminder all Neutron contributors that if you are not the assignee
for a bug, you should be consulting the assignee before you consider
reassigning the bug to yourself or others. Failing to do so is not only
disrespectful, but may also result in unnecessary work. It could be that t
Hi Nachi,
The current neutron gate failure is due to the following nat rule being cleared
from the router namespace when the l3 agent syncs the router:
-A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80
-j REDIRECT --to-ports 9697
The only place the metadata nat rule
On Aug 15, 2013, at 12:50 PM, Joe Gordon wrote:
> •
> On Thu, Aug 15, 2013 at 12:22 PM, Sam Harwell
> 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 decisions I made, I go
> and make an issue
On Aug 16, 2013, at 2:12 AM, Robert Collins wrote:
> On 16 August 2013 20:15, Maru Newby wrote:
>
>>> This pattern has one slight issue, which is:
>>>
>>> • Do not assume the reviewer has access to external web services/site.
>>> In 6 months t
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 w
On Aug 16, 2013, at 11:44 AM, Monty Taylor wrote:
>
>
> On 08/16/2013 02:25 PM, Maru Newby wrote:
>> 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 develope
On Aug 16, 2013, at 11:44 AM, Clint Byrum wrote:
> Excerpts from Maru Newby's message of 2013-08-16 11:25:07 -0700:
>> 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 worki
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
http://lists.openstack.org/cgi-b
ute/admin/content/existing-ha-networking-options.html
> I could be totally wrong and crazy, so please provide some feedback.
>
> Thanks,
>
> Edgar
>
>
> From: Yongsheng Gong
> Date: Monday, August 26, 2013 2:58 PM
> To: "Kyle Mestery (kmestery)" , Aaro
multi-host
globally will be harder on admins than the change 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 New
On Aug 26, 2013, at 10:23 AM, Dean Troyer wrote:
> On Mon, Aug 26, 2013 at 10:50 AM, Maru Newby 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 deliberately avoide
On Aug 27, 2013, at 3:27 PM, Tom Fifield wrote:
> On 27/08/13 15:23, Maru Newby wrote:
>>
>> On Aug 26, 2013, at 9:39 PM, Yongsheng Gong wrote:
>>
>>> First 'be like nova-network' is a merit for some deployments.
>>
>> I'm afraid &
+1 from me, long overdue!
> On May 28, 2015, at 9:42 AM, Kyle Mestery 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 Lieutenant. His influence
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 manuall
ood call, I’ve cross-posted to the user list as you suggest.
>
> On Tue, Mar 3, 2015 at 12:50 PM, Maru Newby 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
> validat
sense to send this to the users list as well. There may 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 wrote:
> There have been a
+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 wrote:
>
> I'd like to propose that we add Ihar Hrachyshka to the Neutron core reviewer
> team. Ihar has been doing a great job reviewing in Neutron as
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 curr
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 i
> On Mar 25, 2015, at 4:22 PM, Monty Taylor 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
> On Apr 1, 2015, at 6:09 AM, Jeremy Stanley 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 in the too
> On Apr 1, 2015, at 2:52 AM, Thierry Carrez 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 project pr
> On Apr 1, 2015, at 1:47 PM, Jeremy Stanley 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
> On Apr 2, 2015, at 3:26 AM, Thierry Carrez 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 sa
1 - 100 of 105 matches
Mail list logo
