On 15 September 2015 at 16:08, Monty Taylor wrote:
> On 09/15/2015 06:30 PM, Armando M. wrote:
>
>>
>>
>> On 15 September 2015 at 08:04, Monty Taylor > <mailto:mord...@inaugust.com>> wrote:
>>
>> Hey all!
>>
>> If a
On 15 September 2015 at 16:01, Monty Taylor wrote:
> On 09/15/2015 06:16 PM, Armando M. wrote:
>
>>
>>
>> On 15 September 2015 at 08:27, Mike Spreitzer > <mailto:mspre...@us.ibm.com>> wrote:
>>
>> Monty Taylor mailto:mord...@inaug
On 15 September 2015 at 15:11, Mathieu Gagné wrote:
> On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
> > We run several clouds where there are multiple external networks. the
> "just run it in on THE public network" doesn't work. :/
> >
> > I also strongly recommend to users to put vms on a private n
On 15 September 2015 at 14:04, Mike Spreitzer wrote:
> "Armando M." wrote on 09/15/2015 03:50:24 PM:
>
> > On 15 September 2015 at 10:02, Doug Hellmann
> wrote:
> > Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> ...
> > As with
On 15 September 2015 at 10:02, Doug Hellmann wrote:
> Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> > On 15 September 2015 at 08:04, Monty Taylor
> wrote:
> >
> > > Hey all!
> > >
> > > If any of you have ever gotten drun
On 15 September 2015 at 11:28, Matt Riedemann
wrote:
>
>
> On 9/15/2015 10:27 AM, Mike Spreitzer wrote:
>
>> Monty Taylor wrote on 09/15/2015 11:04:07 AM:
>>
>> > a) an update to python-novaclient to allow a named network to be passed
>> > to satisfy the "you have more than one network" - the
On 15 September 2015 at 08:04, Monty Taylor wrote:
> Hey all!
>
> If any of you have ever gotten drunk with me, you'll know I hate floating
> IPs more than I hate being stabbed in the face with a very angry fish.
>
> However, that doesn't really matter. What should matter is "what is the
> most s
On 15 September 2015 at 08:27, Mike Spreitzer wrote:
> Monty Taylor wrote on 09/15/2015 11:04:07 AM:
>
> > a) an update to python-novaclient to allow a named network to be passed
> > to satisfy the "you have more than one network" - the nics argument is
> > still useful for more complex things
>
On 12 September 2015 at 18:38, Gary Kotton wrote:
> Thanks! You did a great job. Looking back you made some very tough and
> healthy decisions. Neutron has a new lease on life!
> It is tradition that the exiting PTL buy drinks for the community :)
>
Ok, none of these kind words make you change y
On 10 September 2015 at 11:04, James Dempsey wrote:
> Greetings Devs,
>
> I'm very excited about the new RFE process and thought I'd test it by
> requesting a feature that is very often requested by my users[1].
>
> There are some great docs out there about how to submit an RFE, but I
> don't kno
On 4 September 2015 at 15:33, Paul Carver wrote:
>
> Can someone from the Docs team take a look at why there isn't a docs URL
> for the networking-sfc repo?
>
Everything in OpenStack is code driven. And doc publishing happens through
code review as much as anything else. [1] Should provide point
be merged
during RC. Some other blueprints are best completed during feature freeze,
because of the rebase risk they cause...
Bottom line: never leave it to last minute!
> Thanks,
> Hirofumi
>
> On 2015/09/04, at 7:00, Armando M. wrote:
>
>
>
> On 2 September 2015 at 09:4
On 2 September 2015 at 09:40, Armando M. wrote:
> Hi,
>
> By now you may have seen that I have taken out your change from the gate
> and given it a -2: don't despair! I am only doing it to give priority to
> the stuff that needs to merge in order to get [1] into a much bett
Hi,
By now you may have seen that I have taken out your change from the gate
and given it a -2: don't despair! I am only doing it to give priority to
the stuff that needs to merge in order to get [1] into a much better shape.
If you have an important fix, please target it for RC1 or talk to me or
On 31 August 2015 at 11:41, Armando M. wrote:
>
> On 31 August 2015 at 10:44, Edgar Magana wrote:
>
>> Yeah!!
>>
>
> Well don't get so excited, the check queue is hovering over the 200 mark,
> so.
>
>
well, that didn't last long:
We&#
On 31 August 2015 at 10:44, Edgar Magana wrote:
> Yeah!!
>
Well don't get so excited, the check queue is hovering over the 200 mark,
so.
>
> From: "Armando M."
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> Dat
On 31 August 2015 at 06:18, Ihar Hrachyshka wrote:
> Hi all,
>
> I see neutron folks pushing more neutron patches into the gate. They are
> all doomed to fail until [1] is resolved. So please stop approving patches,
> we only make harm by resetting the gate, with no chance to pass it.
>
> PS: it
On 31 August 2015 at 09:53, Jeremy Stanley wrote:
> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote:
> > I was under the impression that we had a plan to stop allowing these
> > external updates break our gate jobs.
> [...]
>
> We do, and it succeeded in protecting master branch integrat
a breaking update like this always
> comes around the end of a cycle or a feature freeze?
>
You missed 'weekends' :)
Not that it is any consolation, at least there are always a few brave
individuals that step in to the fire!
>
> Carl
>
> On Sun, Aug 30, 2015 at 9:54 PM
Hi,
If you wonder why hell broke loose, [1] will have the answer to your
questions.
Armando
[1] https://bugs.launchpad.net/neutron/+bug/1490380
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
Is this an example of +1+1=3?
On 12 August 2015 at 07:51, Doug Wiegley
wrote:
> A big +1 to both!!
>
> Doug
>
>
>
> On Aug 12, 2015, at 6:45 AM, Kyle Mestery wrote:
>
> It gives me great pleasure to propose Russell Bryant and Brandon Logan as
> core reviewers in the API/DB/RPC area of Neutron.
On 31 July 2015 at 20:33, Paul Carver wrote:
> On 7/31/2015 9:47 AM, Kyle Mestery wrote:
>
> However, it's reasonable to assume the later you propose your RFE bug, the
>> less of a chance it has of making it. We do enforce the Feature Freeze
>> [2],
>> which is the week of August 31 [3]. Thus, ef
On 29 July 2015 at 22:42, Anita Kuno wrote:
> On 07/29/2015 02:37 PM, Armando M. wrote:
> > Hi,
> >
> > Since I was quoted, I would like to take the blame on behalf on the
> Neutron
> > core reviewer/drivers team for not providing the right guidance to
> resolve
Hi,
Since I was quoted, I would like to take the blame on behalf on the Neutron
core reviewer/drivers team for not providing the right guidance to resolve
the apparent conflict between the two proposals.
As some reviewers mentioned, we should really strive to catch two birds
with one stone, and e
On 23 July 2015 at 05:25, Ihar Hrachyshka wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi all,
>
> I've stumbled on this one. It turns out we gate neutron against
> openstack installation that runs vpn-agent instead of l3-agent [1]. Is
> it really what we want to do? I would exp
On 7 July 2015 at 11:56, Doug Hellmann wrote:
> Excerpts from Ben Nemec's message of 2015-07-07 11:41:35 -0500:
> > On 07/04/2015 12:12 AM, Akihiro Motoki wrote:
> > > Hi Oslo and Neutron folks,
> > >
> > > Why is policy_dirs option deprecated in oslo.policy?
> > > In Neutron we have multiple rep
On 10 July 2015 at 16:01, Vadivel Poonathan
wrote:
> Hi,
>
> I have a Neutron plugin (actually a mechanism_driver under ML2) developed
> for Alcatel-Lucent Omniswitches and is currently being used. But it is not
> part of Neutron upstream, nor listed in the docs/wiki section. I tried to
> make it
alvatore
>
>
>
> On 8 July 2015 at 20:21, Armando M. wrote:
>
>> Hi,
>>
>> Another brief update on the matter:
>>
>> Failure rate trends [1] are showing that unstable (w/ multiple API
>> workers + pymysql driver) and stable configurations (w/o
triage/experiment and get to a solution. I'll
watch [1] a little longer before I think it's safe to claim that we're out
of the woods.
Cheers,
Armando
[1] http://goo.gl/YM7gUC
[2] https://review.openstack.org/#/c/199668/
[3] https://review.openstack.org/#/c/199672/
On 22 June 2015 at
Filed [1], I think this affected more than just vpn. Fix coming shortly.
Sorry, I thought I had taken the necessary measures :)
[1] https://bugs.launchpad.net/neutron/+bug/1472361
On 7 July 2015 at 09:11, Armando M. wrote:
> Hi Paul,
>
> Let me look into it.
>
> Thanks,
>
Hi Paul,
Let me look into it.
Thanks,
Armando
On 7 July 2015 at 08:51, Paul Michali wrote:
> I'm seeing that neutron-vpn repo py27 tests are now failing. Did a git
> bisect in Neutron and found that this commit is causing the failure (not
> sure what's broken).
>
> commit 18bc67d56faef30a0f734
Thanks Sean, comments inline.
On 6 July 2015 at 16:58, Sean M. Collins wrote:
> I'd also like to chime in - we've had some discussions on -infra today
> about the partial upgrade issue, and collected the following notes on an
> etherpad.
>
> https://etherpad.openstack.org/p/neutron-partial-upgra
On 6 July 2015 at 13:13, Jeremy Stanley wrote:
> On 2015-07-06 11:54:45 -0700 (-0700), Armando M. wrote:
> [...]
> > For what I can tell, Joe was kind to set the infra to start
> > gathering data on the reliability of the multi-node jobs, but they
> > are clearly flaky [
Hi,
When reading [1], it seems that Doug is implying there will be the ability
to collate multiple policy.json files together? It would be good to get
this point clarified.
Thanks,
Armando
[1] https://bugs.launchpad.net/oslo.policy/+bug/1428332
On 3 July 2015 at 22:12, Akihiro Motoki wrote:
>
Hi,
Not sure if we reached any conclusion with this thread, and I would like to
resume it so that we don't derail the initial plan set forth by Russell and
agreed during the Liberty summit, among other things.
If I look at the thread I think this can be summarized as follow. Please
correct me if
O(1)
(some of computational complexities achieved after Miguel optimizations)
On 6 July 2015 at 09:24, Carl Baldwin wrote:
> +1!
>
> On Mon, Jul 6, 2015 at 4:02 AM, Kevin Benton wrote:
> > Hello!
> >
> > As the Lieutenant of the built-in control plane[1], I am proposing to add
> > Miguel Angel
Hi,
A brief update on the issue that sparked this thread:
A little over a week ago, bug [1] was filed. The gist of that was that the
switch to pymysql unveiled a number of latent race conditions that made
Neutron unstable.
To try and nip these in the bud, the Neutron team filed a number of patch
On 18 June 2015 at 09:54, Jay Pipes wrote:
> On 06/18/2015 12:46 PM, Armando M. wrote:
>
>> On 18 June 2015 at 04:30, Jay Pipes > <mailto:jaypi...@gmail.com>> wrote:
>>
>> On 06/17/2015 02:24 PM, Cathy Zhang wrote:
>>
>> Hi Nicolas,
&
On 18 June 2015 at 04:30, Jay Pipes wrote:
> On 06/17/2015 02:24 PM, Cathy Zhang wrote:
>
>> Hi Nicolas,
>>
>> Thanks for your suggestion. Yes, we can add Application ID to the
>> parameter of the flow classifier/filter. The next updated version will
>> reflect this. Actually in its existing desi
Hi,
The infrastructure jobs are completed. The project repository [1] has been
provisioned, and it is ready to go. Spec [2] is being moved to the new
repo, with patch [3]. Any documentation/specification effort that pertains,
and/or is solely focused on SFC, should target the new repo from now on.
On 16 June 2015 at 22:36, Sam Morrison wrote:
>
> On 17 Jun 2015, at 10:56 am, Armando M. wrote:
>
>
>
> On 16 June 2015 at 17:31, Sam Morrison wrote:
>
>> We at NeCTAR are starting the transition to neutron from nova-net and
>> neutron almost does what
On 15 June 2015 at 19:34, Sam Su wrote:
> Hi stackers,
>
>
>
> I am going to implement a Neutron plugin, however when I checked the
> current Neutron code(master) structure, I found there are two way to
> organize a Neutron plugin:
>
> 1. The first one is implement all L2 and L3 functions u
On 16 June 2015 at 17:31, Sam Morrison wrote:
> We at NeCTAR are starting the transition to neutron from nova-net and
> neutron almost does what we want.
>
> We have 10 “public" networks and 10 “service" networks and depending on
> which compute node you land on you get attached to one of them.
>
+1
On 12 June 2015 at 13:49, Edgar Magana wrote:
> Excellent news! +1
>
> Cheers,
>
> Edgar
>
>
> On Jun 12, 2015, at 12:50 PM, Kevin Benton wrote:
>
> Hello!
>
> As the Lieutenant of the built-in control plane[1], I would
> like Rossella Sblendido to be a member of the control plane core
This is exactly what I did in [1].
Cheers,
Armando
[1]
https://review.openstack.org/#/q/status:open+branch:master+topic:neutron-unstable,n,z
On 12 June 2015 at 09:00, Clint Byrum wrote:
> Excerpts from Chris Dent's message of 2015-06-12 03:47:02 -0700:
> > On Fri, 12 Jun 2015, Joe Gordon wrote
+1
On 11 June 2015 at 12:42, Carl Baldwin wrote:
> +1
>
> On Thu, Jun 11, 2015 at 12:15 PM, Kevin Benton wrote:
> > Hello all!
> >
> > As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO
> > Takashi to be a member of the control plane core reviewer team.
> >
> > He has bee
+1
On 11 June 2015 at 09:27, Carl Baldwin wrote:
> +1!
>
> On Thu, Jun 11, 2015 at 8:34 AM, Henry Gessau wrote:
> > As one of the Lieutenants [1] for the API and DB areas under the PTL, I
> would
> > like to propose Ann Kamyshnikova as a member of the Neutron API and DB
> core
> > reviewer team
Interestingly, [1] was filed a few moments ago:
[1] https://bugs.launchpad.net/neutron/+bug/1463129
On 2 June 2015 at 22:48, Salvatore Orlando wrote:
> I'm not sure if you can test this behaviour on your own because it
> requires the VMware plugin and the eventlet handling of backend response.
https://review.openstack.org/#/c/177946/
>
> Thanks
> Vikram
>
>
> On Fri, Jun 5, 2015 at 6:36 AM, Armando M. wrote:
>
>>
>> On 4 June 2015 at 14:17, Cathy Zhang wrote:
>>
>>> Thanks for joining the service chaining meeting today! Sorry for
On 4 June 2015 at 14:17, Cathy Zhang wrote:
> Thanks for joining the service chaining meeting today! Sorry for the
> time confusion. We will correct the weekly meeting time to 1700UTC (10am
> pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting
> page.
>
>
>
Cathy, thanks for dr
You have better chances of getting an answer if you asked the -dev list and
add [Neutron] to the subject (done here).
That said, can you tell us a bit more about your deployment? You can also
hop on #openstack-neutron on Freenode to look for neutron developers who
can help you more interactively.
On 28 May 2015 at 03:09, Ihar Hrachyshka wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I've heard that other projects come up with actual action lists and
> work assignments. I've heard Nova, Ironic, Oslo do it, and I witnessed
> just that in those Oslo sessions I had a chance to
On 25 May 2015 at 09:46, Mike Bayer wrote:
>
>
> On 5/25/15 12:34 PM, Armando M. wrote:
>
>
>
>
>
> One thing I would like to point out is that in this cycle we'll be working
> extensively in this area to make the very task you are working on easier to
>
On 25 May 2015 at 08:23, Mike Bayer wrote:
>
>
> On 5/25/15 10:24 AM, Henry Gessau wrote:
>
>> Yes, unfortunately the autogenerate currently generates commands to drop
>> all the FWaaS, LBaaS and VPNaaS tables since their models are not in the
>> neutron tree. You can and should delete all these
On 23 May 2015 at 04:43, Assaf Muller wrote:
> There's no real reason as far as I'm aware, just an implementation
> decision.
>
This is inaccurate. There is a reason(s), and this has been asked before:
http://lists.openstack.org/pipermail/openstack/2014-March/005950.html
http://lists.openstack.
On 21 May 2015 at 09:58, Kyle Mestery wrote:
> On Thu, May 21, 2015 at 9:51 AM, Doug Wiegley <
> doug...@parksidesoftware.com> wrote:
>
>>
>> On May 21, 2015, at 9:14 AM, Armando M. wrote:
>>
>>
>>
>> On 21 May 2015 at 08:58, Salvatore Orlan
On 21 May 2015 at 08:58, Salvatore Orlando wrote:
> After putting the whole OpenStack networking contributors community
> through almost 8 cycles of pedant comments and annoying "what if"
> questions, it is probably time for me to relieve neutron contributors from
> this burden.
>
> It has been a
On 28 April 2015 at 05:52, Russell Bryant wrote:
> On 04/28/2015 06:25 AM, Rossella Sblendido wrote:
> >
> >
> > On 04/28/2015 03:24 AM, Armando M. wrote:
> >> >> UnsupportedVersion error if the version is not bumped in their
> agent too.
> >&g
On 27 April 2015 at 18:16, YAMAMOTO Takashi wrote:
> > On 27 April 2015 at 09:09, Rossella Sblendido
> wrote:
> >
> >> Hello all,
> >>
> >> I am working at the blueprint "Restructure the L2 agent" [1] .
> >> One of the work item of this blueprint is to modify the port_update
> >> message to incl
On 23 April 2015 at 09:14, Chris Dent wrote:
>
> This might be a bit presumptuous, but why not give it a try...
>
> This cycle's TC elections didn't come with a set of prepackaged
> questions and though the self-nomination messages have included some
> very interesting stuff I think it would be u
On 27 April 2015 at 09:09, Rossella Sblendido wrote:
> Hello all,
>
> I am working at the blueprint "Restructure the L2 agent" [1] .
> One of the work item of this blueprint is to modify the port_update
> message to include the attributes of the ports that were modified. This
> is implemented in
>
>
> Any project that fails to meet the criteria later can be dropped at any
> time. For example, if some repo is clearly unmaintained, it can be
> removed.
>
If we open the door to excluding projects down the road, then wouldn't we
need to take into account some form of 3rd party CI validation
>
> If we've reached the point where we're arguing about naming, dos this mean
>> we've built consensus on the "yes, it makes sense for these to live under
>> Neutron" argument?
>>
>
>
I think we are in agreement that these projects need to find a more obvious
home, they feel somewhat orphan otherw
On 24 April 2015 at 01:47, Miguel Angel Ajo Pelayo
wrote:
> Hi Armando & Salvatore,
>
> On 23/4/2015, at 9:30, Salvatore Orlando wrote:
>
>
>
> On 23 April 2015 at 01:30, Armando M. wrote:
>
>>
>> On 22 April 2015 at 06:02, Miguel Angel Ajo Pe
On 23 April 2015 at 09:58, Russell Bryant wrote:
> On 04/23/2015 12:14 PM, Armando M. wrote:
> >
> >
> > On 23 April 2015 at 07:32, Russell Bryant > <mailto:rbry...@redhat.com>> wrote:
> >
> > On 04/22/2015 10:33 PM, Armando M. wrote:
>
On 23 April 2015 at 07:32, Russell Bryant wrote:
> On 04/22/2015 10:33 PM, Armando M. wrote:
> >
> > Would it make sense to capture these projects as simply
> > 'affiliated', ie. with a loose relationship to Neutron, because
> > th
>
>
>> I agree with henry here.
> Armando, If we use your analogy with nova that doesn't build and deliver
> KVM, we can say that Neutron doesn't build or deliver OVS. It builds a
> driver and an agent which manage OVS, just like nova which provides a
> driver to manage libvirt/KVM.
> Moreover, ext
On 23 April 2015 at 01:49, Thierry Carrez wrote:
> Armando M. wrote:
> > Is it sensible to assume that Stackforge is going away entirely at some
> > point in the future, and we'll have a single namespace - OpenStack?
>
> The key difference between Stackforge and Op
>
>
> Could you please also pay some attention on Cons of this ultimate
> splitting Kyle? I'm afraid it would hurt the user experiences.
>
> On the position of Dev, A naked Neutron without "official" built-in
> reference implementation probably has a more clear architecture. On
> the other side, us
>
>
>> Would it make sense to capture these projects as simply 'affiliated', ie.
>> with a loose relationship to Neutron, because they use/integrate with
>> Neutron in some form or another (e.g. having 3rd-party, extending-api,
>> integrating-via-plugin-model, etc)? Then we could simply consider ex
On 22 April 2015 at 11:19, Russell Bryant wrote:
> Hello!
>
> A couple of things I've been working on lately are project governance
> issues as a TC member and also implementation of a new virtual
> networking alternative with a Neutron driver. So, naturally I started
> thinking about how the Ne
On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo
wrote:
>
> Hi everybody,
>
>In the latest QoS meeting, one of the topics was a discussion about how
> to implement
> QoS [1] either as in core, or as a service plugin, in, or out-tree.
>
My apologies if I was unable to join, the meeting clas
I would like to announce my candidacy for the OpenStack Technical Committee.
I will try to be brief and to the point: I have been involved in OpenStack
since the early days of the Austin release; I have worked on (perhaps) the
two most prolific projects in OpenStack (Nova, and Neutron) and a few
o
On 6 April 2015 at 08:56, Miguel Ángel Ajo wrote:
> I’d like to co-organized a QoS weekly meeting with Sean M. Collins,
>
> In the last few years, the interest for QoS support has increased,
> Sean has been leading
> this effort [1] and we believe we should get into a consensus about how to
>From spec [1], I read:
- Of the core drivers, the VLAN and OVS drivers will be marked as not
supporting VLAN transparent networks and the LB, VXLAN and GRE drivers will
be marked as supporting VLAN transparent networks. Other drivers will have
legacy behaviour.
I can't seem to find
e two bugs.
Thanks,
Armando
On 20 March 2015 at 09:51, Armando M. wrote:
>
>
> On 19 March 2015 at 23:59, Akihiro Motoki wrote:
>
>> Forwarding my reply to the other thread too...
>>
>> Multiple threads on the same topic is confusing.
>> Can we use this thread if we
des are required,
> and we decided to change the subnet "core" resource. It is the exception.
>
> Thanks,
> Akihiro
>
> 2015-03-20 8:23 GMT+09:00 Armando M. :
> > Forwarding my reply to the other thread here:
> >
> >
> >
> > If my m
Forwarding my reply to the other thread here:
If my memory does not fail me, changes to the API (new resources, new
resource attributes or new operations allowed to resources) have always
been done according to these criteria:
- an opt-in approach: this means we know the expected behavio
If my memory does not fail me, changes to the API (new resources, new
resource attributes or new operations allowed to resources) have always
been done according to these criteria:
- an opt-in approach: this means we know the expected behavior of the
plugin as someone has coded the plugin in
+1!
On 4 March 2015 at 22:29, Kevin Benton wrote:
> +1
> On Mar 4, 2015 12:25 PM, "Maru Newby" wrote:
>
>> +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 propos
On 17 February 2015 at 22:00, YAMAMOTO Takashi
wrote:
> hi,
>
> i want to add an extra requirement specific to OVS-agent.
> (namely, I want to add ryu for ovs-ofctl-to-python blueprint. [1]
> but the question is not specific to the blueprint.)
> to avoid messing deployments without OVS-agent, suc
Hi folks,
I was wondering if we should have a special neutron-drivers meeting on
Wednesday Feb 18th (9:30AM CST / 7:30AM PST) to discuss recent patches
where a few cores have not reached consensus on, namely:
- https://review.openstack.org/#/c/155373/
- https://review.openstack.org/#/c/148318/
T
I also failed to understand the issue, and I commented on the bug report,
where it's probably best to continue this conversation.
Thanks,
Armando
On 16 February 2015 at 07:54, Ihar Hrachyshka wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/16/2015 04:13 PM, James Page wrote:
L2pop is a requirement.
With the existing agent-based architecture, L2pop is used to update the FDB
tables on the compute hosts to make east/west traffic possible whenever a
new port is created or existing one is updated.
Cheers,
Armando
On 10 February 2015 at 23:07, Itzik Brown wrote:
> Hi,
>
Is there any chance that this release might have caused bug [1]? I am still
root-causing what's going on...any input highly appreciated.
Thanks,
Armando
[1] https://bugs.launchpad.net/grenade/+bug/1415284
On 27 January 2015 at 14:23, Doug Hellmann wrote:
> There were some issues with the build
+1
On 15 January 2015 at 14:46, Edgar Magana wrote:
> +1 For adding Doug as Core in Neutron!
>
> I have seen his work on the services part and he is a great member of
> the OpenStack community!
>
> Edgar
>
> From: Kyle Mestery
> Reply-To: "OpenStack Development Mailing List (not for usage
>
> If we were standing at a place with a detailed manual upgrade document
> that explained how to do minimal VM downtime, that a few ops had gone
> through and proved out, that would be one thing. And we could figure out
> which parts made sense to put tooling around to make this easier for
> ever
>
>
>
> Good questions. I'm also looking for the linux bridge MD, SRIOV MD...
> Who will be responsible for these drivers?
>
> Excellent question. In my opinion, 'technology' specific but not vendor
> specific MD (like SRIOV) should not be maintained by specific vendor. It
> should be accessible fo
On 15 December 2014 at 09:53, Neil Jerram
wrote:
>
> Hi all,
>
> Following the approval for Neutron vendor code decomposition
> (https://review.openstack.org/#/c/134680/), I just wanted to comment
> that it appears to work fine to have an ML2 mechanism driver _entirely_
> out of tree, so long as t
This was more of a brute force fix!
I didn't have time to go with finesse, and instead I went in with the
hammer :)
That said, we want to make sure that the upgrade path to Kilo is as
painless as possible, so we'll need to review the Release Notes [1] to
reflect the fact that we'll be providing a
is, ask oslo people,
>> >they did it plenty of times when graduating libraries from
>> oslo-incubator.
>> >/Ihar
>> >
>> >On 10/12/14 19:18, Cedric OLLIVIER wrote:
>> >> <https://review.openstack.org/#/c/140191/>
>> >>
>> >
On 12 December 2014 at 22:18, Ryu Ishimoto wrote:
>
>
> Hi All,
>
> It's great to see the vendor plugin decomposition spec[1] finally getting
> merged! Now that the spec is completed, I have a question on how this may
> impact neutronclient, and in particular, its handling of vendor extensions.
>
iver/blob/icehouse/apic_ml2/neutron/db/migration/alembic_migrations/env.py
> [4]
> https://github.com/noironetworks/apic-ml2-driver/blob/icehouse/setup.cfg
> [5] https://github.com/openstack-dev/cookiecutter
> [6] https://github.com/stackforge/group-based-policy
>
> On Tue, Dec 9,
e text you quoted in the review makes that clear. We will look at
>> further decomposing ML2 post Kilo, but we have to be realistic with what we
>> can accomplish during Kilo.
>> >
>> > Find me on IRC Monday morning and we can discuss further if you still
>
For anyone who had an interest in following this thread, they might want to
have a look at [1], and [2] (which is the tl;dr version [1]).
HTH
Armando
[1] https://review.openstack.org/#/c/134680
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-December/052346.html
__
Hi folks,
For a few weeks now the Neutron team has worked tirelessly on [1].
This initiative stems from the fact that as the project matures, evolution
of processes and contribution guidelines need to evolve with it. This is to
ensure that the project can keep on thriving in order to meet the nee
Congrats to Henry and Kevin, +1!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi Don,
You should look at this one:
https://wiki.openstack.org/wiki/NeutronSubteamCharters
Also, it would be good to start feeding the content of that gdoc into a
neutron-specs blueprint, using template [1] and process [2], bearing in
mind these dates [3]
1.
http://git.openstack.org/cgit/opens
Hi Henry,
Thanks for your input.
> No attention to argue on agent vs. agentless, built-in reference vs.
> external controller, Openstack is an open community. But, I just want
> to say that modularized agent re-factoring does make a lot of sense,
> while forcing customer to piggyback an extra SD
e for being outside of neutron's main repo (which, if you're
> following the discussions does not mean "outside of neutron"). The
> arguments I've seen so far do not yet convince me this thing has to be
> tightly integrated into the core neutron.
>
My work
501 - 600 of 673 matches
Mail list logo
