Public bug reported:
The description attribute is missed attribute in
_make_security_group_rule_dict
Create sec group rule with desc
stack@bionic-template:~/devstack$ openstack security group rule create
--description "test rule" --remote-ip 0.0.0.0/0 --ingress
ff57f76f-93a0-4bf3-b538-c88df40f
t should be:
if not fwr_db['shared']:
** Affects: neutron
Importance: Undecided
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron
I am unfortunately not very up-to-date with Mesos, but I reckon it is fair
to assume that in the current status N/S connectivity to containers should
be handled outside of mesos infrastructure, ie: OVN can define a topology
that enables external users to reach the LSPs in the LS specified in the
CN
Not that I am aware of (note: I haven't used kube-up in a while)
Are you planning to run OVS on nodes and then build the overlay on your
own, or do you have in mind to play with OVN?
In the latter case, there's an official openvswitch project for
OVN/kubernetes integration: https://github.com/open
Probably that LOG statement is a line added for debugging purposes.
There are several probable causes for a floating ip being down. If you see
any traceback in the neutron server or l3-agent that will probably
immediately reveal the root cause.
On the other hand, lack of any traceback might indica
As for the notifier proposed above it is correct that neutron needs to be
changed. This should not be a massive amount of work. Today it works with
nova only pretty much because nova it's the only compute service it
interacts with.
The question brought aboud ping vs operational status is a very go
Neutron has the ability already of sending an event as a REST call to
notify a third party that a port became active [1]
This is used by Nova to hold on booting instances until network has been
wired.
Perhaps kuryr could leverage this without having to tap into the AMQP bus,
as that would be implem
Thanks Guru!
Some comments inline.
Salvatore
On 19 May 2016 at 16:11, Guru Shetty wrote:
>
>
> On 19 May 2016 at 03:57, Salvatore Orlando wrote:
>
>> [Accidentally sent message before completing, resuming here]
>>
>> Hello,
>>
>> I have been working
om/salv-orlando/ovn-kubernetes/blob/master/ovn_k8s/conn_processor.py#L59
On 19 May 2016 at 12:38, Salvatore Orlando wrote:
> Hello,
>
> I have been working for a while on integration with kubernetes with a CNI
> plugin for OVN.
> The work in [1] is forked by Guru's repo
Hello,
I have been working for a while on integration with kubernetes with a CNI
plugin for OVN.
The work in [1] is forked by Guru's repository by the same name [2].
Most consumers of the CNI interface have an expectation that when returning
from the plugin the container interface is fully config
There is a job which has been turned on again by mistake and I'm working on
ensuring it's put to sleep again (for good this time).
If you can avoid disabling the whole account it would be great as the same
credentials are used by the still-voting nova CI.
Cheers,
Salvatore
On 3 May 2016 at 10:47
On 21 April 2016 at 16:54, Boden Russell wrote:
> On 4/20/16 3:29 PM, Doug Hellmann wrote:
> > Yes, please, let's try to make that work and contribute upstream if we
> > need minor modifications, before we create something new.
>
> We can leverage the 'retrying' module (already in global requirem
On 12 April 2016 at 15:48, Andrew Laski wrote:
>
>
> On Tue, Apr 5, 2016, at 09:57 AM, Ryan McNair wrote:
> > >It is believed that reservation help to to reserve a set of resources
> > >beforehand and hence eventually preventing any other upcoming request
> > >(serial or parallel) to exceed quota
For what is worth neutron employs "resource trackers" which conceptually do
something similar to nova quota usage statistics.
Before starting any transaction that can potentially change usage for a
given resource, the quota enforcement mechanism checks for a "dirty" marker
on the resource tracker.
y of
doing field selection they should allowed to use it.
** Affects: neutron
Importance: Medium
Assignee: Salvatore Orlando (salvatore-orlando)
Status: In Progress
** Tags: pecan
--
You received this bug notification because you are a member of Yahoo!
Engineering Team
Hey! This sounds like bike-shedding & yak-shaving... totally my thing!
It is true that the Neutron model currently kind of forces a two-level
topology, with the external network being a sort of special case.
Regardless, this does not mean you cannot assign directly public IPs to
your instances - N
As I am doing some integration between OVN and Kubernetes, there is a
similar problem there where the introduction of this concept can be very
beneficial.
To provide some context a Kubernetes network policy [1] might have several
"from" clauses which might translate into a great number of IP addre
I'm not sure if this was mentioned already throughout the thread, however
as I've been working a bit on quotas in the past I might have some
additional information:
- Looking at quotas it is worth distinguishing between management (eg::
resource limits per tenant and/or users), and enforcement (eg
Indeed the VMware plugins were not using resource tracking (they know that
my code should not be trusted!)
I think this bears however another question that we need to answer... it is
likely that some change broke quota enforcement for plugins which do not
use usage tracking.
When I developed reser
They might be not perfect but from my little experience they are able to
forward traffic and do SNAT/DNAT without too many issues.
If your deployment is failing to properly configure routing, you should be
getting errors in the l3 agent logs - sharing them might help.
Trying to ping the internal
Some thoughts inline.
Salvatore
On 11 March 2016 at 23:15, Carl Baldwin wrote:
> Hi,
>
> I have started to get into coding [1] for the Neutron routed networks
> specification [2].
>
> This spec proposes a new association between network segments and
> subnets. This affects how IPAM needs to wo
On 7 March 2016 at 10:54, Gary Kotton wrote:
> There are a number of issues here:
>
>1. The create returns additional values, for example the binding:vnic_type,
>whilst the get does not
>
> This is probably a consequence of fixing the behaviour mismatch between
create and get.
>
>1.
On 3 March 2016 at 10:38, Ihar Hrachyshka wrote:
> Kevin Benton wrote:
>
> Hi,
>>
>> I know this has come up in the past, but some folks in the infra channel
>> brought up the topic of changing the default security groups to allow all
>> traffic.
>>
>> They had a few reasons for this that I will
On 11 February 2016 at 20:17, John Belamaric
wrote:
>
> On Feb 11, 2016, at 12:04 PM, Armando M. wrote:
>
>
>
> On 11 February 2016 at 07:01, John Belamaric
> wrote:
>
>>
>>
>>
>> It is only internal implementation changes.
>>
>
> That's not entirely true, is it? There are config variables to c
The difference lies in the process in my opinion.
If the switch is added into the migration path then we will tell operators
when to switch.
I was suggesting doing it manual because we just don't know if every
operator is happy about doing the switch when upgrading to Newton, but
perhaps it is just
Orlando (salvatore-orlando)
Status: In Progress
** Tags: pecan
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1542507
Title:
Pecan: quota list does not include tenant_id
Status in
On 5 February 2016 at 17:58, Neil Jerram wrote:
> On 05/02/16 16:31, Pavel Bondar wrote:
> > On 05.02.2016 12:28, Salvatore Orlando wrote:
> >>
> >>
> >> On 5 February 2016 at 04:12, Armando M. >> <mailto:arma...@gmail.com>> wrote:
> &
get_supported_extension_aliases provided by the extension manager.
for instance the rbac extension will not work until this is fixed.
** Affects: neutron
Importance: Medium
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
** Tags: pecan
--
You received this bug
On 5 February 2016 at 04:12, Armando M. wrote:
>
>
> On 4 February 2016 at 08:22, John Belamaric
> wrote:
>
>>
>> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin wrote:
>> >
>> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar
>> wrote:
>> >> I am trying to bring more attention to [1] to make final d
Public bug reported:
clients are hardly going to work with an issue like this
** Affects: neutron
Importance: Undecided
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
** Tags: pecan
--
You received this bug notification because you are a member of Yahoo
perform this simple conversion.
The author of the code in question should consider an alternative career
path far away from programming and engineering in general.
** Affects: neutron
Importance: Undecided
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
** Tags
[2]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/api_common.py#n32
** Affects: neutron
Importance: Undecided
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
** Tags: pecan
--
You received this bug notification because you are a member of Yahoo
I agree with Armando that at the end of the day user requirements should
drive these decisions.
I think you did a good job in listing what are the pro and the cons of
choosing standalone plugin rather than a ML2 driver.
The most important point you made, in my opinion, concerns the ability of
supp
ost
> libraries just drop the payload for such cases.
>
Nevertheless, we're pretty much in control of that. We've already discussed
this, and doing so does not violate RFC7231, so it's ok from a protocol
perspective.
If needed, we can tweak the API request processing workflow for al
I tend to agree with Doug and Ryan's stance. If you need to pass 1000s of
network-id on a single request you're probably not doing things right on
the client side.
As Ryan suggested you can try and split the request in multiple requests
with acceptable URI lenght and send them in parallel; this wil
eutron
Importance: Medium
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1528510
Title:
Pecan: startup assumes contr
The point raised by Matt for Nova applies to Neutron as well.
Neutron does not have strict deadlines for blueprint approval; however even
if in theory it would still be possible to achieve this for Mitaka, it is
rather unlikely since the number of blueprints already in the pipeline is
way more than
The Neutron API dropped XML support quite some time ago.
Therefore specifying --request-format xml already produces an error.
Even if this parameter is already vestigial and should be abruptly
removed. We don't know whether anyone is using it. For instance one could
have a set of scripts that expl
I only have some historical, anecdotal, and rapidly waning memory of
previous releases.
Nevertheless my feeling is that the process has been a success so far.
In past times it would not have been a surprise if a bug fell under the
radar until that well known brownish matter hit the proverbial fan.
Hello Pedro,
Neutron has some (limited) capabilities for injecting static routes into
instances.
You can try whether the subnet's host_routes attribute [1] can satisfy your
requirement.
Routes can however be specified only in the form destination CIDR/next hop.
Note: the host_routes option leverag
Public bug reported:
Authorization checks are completely skipped on DELETE operations both in the
'before' and in the 'after' hooks.
This does not look great, and should be fixed.
** Affects: neutron
Importance: Undecided
Assignee: Salvatore Orlando (salvatore-orla
f any stakeholder.
If these information are needed for making scheduling decisions based on
network requirements, then it makes sense to expose this information also
at the API layer (I assume there also plans for making the scheduler
*seriously* network aware). However, this information
It makes sense to have a single point were response pagination is made in
API processing, rather than scattering pagination across Nova REST
controllers; unfortunately if I am not really able to comment how feasible
that would be in Nova's WSGI framework.
However, I'd just like to add that there i
Arbitrary blobs are a powerful tools to circumvent limitations of an API,
as well as other constraints which might be imposed for versioning or
portability purposes.
The parameters that should end up in such blob are typically specific for
the target IPAM driver (to an extent they might even identi
Inline,
Salvatore
On 4 November 2015 at 15:11, Cory Benfield wrote:
>
> > On 4 Nov 2015, at 13:13, Salvatore Orlando
> wrote:
> >
> > Regarding Jay's proposal, this would be tantamount to defining an API
> action for retrieving instances, something currently bei
Regarding Jay's proposal, this would be tantamount to defining an API
action for retrieving instances, something currently being discussed here
[1].
The only comment I have is that I am not entirely surely whether using the
POST verb for operations which do no alter at all the server representation
This plan makes a lot of sense to me.
With the staggering number of sub-projects in neutron it is impossible for
the stable team to cope with the load. Delegation and decentralisation is a
must and both sub-project maintainers and the stable team will benefit from
it.
Also, since patches can always
Orlando (salvatore-orlando)
Status: New
** Tags: release-subproject
** Also affects: neutron
Importance: Undecided
Status: New
** Tags added: release-subproject
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
This sounds like a pretty decent idea to me. Considering Neutron's patch
merge rate this activity should hopefully not take a consistent chunk of
your Friday.
It might also make sense to ask contributors to resume the habit of tagging
bugs with 'backport-potential' even if not in the RC period.
I
Hi Germy,
It seems that you're looking at solutions for ensuring consistency between
the "desired" configuration (Neutron), and the actual one (whatever is in
your backend) at startup.
This has been discussed several times in the past - not just for
synchronization at startup, but also for ensurin
rrent WSGI
framework
** Affects: neutron
Importance: High
Assignee: Salvatore Orlando (salvatore-orlando)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bu
a pecan bug.
The policy hook should take this into account and handle the exception.
[1]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/pecan_wsgi/hooks/policy_enforcement.py#n94
** Affects: neutron
Importance: Undecided
Assignee: Salvatore Orlando (salvatore-orlando
k.org/cgit/openstack/neutron/tree/neutron/extensions/quotasv2.py#n87
** Affects: neutron
Importance: Medium
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed
Inline,
Salvatore
On 12 October 2015 at 09:29, Germy Lure wrote:
> Hi Kevin,
>
> *Thank you for your response. Periodic data checking is a popular and
> effective method to sync info. But there is no such a feature in Neutron.
> Right? Will the community merge it soon? And can we consider it wit
Inline,
Salvatore
On 12 October 2015 at 10:23, Germy Lure wrote:
> Thank you, Kevin.
> So the community just divided the whole openstack into separate
> sub-projects(Nova,Neutron and etc.) but it's not taken into account that if
> those modules can work together with different versions. Yes?
>
hooks/quota_enforcement.py#n48
** Affects: neutron
Importance: High
Assignee: Salvatore Orlando (salvatore-orlando)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.ne
Or, since many OpenStack projects now use Pecan, we could fix this
ourselves as a thank you note to Pecan developers!
Salvatore
On 1 October 2015 at 21:08, Ryan Petrello
wrote:
> Yep, this definitely looks like a Python3-specific bug. If you'll open a
> ticket, I'll take a look as soon as I ge
Good morning Sam,
As you say, your requirement cannot be satisfied today. The option you
mention provided a nice workaround but did not fully solve your problem.
I think in order to satisfy it Neutron could either:
1) Specify this on a per-network setting in Neutron
2) Enable VIF usage tracking gr
Random comments inline.
Salvatore
On 24 September 2015 at 14:05, Russell Bryant wrote:
> On 09/24/2015 01:17 AM, Amitabha Biswas wrote:
> > Hi everyone,
> >
> > I want to open up the discussion regarding how to support OVN
> > VTEP gateway deployment and its lifecycle in Neutron.
>
> Thanks a l
: neutron
Importance: Medium
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1499358
Title:
M2: Quota usage
next get operation.
** Affects: neutron
Importance: Undecided
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs
f, or both.
Salvatore
On 22 September 2015 at 04:25, Ganesh Narayanan (ganeshna) <
ganes...@cisco.com> wrote:
> Another project for diagnosing OVS in Neutron:
>
> https://github.com/CiscoSystems/don
>
> Thanks,
> Ganesh
>
> From: Salvatore Orlando
> Reply-To: OpenStack
The comment from Kris is correct.
In the official openstack guide I believe it is stated to remove any
address from the interface attached to br-ex (sudo ip addr del dev
), not to assign it 0.0.0.0
If the guide says otherwise please open a bug against the relevant doc
project.
Salvatore
On 17
It sounds like indeed that easyOVS covers what you're aiming too.
However, from what I gather there is still plenty to do in easy OVS, so
perhaps rather than starting a new toolset from scratch you might build on
the existing one.
Personally I'd welcome its adoption into the Neutron stadium as deb
tracking for ports might be disabled.
A related question is why the logic for deleting a port resides in the
ipam module, but probably it should not be answered here.
** Affects: neutron
Importance: Medium
Assignee: Salvatore Orlando (salvatore-orlando)
Status: In Progress
currently in base.py
./neutron/newapi/hooks/ownership_validation.py:34: #
TODO(salvatore-orlando): consider whether this check can be folded
./neutron/newapi/app.py:40:#TODO(kevinbenton): error templates
./neutron/newapi/controllers/root.py:150:# TODO(kevinbenton): allow
fields a
On 28 August 2015 at 16:57, Sean Dague wrote:
> On 08/28/2015 11:20 AM, Assaf Muller wrote:
> > To recap, we had three issues impacting the gate queue:
> >
> > 1) The neutron functional job has had a high failure rate for a while
> > now. Since it's impacting the gate,
> > I've removed it from th
___
>
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy, LLC.
>
> From: Salvatore Orlando
> Date: Tuesday, August 25, 2015 at 4:33 PM
> To: Assaf Muller
> Cc: "openstack-operators@lists.openstack.org" <
> openstack-operators@lists.ope
Actually the root cause for the failure I did observe was different.
This appears to be a genuine nova error where a server is deleted by
another test while the list operation is in progress. It is also
interesting that nova fails with a 404 here - this appears to really be
a bug.
In support of m
As the specification linked by Assaf has without doubt value for operators,
I think the drivers team might consider it for inclusion in the Liberty
release.
Unfortunately the specification and the patch have not received many
reviews, but can still be sorted, especially considering that the patch's
Hi Gal,
even if I've been a lurker so far, I'm interested in attending for learning
and contributing to it with my massive bug-injecting skills!
You said "virtual sprint" and "somewhere in september" - I think
"somewhere" refers to dates?
Anyway I am pretty much open to any date from September 7t
The etherpad contains some complaints around DVR implementation that might
deserve furhter exploration.
However, as pointed out by Jay, the comments made leave very little room
for actionable items.
It would be great if the author(s) could fill in with more details.
Salvatore
On 19 August 2015 at
my 0.02€ on the matter inline.
Regards,
Salvatore
On 18 August 2015 at 23:45, Mathieu Rohon wrote:
> hi brandon,
>
> thanks for your answer.
>
> my answers inline,
>
>
>
> On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan <
> brandon.lo...@rackspace.com> wrote:
>
>> So let me make sure I understa
that code.
[1] http://logs.openstack.org/60/213360/4/check/gate-rally-dsvm-neutron-
neutron/4297681/logs/screen-q-svc.txt.gz?level=TRACE#_2015-08-18_10_28_01_314
** Affects: neutron
Importance: High
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
--
You received
On 13 August 2015 at 09:50, John Garbutt wrote:
> On Wednesday, August 12, 2015, Thierry Carrez
> wrote:
>
>> Gary Kotton wrote:
>> >
>> > On 8/12/15, 12:12 AM, "Mike Perez" wrote:
>> >> On 15:39 Aug 11, Gary Kotton wrote:
>> >>> On 8/11/15, 6:09 PM, "Jay Pipes" wrote:
>> >>>
>> Are you s
I have been hit by these failures as well.
I think you did well by bumping out that revert from the queue; I think it
simply cures the sympton possibly affecting correct operations of the
firewall service.
If we are looking at removing the sympton on the API job, than I'd skip the
failing tests whi
Kyle,
I can speak very little about the QoS branch, but from what I gather it is
mature enough to be merged back.
However, I believe the Pecan work is still incomplete as we need a solution
to run the RPC over AMQP server independently. Once we have that we can
start merging back what we have.
Sa
: neutron
Importance: Undecided
Status: New
** Affects: neutron/juno
Importance: Undecided
Status: New
** Affects: vmware-nsx
Importance: Undecided
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
** Also affects: neutron
Importance
IP isn’t working.
>
>
>
> I am able to ssh to the same machine with the floating IP outside
> Openstack but internally it doesn’t seem to work. My goal here is to ssh
> within an instance using the floating IP.
>
>
>
> Thank you,
>
> Aishwarya
>
>
>
&g
Why are you focusing on authentication issues when it seems you have either
a sshd config issue or a connectivity problem?
Indeed your ssh handshake is stopping quite early - see below:
debug1: Connecting to 192.168.1.250 [192.168.1.250] port 22.
debug1: Connection established.
debug1: Enabling c
More comments inline.
Salvatore
On 31 July 2015 at 01:47, Kevin Benton wrote:
> The issue is that the Neutron credentials might not have privileges to
> resolve the name to a UUID. I suppose we could just fail in that case.
>
>
As quota-update is usually restricted to admin users this should no
To the best of my knowledge Neutron is unable to enforce tenant quotas
using the tenant name; this should be "undocumented".
What Kevin suggests also goes in this direction, even if we have to be
careful as we're making assumptions on how tenant ids are represented (if
the deployment is not using K
subsequent db operation will fail)
[1]
http://git.openstack.org/cgit/openstack/vmware-nsx/tree/vmware_nsx/neutron/plugins/vmware/plugins/base.py#n1573
** Affects: neutron
Importance: Undecided
Assignee: Salvatore Orlando (salvatore-orlando)
Status: New
** Affects: neutron
Public bug reported:
This extension can be supported without effort by the NSX-mh plugin and
it should be added to supported extension aliases.
** Affects: neutron
Importance: Undecided
Status: New
** Affects: neutron/juno
Importance: Undecided
Status: New
** Affects
oslo_service is dumping option values already. Probably neutron does not
need to do that anymore.
** Affects: neutron
Importance: Medium
Assignee: Salvatore Orlando (salvatore-orlando)
Status: In Progress
** Changed in: neutron
Assignee: (unassigned) => Salvatore Orla
For my low-orbit perspective (I would have lied if I said 10,000 or 30,000
ft!) Kuryr's ultimate goal is to provide:
1) a container-oriented set of neutron plugins and drivers (you know the
ML2 driver, a l3 svc plugin, a lbaas driver, etc. etc.)
2) possibly (I'm not sure if that's the case) control
rk might be given distinct tags on distinct hosts.
I hope I got your question right!
> Regards
>
> 2015-07-23 16:58 GMT+02:00 Salvatore Orlando :
>
>> When you manually setup IP addressing on the VMs, are they able to ping
>> each other?
>> The issue you are descr
When you manually setup IP addressing on the VMs, are they able to ping
each other?
The issue you are describing is compatible with a scenario where both the
dhcp agent and the l3 agent on the same "network node", and that node gets
disconnected from the rest of the fabric.
This could be for sever
I reckon that this approach makes sense, as it alters very little OVN's
northbound schema; moreover at first glance I do not see in the patch
series any change to the OVN pipeline.
Also mapping neutron provider networks extension onto OVN should not be too
difficult. Perhaps neutron will have to d
This makes sense to me as well.
It's surely better to have structured data rather then encode them in
resource names.
In the options attribute for a "local" logical port, I guess the "name"
attribute will be the name of some ovs bridge instance where the port is
plugged.
From a neutron integratio
A few comments inline.
Generally speaking the only thing I'd like to remark is that this use case
makes sense independently of whether you are using overlay, or any other
"SDN" solution (whatever SDN means to you).
Also, please note that this thread is now split in two - there's a new
branch star
It is not possible to constrain this attribute to an enum, because there is
no fixed list of device owners. Nevertheless it's good to document know
device owners.
Likewise the API layer should have checks in place to ensure accidental
updates to this attributes do not impact control plane function
Do you reckon that the process that led to creating a migration like [1]
should also be documented in devref?
That might be helplful for developers, unless that process is already
documented elsewhere.
Salvatore
[1] https://review.openstack.org/#/c/202013/1
On 15 July 2015 at 15:54, Mike Bayer
Some comments inline.
Salvatore
On 15 July 2015 at 10:24, Alex Xu wrote:
>
>
> 2015-07-15 5:14 GMT+08:00 Matt Riedemann :
>
>>
>>
>> On 7/14/2015 3:43 PM, Cale Rath wrote:
>>
>>> Hi,
>>>
>>> I created a patch to fail on the proxy call to Neutron for used limits,
>>> found here: https://review.o
Yes please.
This would be a good starting point.
I also think that the ability of editing it, as well as the value it could
be set to, should be constrained.
As you have surely noticed, there are several code path which rely on an
appropriate value being set in this attribute.
This means a user c
Some pedant comments inline.
Salvatore
On 13 July 2015 at 23:29, Russell Bryant wrote:
> On 07/13/2015 05:08 PM, Kevin Benton wrote:
> > Thanks for the info. So the equivalent in neutron would be if we just
> > ensure backward compatible AMQP APIs, right?
>
> There's a few parts:
>
> 1) Backwar
Public bug reported:
you know what? meh.
** Affects: neutron
Importance: Undecided
Status: Invalid
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https
I agree and I would make the switch as soon as possible. The graphite graph
you posted showed that since 6/28 the difference in failure rate is such
that isn't even statistically significant. However, spikes in failure rates
of the unstable job also suggest that you're starting to chase a moving
ta
Reading your post and the associated patch it seems that you're treating
the physical network as a logical port from a pipeline perspective but
exposing it as a logical switch attribute from a NB DB perspective. Is that
correct?
If my previous statement is correct, I wonder why not treat it always
Hello Marco,
more comments inline.
Salvatore
On 7 July 2015 at 22:09, Marco Mariani wrote:
> 2015-07-07 20:52 GMT+02:00 Salvatore Orlando :
>
> If I understand correctly your use case security groups can be probably
>> used to satisfy your goal with Neutron.
>>
>>
1 - 100 of 1094 matches
Mail list logo
