than happy to slap your
hands too.
Thanks,
Kevin
--
*From:* Salvatore Orlando [sorla...@nicira.com]
*Sent:* Tuesday, May 05, 2015 3:13 PM
*To:* OpenStack Development Mailing List
*Subject:* [openstack-dev] [neutron][api] Extensions out, Micro-versions
I think Paul is correctly scoping this discussion in terms of APIs and
management layer.
For instance, it is true that dynamic routing support, and BGP support
might be a prerequisite for BGP VPNs, but it should be possible to have at
least an idea of how user and admin APIs for this VPN use case
Silvia,
Unfortunately this log snippet just tells us that Neutron failed at startup.
There might be more information in the Neutron log. As the service failed
to start you should see a traceback in q-svc.log (or whatever name you have
for neutron's screen log).
Regards,
Salvatore
On 6 May 2015
Thanks Bob.
Two answers/comments below.
On 6 May 2015 at 14:59, Bob Melander (bmelande) bmela...@cisco.com wrote:
Hi Salvatore,
Two questions/remarks below.
From: Salvatore Orlando sorla...@nicira.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack
Patch #153236 is introducing pluggable IPAM in the db base plugin class,
and default to it at the same time, I believe.
If the consensus is to default to IPAM driver then in order to satisfy
grenade requirements those migrations scripts should be run. There should
actually be a single script to
There have now been a few iterations on the specification for Neutron
micro-versioning [1].
It seems that no-one in the community opposes introducing versioning. In
particular API micro-versioning as implemented by Nova and Ironic seems a
decent way to evolve the API incrementally.
What the
Among the OpenStack project of which I have some knowledge, none of them
uses any DDT library.
If you think there might be a library from which lbaas, neutron, or any
other openstack project might take advantage, we should consider it.
Salvatore
On 14 April 2015 at 20:33, Madhusudhan Kandadai
I think the first workaround is the solution we're looking for as it better
reflects the fact that opencontrail is a db-less plugin.
I hope it will be the easier too, but you can never be too sure with
neutron unit tests.
Salvatore
On 4 May 2015 at 12:56, Pavel Bondar pbon...@infoblox.com wrote:
At a first glance it seems run_ssh is disabled in gate tests [1]. I could
not find any nova job where it is enabled.
These tests are therefore skipped. For what is worth they might be broken
now. Sharing a traceback or filing a bug might help.
Salvatore
[1]
I believe German is referring to the case where a user performs an
operation on behalf of some other project to whom it bears no relationship.
In this case the user performing the operation authenticates with keystone
with a project_id which is not the one for which the operation is being
On 24 April 2015 at 14:11, Russell Bryant rbry...@redhat.com wrote:
On 04/24/2015 07:21 AM, Amrith Kumar wrote:
We had a hypothesis about why +0 was rarely used (never conclusively
proved). Our hypothesis was that since Stackalytics didn't count +0's
it led to an increased propensity to -1
On 24 April 2015 at 15:13, Kyle Mestery mest...@mestery.com wrote:
On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe loywo...@gmail.com wrote:
It's already away from the original thread, so I start this new one,
also with some extra tag because I think it touch some corss-project
area.
Original
On 24 April 2015 at 16:50, Chris Friesen chris.frie...@windriver.com
wrote:
On 04/24/2015 07:26 AM, Salvatore Orlando wrote:
If you think it might be beneficial to adjust tooling to that these
contributions get counted this is fine by me. I just wanted to point
out that
I do not consider
Doug, HMS Octavia was a British mine sweeper that served during WW2
figthing German warships and u-boats somewhere in the sea.
I therefore believe if you have anything against this name you are secretly
a nazi.
Does that work for the Godwin's law call?
Salvatore
On 23 April 2015 at 22:09, Doug
On 23 April 2015 at 01:30, Armando M. arma...@gmail.com wrote:
On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo mangel...@redhat.com
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
At first glance it seems like you're trying to run these tests with a
neutron repo which is not up to date.
Recently Neutron unit tests were reorganized [1]. Have you tried pulling
again from git the neutron repo?
Salvatore
[1] https://review.openstack.org/#/c/158811/
On 22 April 2015 at 19:38,
On 22 April 2015 at 14:49, Doug Hellmann d...@doughellmann.com wrote:
Excerpts from Ihar Hrachyshka's message of 2015-04-22 12:33:52 +0200:
On 04/22/2015 05:01 AM, Doug Hellmann wrote:
Excerpts from Ihar Hrachyshka's message of 2015-04-17 14:45:58
+0200:
Hi,
tl;dr neutron has
On 21 April 2015 at 14:25, Guo, Ruijing ruijing@intel.com wrote:
Somebody can help me to understand why neutron DB is needed upgrade even
in refresh installation unlike other components.
From my understanding, DB upgrade is risky and needed when upgrade.
Alembic is a fairly reliable
On 19 April 2015 at 02:23, Jay Pipes jaypi...@gmail.com wrote:
On 04/13/2015 12:39 PM, Carl Baldwin wrote:
On Mon, Apr 13, 2015 at 8:44 AM, Pavel Bondar pbon...@infoblox.com
wrote:
Hi,
I made some investigation on the topic[1] and see several issues on this
way.
1. Plugin's
On 20 April 2015 at 10:03, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/17/2015 07:49 PM, Salvatore Orlando wrote:
== 2. filling in admin context with admin roles ==
Admin context object is filled with .roles attribute that is a list
DVR probably still does satisfy the same requirements as nova multi-host,
because of the lack of SNAT masquerade distribution.
Neutron DVR distributes the floating IP and east-west traffic, but the
default gateway for each VM is still centralised, thus making the network
node a SPOF.
Then from a
Thanks for this analysis Ihar.
Some comments inline.
On 17 April 2015 at 14:45, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
tl;dr neutron has special semantics for policy targets that relies on
private symbols from oslo.policy, and it's
And since we've circled back I might add that perhaps we want nova-network
to deliver that.
Simple, reliable networking leveraging well-established off-the-shelf
technologies that satisfies the use cases Jeremy is referring to.
If regardless of changes in governance pertaining openstack project
On 17 April 2015 at 21:35, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-04-17 11:49:23 -0700 (-0700), Kevin Benton wrote:
I definitely understand that. But what is the major complaint from
operators? I understood that quote to imply it was around
Neutron's model of self-service
I think this work falls into the service VM category.
openwrt unlike other service VMs used for networking services (like
cloudstack's router vm) is very lightweight, and it's fairly easy to
provision such VMs on the fly. It should be easy also to integrate with a
ML2 control plane or even with
On 9 April 2015 at 17:04, Kyle Mestery mest...@mestery.com wrote:
On Thu, Apr 9, 2015 at 9:52 AM, Assaf Muller amul...@redhat.com wrote:
The Neutron specs process was introduced during the Juno timecycle. At
the time it
was mostly a bureaucratic bottleneck (The ability to say no) to ease the
Neutron PUT operations currently fulfil PATCH semantics in most cases.
If you omit an attribute in a PUT request its value will stay unchanged.
This behaviour, even if not strictly correct, will not change until a
strategy for evolving the API is implemented.
Salvatore
On 7 April 2015 at 02:06,
On 7 April 2015 at 00:33, Armando M. arma...@gmail.com wrote:
On 6 April 2015 at 08:56, Miguel Ángel Ajo majop...@redhat.com 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
On 31 March 2015 at 17:22, Mike Bayer mba...@redhat.com wrote:
Eugene Nikanorov enikano...@mirantis.com wrote:
Hi Matthew,
I'll add just 2c:
We've tried to move from repeatable-read to read committed in Neutron
project.
This change actually has caused multiple deadlocks during
Akihiro,
thanks for sharing this on the mailing list.
I have some answers inline, but from a community process perspective I have
a feeling that a majority of contributors feel like well established
guidelines have been violated. This has been exacerbated by the fact that
these changes are
Thanks for starting this Russell.
Some answers inline.
Salvatore
On 27 March 2015 at 00:54, Russell Bryant rbry...@redhat.com wrote:
Gary and Kyle, I saw in my IRC backlog that you guys were briefly
talking about testing the Neutron ovn ml2 driver. I suppose it's time
to add some more code
On 25 March 2015 at 14:21, Sean Dague s...@dague.net wrote:
On 03/25/2015 09:03 AM, Gary Kotton wrote:
From: Jordan Pittier jordan.pitt...@scality.com
mailto:jordan.pitt...@scality.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
On 25 March 2015 at 17:36, Neil Jerram neil.jer...@metaswitch.com wrote:
Kevin Benton blak...@gmail.com writes:
This is a nice option for smaller deployments that didn't need the
complexity of NAT. From a custom L3 plugin perspective, it also
eliminated any single points of failure pretty
On 23 March 2015 at 14:49, Mathieu Rohon mathieu.ro...@gmail.com wrote:
Hi romil,
I think the main purpose of this DB field is to maintain the compatibility
in dataplane between OVS and LinuxBridge which, by default, don't use the
same UDP port for VXLAN.
It might be useful for a cloud
Comments inline.
Salvatore
On 23 March 2015 at 15:41, John Belamaric jbelama...@infoblox.com wrote:
On 3/20/15, 8:31 PM, Salvatore Orlando sorla...@nicira.com wrote:
As the IPAM driver is called in NeutronDbPluginV2, this call happens
while another transaction is typically in progress
I think that moving the discussion in whether a pool represents a tenant's
routable address space, or whether we need a new (another?!) API entity do
deal with it probably does not really fall within the scope of this thread.
I am pretty sure Carl will soon push a specification for address scope
I just think that we might bury this discussion considering what Carl said,
and that I agree with.
So far we don't even know if we'll ever need this feature. When a concrete
use case will come for asking things like: gimme a /22 Ipv4 network and
make sure I have a pool spanning from the 1st to the
subnet pools, so it
won't be a total failure!
Salvatore
[1] https://review.openstack.org/#/c/153236/
On 17 March 2015 at 15:32, Salvatore Orlando sorla...@nicira.com wrote:
On 17 March 2015 at 14:44, Carl Baldwin c...@ecbaldwin.net wrote:
On Mar 15, 2015 6:42 PM, Salvatore Orlando
If we feel a need for specifying the relative position of gateway address
and allocation pools when creating a subnet from a pool which will pick a
CIDR from its prefixes, then the integer value solution is probably
marginally better than the fake IP one (eg.: 0.0.0.1 to say the gateway
is the
It's good to have trackers for cleaning up the implementation of these
features. I hope we might be able soon to provide more details concerning
what cleaning up activities should happen here.
Core vs extension is often incorrectly misunderstood for essential vs
optional. I believe this
On 17 March 2015 at 14:44, Carl Baldwin c...@ecbaldwin.net wrote:
On Mar 15, 2015 6:42 PM, Salvatore Orlando
* the ML2 plugin overrides several methods from the base db class.
From what I gather from unit tests results, we have not yet refactored it.
I think to provide users something
With the API tests being now available in the neutron repository - and
being actively developed, I would also mandate in reviews that API tests
are provided in lieu of the usual unit tests which at the end of the day do
what the API tests are supposed to do.
This will provide better validation,
On 14 March 2015 at 11:19, Sławek Kapłoński sla...@kaplonski.pl wrote:
Hello,
I'm using ovs agents with L2 population mechanism in ML2 plugin. I noticed
that sometimes agents don't receive proper RPC to add new vxlan tunnel
openflow rules and then vxlan network between some compute nodes not
The L2 agent, for instance, has a logic to perform full synchronisations
with the server.
These happens in two cases:
1) upon agent restart, as some messages from the server side might have
gone lost
2) whenever a failure is detected on the agent side (this is probably a bit
too conservative).
-13T15:08:15
[2] https://review.openstack.org/#/c/150485/
[3] https://review.openstack.org/#/c/147479/
[4] https://review.openstack.org/#/c/153236/
On Mon, Mar 9, 2015 at 4:44 AM, Salvatore Orlando sorla...@nicira.com
wrote:
Aloha everybody!
This is another long email, so here's
I completely agree with you - Sean and Joe.
Since the argument was brought up I just wanted to point out that this
quota service thing is a bit of a unicorn at the moment, and it should
not distract from fixing and improving quota maangement enforcement logic
in the various openstack projects.
It sounds like we're diverging a bit from the original topic, but...
whatever.
Yeah! We should totally work towards a quota service - that's what we said
back in 2011
This is a topic that comes back regularly like the Halley's comet. With the
only difference that it happens every 6 months, not 75
:* Salvatore Orlando [mailto:sorla...@nicira.com
sorla...@nicira.com]
*Sent:* Monday, March 09, 2015 6:06 AM
*To:* OpenStack Development Mailing List
*Subject:* [openstack-dev] [api][neutron] Best API for generating subnets
from pool
Greetings!
Neutron is adding a new concept of subnet pool
larger feedback, especially
since that patch should always have had the ApiImpact flag.
Needless to say, I'm happy to proceed with things as they've been agreed.
On Mon, Mar 9, 2015 at 7:05 AM, Salvatore Orlando sorla...@nicira.com
wrote:
The problem with this approach is, in my opinion
Greetings!
Neutron is adding a new concept of subnet pool. To put it simply, it is a
collection of IP prefixes from which subnets can be allocated. In this way
a user does not have to specify a full CIDR, but simply a desired prefix
length, and then let the pool generate a CIDR from its prefixes.
Aloha everybody!
This is another long email, so here's the summary for people with 5-minute
or less attention span:
The IPAM reference driver is almost ready [1]. Unfortunately letting the
driver doing allocation pools required a few major changes, so the latest
patchset is rather big. I would
Hi Leo,
Every agent keeps anyway an in-memory state throughout its execution.
The agents indeed have no persistent storage - at least not in the usual
form of a database. They however rely on data other than the neutron
database.
For instance for the l2 agent, ovsdb itself is a source of
Considering my current load I expect code to be ready by wednesday March
11th.
Maybe we can say that we can grant a FFE as long as the code makes it - in
full - by that date?
Salvatore
On 5 March 2015 at 16:03, Kyle Mestery mest...@mestery.com wrote:
On Thu, Mar 5, 2015 at 3:29 AM, Salvatore
I was hoping to push code today for [1], but unfortunately I got caught by
something else during this week and I'll miss the code proposal deadline.
I would like to apply for a FFE; however, since I've experienced FFEs in
previous release cycles, please treat this request as best-effort if there
To put in another way I think we might say that change 154670 broke
backward compatibility on the RPC interface.
To be fair this probably happened because RPC interfaces were organised in
a way such that this kind of breakage was unavoidable.
I think the strategy proposed by Assaf is a viable
Ihar has proved in several circumstances that he knows neutron source trees
way better than me, his reviews are more frequent, thorough, and useful
than those of the average core team member. Summarising, in my opinion it
is a nonsense that I am part of this team and he's not.
So I am obviously
Is common sense an option here?
More specifically I mean leveraging the common sense of both contributors
and core reviewers (or whoever is authorized to abandon patches).
The formers should abandon patches they're not working on anymore, and
expect somebody else to do that if the patches they
While it is entirely possible that the feature is broken, it seems that in
this case you're expecting the allowed_address_pairs to populate fixed_ips.
Neutron does many crazy and unreasonable things but asking you to pass an
attribute in the request to populate another attribute is not one of
Thanks Clint.
I think you are bringing an interesting and disruptive perspective into
this discussion.
Disruptive because one thing that has not been considered so far in this
thread is that perhaps we don't need at all to leverage multi-master
capabilities for write operations.
More comments
as if they were hieroglyphics.
Thanks,
Eugene.
On Wed, Feb 25, 2015 at 4:35 AM, Robert Collins robe...@robertcollins.net
wrote:
On 24 February 2015 at 01:07, Salvatore Orlando sorla...@nicira.com
wrote:
Lazy-Stacker summary:
...
In the medium term, there are a few things we might consider
On 25 February 2015 at 16:52, Carl Baldwin c...@ecbaldwin.net wrote:
jOn Mon, Feb 23, 2015 at 5:07 AM, Salvatore Orlando sorla...@nicira.com
wrote:
Lazy-Stacker summary:
I am doing some work on Neutron IPAM code for IP Allocation, and I need
to
found whether it's better to use db locking
, PAUL pc2...@att.com wrote:
Maybe I'm misreading review.o.o, but I don't see the -2. There was a -2
from Salvatore Orlando with the comment The -2 on this patch is only to
deter further comments and a link to 140292, but 140292 has a comment from
Kyle saying it's been abandoned in favor of going
As you can see, netconn-api has gone into the Openstack-attic.
A few months ago, all neutron API reference docs were moved into
neutron-specs (similar things happened to other projects).
The new home of the VPN API spec is [1]
Salvatore
[1]
..
-Bob
On 2/24/15 11:11 AM, Kyle Mestery wrote:
On Tue, Feb 24, 2015 at 3:19 AM, Salvatore Orlando sorla...@nicira.com
wrote:
On 24 February 2015 at 01:34, Kyle Mestery mest...@mestery.com wrote:
Russel and I have already merged the initial ML2 skeleton driver [1].
The thinking
Lazy-Stacker summary:
I am doing some work on Neutron IPAM code for IP Allocation, and I need to
found whether it's better to use db locking queries (SELECT ... FOR UPDATE)
or some sort of non-blocking algorithm.
Some measures suggest that for this specific problem db-level locking is
more
My opinions inline.
On 17 February 2015 at 16:04, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
response was huge so far :) so to add more traction, I have a question
for everyone. Let's assume we want to move entry points for all
services
On 13 February 2015 at 12:40, Rossella Sblendido rsblend...@suse.com
wrote:
On 02/12/2015 02:36 PM, Salvatore Orlando wrote:
- I promised a non blocking algorithm for IP allocation. The one I was
developing was based on specifying the primary key on the ip_requests
table in a way
On 12 February 2015 at 19:57, John Belamaric jbelama...@infoblox.com
wrote:
From: Salvatore Orlando sorla...@nicira.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Thursday, February 12, 2015 at 8:36 AM
To: OpenStack
Hi,
I have updated the patch; albeit not complete yet it's kind of closer to be
an allocator decent enough to replace the built-in logic.
I will be unable to attend today's L3/IPAM meeting due to a conflict, so
here are some highlights from me on which your feedback is more than
welcome:
- I
I reckon the blueprint [1] supersedes the one in the old wiki page you
found.
It lies in abandoned status as it did not make the release plan for Kilo. I
am sure the author and the other contributors working on it will resume it
for the next release.
Salvatore
[1]
, at least in Horizon dashboard
where it pops up in the main instance screen without a specific search,
can be very confusing.
On 12/16/14 12:25, Salvatore Orlando wrote:
In Neutron IP address management and distribution are separated
concepts.
IP addresses are assigned to ports even when DHCP
On 28 January 2015 at 20:19, Brian Haley brian.ha...@hp.com wrote:
Hi Kevin,
On 01/28/2015 03:50 AM, Kevin Benton wrote:
Hi,
Approximately a year and a half ago, the default DHCP lease time in
Neutron was
increased from 120 seconds to 86400 seconds.[1] This was done with the
goal of
The patch Kevin points out increased the lease to 24 hours (which I agree
is as arbitrary as 2 minutes, 8 minutes, or 1 century) because it
introduced use of DHCPRELEASE message in the agent, which is supported by
dnsmasq (to the best of my knowledge) and is functionally similar to
FORCERENEW.
Hi,
We have attempted several times to start a conversation around the
interface between nova and neutron and its problems, starting with the fact
that it's chatter than two Italians arguing about football (*).
Indeed the first attempt at fixing these problems goes back to the Fall
2012 summit
On 22 January 2015 at 17:09, Sean Dague s...@dague.net wrote:
On 01/22/2015 10:28 AM, Salvatore Orlando wrote:
Hi,
We have attempted several times to start a conversation around the
interface between nova and neutron and its problems, starting with the
fact that it's chatter than two
I agree with the proposed changes.
I would also like to take a chance to thank Sumit for the effort he has put
in this project over several years - he has been in the core team since the
project's inception and has been a witness of all its developments - both
the good and the bad ones!
You are right.
run_tests.sh simply runs unit tests which cover tempest's code itself.
In order to run the tests for the various OpenStack services, use tox.
In tox.ini there are several environments defined which run different sets
of tests.
When all you want to do is run just a specific test
/download/ds0VRvNlba/boson_arch.jpg?lgfp=3000
On 28 November 2014 at 18:20, Jay Pipes jaypi...@gmail.com wrote:
On 11/17/2014 05:49 PM, Salvatore Orlando wrote:
Hi all,
I am resuming this thread following the session we had at the summit in
Paris (etherpad here [1])
While there was some
I think Kevin is right - the actual root cause lies in plugins for which
disassociate_floating_ips returns None rather than an (empty) iterable.
A quick check revealed that at least:
neutron.plugins.embrane.base_plugin.EmbranePlugin
I think it should be possible to have a sanity check like the following:
2.63 - sorry, that's not going to work
=2.63, 2.67 - it kind of works but ipv6 is going to be messed up
2.67 - we're all right
The runtime check on the dhcp agent is a startup check. Personally I think
agents should run
Hi VMware NSX CI for Neutron was disabled but unfortunately it kept voting
on a few set of patches, always failing for a number of reasons.
It seems everything is fixed now and all the jobs have been reinstated.
Salvatore
On 25 December 2014 at 08:32, Hirofumi Ichihara
I think the point made is that the behaviour is currently inconsistent and
not user friendly.
Regardless of that, I would like to point that technically this kind of
change is backward incompatible and so it should not be simply approved by
popular acclamation.
I will seek input from the API WG
I would like to chime into this discussion wearing my plugin developer hat.
We (the VMware team) have looked very carefully at the current proposal for
splitting off drivers and plugins from the main source code tree. Therefore
the concerns you've heard from Gary are not just ramblings but are
On 9 December 2014 at 17:32, Armando M. arma...@gmail.com wrote:
On 9 December 2014 at 09:41, Salvatore Orlando sorla...@nicira.com
wrote:
I would like to chime into this discussion wearing my plugin developer
hat.
We (the VMware team) have looked very carefully at the current proposal
, Salvatore Orlando sorla...@nicira.com wrote:
Thanks Mike!
I've left some comments on the patch.
Just out of curiosity, since now alembic can autogenerate foreign keys,
are we be able to remove the logic for identifying foreign keys to
add/remove [1]?
Salvatore
[1]
http://git.openstack.org/cgit
1800UTC should generally work for Europe. The only issue is that it falls
right around dinner time.
It is however a good timing since most of the night hours fall over the
pacific ocean.
Therefore I tend to agree with Joshua's proposal since with that time range
most of the night hours would fall
I am happy with the proposed change in the core team.
Many thanks to the outgoing members and a warm welcome to hell (err core
team) to Henry and Kevin!
Salvatore
Il 02/dic/2014 17:20 Mark McClain m...@mcclain.xyz ha scritto:
On Dec 2, 2014, at 10:59 AM, Kyle Mestery mest...@mestery.com
Thanks Mike!
I've left some comments on the patch.
Just out of curiosity, since now alembic can autogenerate foreign keys, are
we be able to remove the logic for identifying foreign keys to add/remove
[1]?
Salvatore
[1]
Afaict infoblox integration cannot work with stock openstack components.
I think you'll need a service plugin and additional logic to bypass
Neutron's baked IPAM logic, and a modified DHCP agent to support relay.
The community is working on solution for integrating neutron with 3rd party
IPAM and
Hi,
As most of you surely know the proposal for micro versioning in Nova [1]
has been approved for Kilo.
I am sure you are aware that a similar proposal has bee discussed for
Neutron at the design summit.
Considering the direction taken by nova, and the fact that neutron
extensions are becoming
On 21 November 2014 10:35, Antonio Messina antonio.s.mess...@gmail.com
wrote:
Hi all,
I'm running a Juno testbed with Neutron, ml2 and ovs. We have use
cases where we would like to create a shared vlan network and directly
attach a VM on this network. This is not hard to do, and I've
On 20 November 2014 02:19, Sukhdev Kapur sukhdevka...@gmail.com wrote:
Folks,
Like Ian, I am jumping in this very late as well - as I decided to travel
Europe after the summit, just returned back and catching up :-):-)
I have noticed that this thread has gotten fairly convoluted and
Aloha guardians of the API!
I haven recently* reviewed a spec for neutron [1] proposing a distinct URI
for returning resource count on list operations.
This proposal is for selected neutron resources, but I believe the topic is
general enough to require a guideline for the API working group. Your
' depends on the outcome
of the discussion at [1]
Salvatore
[1]
https://review.openstack.org/#/c/133660/7/guidelines/representation_structure.rst
On 20 November 2014 15:24, Christopher Yeoh cbky...@gmail.com wrote:
On Thu, 20 Nov 2014 14:47:16 +0100
Salvatore Orlando sorla...@nicira.com wrote
Apparently, like everything Openstack-y we have a gathered a good crowd of
people with different opinions, more or less different, more or less strong.
My only strong opinion is that any ocean-boiling attempt should be
carefully avoided, and any proposed approach should add as little as
possible
I think we should also get rid of some nonsenses in the way events are
processed by the l2 agent. Carl did something similar for the l3 agent.
In the past release cycle I put some patches to avoid event starvation or
to prevent the same event to be processed multiple times, but I did not
address
I think you do not have a l3 plugin configured in your neutron.conf -
therefore the l3 extension is not being loaded and the router resource does
not exist.
If the l3 plugin is not there just add it to service_plugins.
If the diagnosis is correct, can you post this question to ask.openstack.org
rather start from there and iterate.
My 2c,
Armando
On 14 November 2014 08:47, Salvatore Orlando sorla...@nicira.com
wrote:
Thanks guys.
I think you've answered my initial question. Probably not in the way I
was
hoping it to be answered, but it's ok.
So now we have
Ponomaryov
vponomar...@mirantis.com wrote:
Manila project does use policy common code from incubator.
Our small wrapper for it:
https://github.com/openstack/manila/blob/8203c51081680a7a9dba30ae02d7c43d6e18a124/manila/policy.py
On Wed, Oct 15, 2014 at 2:41 AM, Salvatore Orlando sorla...@nicira.com
Thanks Maruti,
I have some comments and questions which I've posted on gerrit.
There are two things I would like to discuss on the mailing list concerning
this effort.
1) Is this spec replacing https://review.openstack.org/#/c/100278 and
https://review.openstack.org/#/c/93613 - I hope so,
101 - 200 of 459 matches
Mail list logo
