On 8 August 2014 10:56, 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 plugin
Adding the GBP extension to Neutron does not change the nature of the
software architecture of Neutron making it more or less monolithic.
I agree with this statement...partially: the way GBP was developed is in
accordance to the same principles and architectural choices made for the
service
optimal one?
On Fri, Aug 8, 2014 at 1:45 PM, Armando M. arma...@gmail.com wrote:
On 8 August 2014 10:56, 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
One advantage of the service plugin is that one can leverage the neutron
common framework such as Keystone authentication where common scoping is
done. It would be important in the policy type of framework to have such
scoping
The framework you're referring to is common and already
On Fri, Aug 8, 2014 at 5:38 PM, Armando M. arma...@gmail.com wrote:
One advantage of the service plugin is that one can leverage the
neutron common framework such as Keystone authentication where common
scoping is done. It would be important in the policy type of framework to
have
On 9 August 2014 10:16, Jay Pipes jaypi...@gmail.com wrote:
Paul, does this friend of a friend have a reproduceable test script for
this?
Thanks!
-jay
We would also need to know the OpenStack release where this issue manifest
itself. A number of bugs have been raised in the past around
I am gonna add more color to this story by posting my replies on review [1]:
Hi Angus,
You touched on a number of points. Let me try to give you an answer to all
of them.
(I'll create a bug report too. I still haven't worked out which class of
changes need an accompanying bug report and which
At the moment pylint on neutron is *very* noisy, and I've been looking
through
the reported issues by hand to get a feel for what's involved. Enabling
pylint is a separate discussion that I'd like to have - in some other
thread.
I think enabling pylint check was discussed at the
Hi folks,
According to [1], we have ways to introduce external references to commit
messages.
These are useful to mark certain patches and their relevance in the context
of documentation, upgrades, etc.
I was wondering if it would be useful considering the addition of another
tag:
A concern with this approach is it's pretty arbitrary, and not always
clear which bugs are being addressed and how severe they are.
Well, establishing whether LP reports are actual bugs and assigning the
severity isn't what triaging is for?
An idea that came up in the Infra/QA meetup was
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing cycle or so.
Likely, this effort is going to take more than two cycles, and would
require a very focused team of people
On 10 September 2014 22:23, Russell Bryant rbry...@redhat.com wrote:
On 09/10/2014 10:35 PM, Armando M. wrote:
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing
VLAN is on the radar, vxlan/gre was done to start with.
I believe Vivek mentioned the rationale in some other thread. The gist
of it below:
In the current architecture, we use a unique DVR MAC per compute node
to forward DVR Routed traffic directly to destination compute node.
The DVR routed
What about:
https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12
On 22 September 2014 10:23, Kevin L. Mitchell
kevin.mitch...@rackspace.com wrote:
My team just ran into an issue where neutron was not passing unit tests
when run under Python 2.6. We tracked this down to
of python 2.6, and move on, but then
I'd also like to get rid of 2.7 and move on also ;)
- Josh
On Sep 22, 2014, at 11:17 AM, Monty Taylor mord...@inaugust.com wrote:
On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote:
On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote:
What about:
https
To be fair, neutron cores turned down reviews [1][2][3] for fear that
the patch would break Hyper-V support for Neutron.
Whether it's been hinted (erroneously) that this was a packaging issue
is irrelevant for the sake of this discussion, and I suggested (when I
turned down review [3]) if we
+1
On Feb 13, 2014 5:52 PM, Nachi Ueno na...@ntti3.com wrote:
+1
2014年2月12日水曜日、Mayur Patilram.nath241...@gmail.comさんは書きました:
+1
*--*
*Cheers,*
*Mayur*
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Thomas,
I feel your frustration, however before complaining please do follow
the actual chain of events.
Patch [1]: I asked a question which I never received an answer to.
Patch [2]: I did put a -1, but I have nothing against this patch per
se. This was only been recently abandoned and my -1
On 20 February 2014 14:13, Vincent Untz vu...@suse.com wrote:
Le jeudi 20 février 2014, à 12:02 -0800, Armando M. a écrit :
Thomas,
I feel your frustration, however before complaining please do follow
the actual chain of events.
Patch [1]: I asked a question which I never received an answer
Nice one!
On 21 February 2014 11:22, Aaron Rosen aaronoro...@gmail.com wrote:
This should fix the false positive for brocade:
https://review.openstack.org/#/c/75486/
Aaron
On Fri, Feb 21, 2014 at 10:34 AM, Aaron Rosen aaronoro...@gmail.com wrote:
Hi,
Yesterday, I pushed a patch to
Hi Simon,
You are absolutely right in your train of thoughts: unless the
third-party CI monitors and vets all the potential changes it cares
about there's always a chance something might break. This is why I
think it's important that each Neutron third party CI should not only
test Neutron
I have been doing so in the number of patches I pushed to reduce error
traces due to the communication between server and dhcp agent.
I wanted to take care of the l3 agent too, but one thing I noticed is
that I couldn't find a log for it (I mean on the artifacts that are
published at job's
I believe the Brocade's mech driver might have the same problem.
That said, if the content of the rpm that installs the BigSwitch plugin is
just the sub-tree for bigswitch (plus the config files, perhaps), you might
get away with this issue by just installing the bigswitch-plugin package. I
code.
Sort of like:
common/brocade/templates
common/bigswitch/*
-Shiv
From: Armando M. arma...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
To: OpenStack Development Mailing List (not for usage questions)
openstack
I wonder what the turnaround of trivial patches actually is, I bet you it's
very very small, and as Daniel said, the human burden is rather minimal (I
would be more concerned about slowing them down in the gate, but I digress).
I think that introducing a two-tier level for patch approval can only
just a provocative thought: If we used the ovsdb connection instead, do we
really need an L2 agent :P?
On 17 June 2014 18:38, Kyle Mestery mest...@noironetworks.com wrote:
Another area of improvement for the agent would be to move away from
executing CLIs for port commands and instead use
more
intelligently/appropriately.
--
Thanks,
Vivek
*From:* Armando M. [mailto:arma...@gmail.com]
*Sent:* Tuesday, June 17, 2014 10:26 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Neutron][ML2] Modular L2 agent
architecture
Hi Gary,
Thanks for sending this out, comments inline.
On 29 June 2014 00:15, Gary Kotton gkot...@vmware.com wrote:
Hi,
At the moment there are a number of different BP’s that are proposed to
enable different VMware network management solutions. The following specs
are in review:
1.
Hi folks,
The DVR team is working really hard to complete this important task for
Juno and Neutron.
In order to help see this feature in action, a video has been made
available and link can be found in [2].
There is still some work to do, however I wanted to remind you that all of
the relevant
try again next week Monday at 14:00 UTC. The meeting will take place
on #openstack-vmware channel
Alut a continua
Gary
On 6/30/14, 6:38 PM, Kyle Mestery mest...@noironetworks.com wrote:
On Mon, Jun 30, 2014 at 10:18 AM, Armando M. arma...@gmail.com wrote:
Hi Gary
I think the specs under the umbrella one can be approved/treated
individually.
The umbrella one is an informational blueprint, there is not going to be
code associated with it, however before approving it (and the individual
ones) we'd need all the parties interested in vsphere support for
That would be my thinking as well, but if we managed to make an impressive
progress from now until the Feature Freeze proposal deadline, I'd be
willing to reevaluate the situation.
A.
On 21 July 2014 12:13, Kyle Mestery mest...@mestery.com wrote:
On Mon, Jul 21, 2014 at 2:03 PM, Armando M
It is not my intention debating, pointing fingers and finding culprits,
these issues can be addressed in some other context.
I am gonna say three things:
1) If a core-reviewer puts a -2, there must be a good reason for it. If
other reviewers blindly move on as some people seem to imply here,
Hi,
When I think about Group-Based Policy I cannot help myself but think about
the degree of variety of sentiments (for lack of better words) that this
subject has raised over the past few months on the mailing list and/or
other venues.
I speak for myself when I say that when I look at the
This thread is moving so fast I can't keep up!
The fact that troubles me is that I am unable to grasp how we move forward,
which was the point of this thread to start with. It seems we have 2
options:
- We make GBP to merge as is, in the Neutron tree, with some minor revision
(e.g. naming?);
-
On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote:
I think we should merge it and just prefix the API for now with
'/your_application_will_break_after_juno_if_you_use_this/'
And you make your call based and what pros and cons exactly, If I am ask?
Let me start:
Option 1:
- pros
This is probably not intentional from your part ,but your choice of words
make it seem that you are deriding the efforts of the team behind this
effort. While i may disagree technically here and there with their current
design, it seems to me that the effort in question is rather broad based
Hi Salvatore,
I did notice the issue and I flagged this bug report:
https://bugs.launchpad.net/nova/+bug/1352141
I'll follow up.
Cheers,
Armando
On 7 August 2014 01:34, Salvatore Orlando sorla...@nicira.com wrote:
I had to put the patch back on WIP because yesterday a bug causing a 100%
If the consensus is to unify all the config options into a single
configuration file, I'd suggest following what the Nova folks did with
[1], which I think is what Salvatore was also hinted. This will also
help mitigate needless source code conflicts that would inevitably
arise when merging
+1 from me too: Carl's contributions, code and reviews, have helped raise
the quality of this project.
Cheers,
Armando
On 21 May 2014 15:05, Maru Newby ma...@redhat.com wrote:
On May 21, 2014, at 1:59 PM, Kyle Mestery mest...@noironetworks.com wrote:
Neutron cores, please vote +1/-1 for the
I would second Maru's concerns, and I would also like to add the following:
We need to acknowledge the fact that there are certain architectural
aspects of Neutron as a project that need to be addressed; at the
summit we talked about the core refactoring, a task oriented API, etc.
To me these
AM, Armando M. arma...@gmail.com wrote:
I would second Maru's concerns, and I would also like to add the
following:
We need to acknowledge the fact that there are certain architectural
aspects of Neutron as a project that need to be addressed; at the
summit we talked about the core
On 23 May 2014 12:31, Robert Kukura kuk...@noironetworks.com wrote:
On 5/23/14, 12:46 AM, Mandeep Dhami wrote:
Hi Armando:
Those are good points. I will let Bob Kukura chime in on the specifics of
how we intend to do that integration. But if what you see in the
prototype/PoC was our final
On 24 May 2014 05:20, Robert Kukura kuk...@noironetworks.com wrote:
On 5/23/14, 10:54 PM, Armando M. wrote:
On 23 May 2014 12:31, Robert Kukura kuk...@noironetworks.com wrote:
On 5/23/14, 12:46 AM, Mandeep Dhami wrote:
Hi Armando:
Those are good points. I will let Bob Kukura chime
as
through the REST API. Is this a misunderstanding?
That was not my understanding, but I'll let Mark chime in on this.
Many thanks
Armando
Best,
Mohammad
Armando M. arma...@gmail.com wrote on 05/24/2014 01:36:35 PM:
From: Armando M. arma...@gmail.com
To: OpenStack Development Mailing
/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/
- GP PoC document
[image: Inactive hide details for Armando M. ---05/26/2014 09:46:34
PM---On May 26, 2014 4:27 PM, Mohammad Banikazemi m...@us.ibm.co]Armando
M. ---05/26/2014 09:46:34 PM---On May 26, 2014 4:27 PM, Mohammad
Banikazemi m...@us.ibm.com wrote
Hi Keshava,
To the best of my knowledge Nova does not have an explicit way to determine
VM placements based on network attributes. That said, it does have a
general mechanism called host-aggregates [1] that can be leveraged to
address what you are looking for. How certain hosts are grouped
Hi Paul,
Just out of curiosity, I am assuming you are using the client that
still relies on httplib2. Patch [1] replaced httplib2 with requests,
but I believe that a new client that incorporates this change has not
yet been published. I wonder if the failures you are referring to
manifest
here as it seems like an ssl thing itself. But... who knows?? I'm not
sure how consistently we can
recreate this, but if we can, I'll try using that patch to use requests and
see if that helps.
Armando M. arma...@gmail.com wrote on 05/29/2014 11:52:34 AM:
From: Armando M. arma
I have all of these bugs on my radar, and I want to fast track them
for merging in the next few days.
Please tag the bug reports with 'juno-rc-potential'.
For each of them we can discuss the loss of functionality they cause.
If no workaround can be found, we should definitely cut an RC2.
As far as I can tell when you specify:
dhcp_agents_per_network = X 1
The server binds the network to all the agents (up to X), which means that
you have multiple instances of dnsmasq serving dhcp requests at the same
time. If one agent dies, there is no fail-over needed per se, as the other
It sounds like the only reasonable option we are left with right now is to
document.
Even if we enabled/removed the backport, it would take time until users can
get their hands on a new cut of the stable branch.
We would need to be more diligent in the future and limit backports to just
bug
on.
I have the same problem wit L3 agents by the way, that's next on my list
--
Noel
On Tue, Oct 21, 2014 at 12:52 PM, Armando M. arma...@gmail.com wrote:
As far as I can tell when you specify:
dhcp_agents_per_network = X 1
The server binds the network to all the agents (up to X
Sorry for jumping into this thread late...there's lots of details to
process, and I needed time to digest!
Having said that, I'd like to recap before moving the discussion forward,
at the Summit and beyond.
As it's being pointed out, there are a few efforts targeting this area; I
think that is
I must admit I haven't digged up too much, but this might also look
suspicious:
https://review.openstack.org/#/c/96782/
Perhaps it's a combination of both? :)
On 29 October 2014 08:17, Kyle Mestery mest...@mestery.com wrote:
On Wed, Oct 29, 2014 at 7:25 AM, Hly henry4...@gmail.com wrote:
Hi Eugene thanks for bringing this up for discussion. My comments inline.
Thanks,
Armando
On 5 November 2014 12:07, Eugene Nikanorov enikano...@mirantis.com wrote:
Hi folks,
I'd like to raise a discussion kept in irc and in gerrit recently:
https://review.openstack.org/#/c/131944/
The
I would be open to making this toggle switch available, however I feel that
doing it via static configuration can introduce unnecessary burden to the
operator. Perhaps we could explore a way where the agent can figure which
state it's supposed to be in based on its reported status?
Armando
On 5
I have just realized that I should have cross-reference this mail on both
ML's. Same message for the dev mailing list.
Thanks,
Armando
On 6 November 2014 00:32, Armando M. arma...@gmail.com wrote:
Hi there,
I know this may be somewhat short notice, but a few of us have wondered if
we should
Not sure if you've seen this one too:
https://wiki.openstack.org/wiki/Neutron/DVR
Hope this helps!
Armando
On 7 November 2014 01:50, Li Tianqing jaze...@163.com wrote:
Oh, thanks, i finally find it.
it's all here.
https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
Thanks a
Hi Miguel,
Thanks for picking this up. Pull me in and I'd be happy to help!
Cheers,
Armando
On 7 November 2014 10:05, Miguel Ángel Ajo majop...@redhat.com wrote:
Hi Yorik,
I was talking with Mark Mcclain a minute ago here at the summit about
this. And he told me that now at the start
I chimed in on another thread, but I am reinstating my point just in case.
On 13 November 2014 04:38, Gary Kotton gkot...@vmware.com wrote:
Hi,
A few months back we started to work on a umbrella spec for Vmware
networking support (https://review.openstack.org/#/c/105369). There are a
number
Last Friday I recall we had two discussions around this topic. One in the
morning, which I think led to Maruti to push [1]. The way I understood [1]
was that it is an attempt at unifying [2] and [3], by choosing the API
approach of one and the architectural approach of the other.
[1]
Benjamin,
Feel free to reach out. If you are referring to my -2, that was just
provisional.
Before we can go ahead and see an improved scheduling capability for DHCP,
you guys need to resolve the conflict between the overlapping blueprints,
working together or giving up one in favor on the
Hello,
As follow-up action after the Design Summit Session on Core/Vendor split,
please find the proposal outlined here:
https://review.openstack.org/#/c/134680/
I know that Anita will tell me off since I asked for reviews on the ML, but
I felt that it was important to raise awareness, even
On 17 November 2014 01:13, Mathieu Rohon mathieu.ro...@gmail.com wrote:
Hi
On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote:
Last Friday I recall we had two discussions around this topic. One in the
morning, which I think led to Maruti to push [1]. The way I understood
Hi Carl,
Thanks for kicking this off. I am also willing to help as a core reviewer
of blueprints and code
submissions only.
As for the ML2 agent, we all know that for historic reasons Neutron has
grown to be not only a networking orchestration project but also a
reference implementation that is
Mark, Kyle,
What is the strategy for tracking the progress and all the details about
this initiative? Blueprint spec, wiki page, or something else?
One thing I personally found useful about the spec approach adopted in [1],
was that we could quickly and effectively incorporate community
November 2014 01:13, Mathieu Rohon mathieu.ro...@gmail.com wrote:
Hi
On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote:
Last Friday I recall we had two discussions around this topic. One in
the
morning, which I think led to Maruti to push [1]. The way I understood
[1
problem, free
of any potential confusion or open to subjective interpretation; a loose
API suffers from both pitfalls, hence my suggestion to go with API proposed
in [1].
Make sense?
cheers..
-Sukhdev
On Tue, Nov 18, 2014 at 6:44 PM, Armando M. arma...@gmail.com wrote:
Hi,
On 18 November
spin-off
goes ahead, so that efforts, like this one, can evolve at the pace they are
comfortable with.
Salvatore
[1] http://openvswitch.org/pipermail/dev/2013-October/032530.html
Make sense?
cheers..
-Sukhdev
On Tue, Nov 18, 2014 at 6:44 PM, Armando M. arma...@gmail.com wrote
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.
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 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
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
in tree whilst the others will be moved out of tree will be
problematic. I think that the model will be complete if the ML2 was also
out of tree. This will help crystalize the idea and make sure that the
model works correctly.
Thanks
Gary
From: Armando M. arma...@gmail.com
Reply
On 12 December 2014 at 22:18, Ryu Ishimoto r...@midokura.com 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
://review.openstack.org/#/c/140191/
2014-12-09 18:32 GMT+01:00 Armando M. arma...@gmail.com
mailto:arma...@gmail.com:
By the way, if Kyle can do it in his teeny tiny time that he has
left after his PTL duties, then anyone can do it! :)
https://review.openstack.org/#/c/140191/
This patch looses
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
On 15 December 2014 at 09:53, Neil Jerram neil.jer...@metaswitch.com
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
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 for all
+1
On 15 January 2015 at 14:46, Edgar Magana edgar.mag...@workday.com 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 mest...@mestery.com
Reply-To: OpenStack
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
On 17 February 2015 at 22:00, YAMAMOTO Takashi yamam...@valinux.co.jp
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
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/
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 ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/16/2015 04:13 PM,
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 d...@doughellmann.com wrote:
There were some
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
everyone.
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
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
.
Thanks,
Armando
On 20 March 2015 at 09:51, Armando M. arma...@gmail.com wrote:
On 19 March 2015 at 23:59, Akihiro Motoki amot...@gmail.com wrote:
Forwarding my reply to the other thread too...
Multiple threads on the same topic is confusing.
Can we use this thread if we continue the discussion
+09:00 Armando M. arma...@gmail.com:
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
+1!
On 4 March 2015 at 22:29, Kevin Benton blak...@gmail.com wrote:
+1
On Mar 4, 2015 12:25 PM, Maru Newby ma...@redhat.com 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
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
On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com 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
they use/integrate with Neutron
On 23 April 2015 at 01:49, Thierry Carrez thie...@openstack.org 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 OpenStack
On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com wrote:
On 04/23/2015 12:14 PM, Armando M. wrote:
On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
On 04/22/2015 10:33 PM, Armando M. wrote:
Would
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, external
On 24 April 2015 at 01:47, Miguel Angel Ajo Pelayo mangel...@redhat.com
wrote:
Hi Armando Salvatore,
On 23/4/2015, at 9:30, Salvatore Orlando sorla...@nicira.com wrote:
On 23 April 2015 at 01:30, Armando M. arma...@gmail.com wrote:
On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo
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 otherwise. Most
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 extending
1 - 100 of 657 matches
Mail list logo
