The bug has nothing to do with upstream neutron project, hence removing
it.
** No longer affects: neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1652748
Title:
Sometimes the
Public bug reported:
When a network contains several subnets (especially ipv4 + ipv6) DHCP
agent may spawn dnsmasq incorrectly, so tag in the command line (--dhcp-
range) will not match the tag in opts file.
This leads to a state when dnsmasq sends it's IP address as a default
gateway.
As a
This is expected behavior.
Node time being in sync with other nodes and not being adjusted severily is
critical for agent status to work properly.
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
n.agent.l3.dvr_router for
gw_fixed_ip in gateway['fixed_ips']:
2016-05-01 18:09:57.907 733 TRACE neutron.agent.l3.dvr_router TypeError:
'NoneType' object has no attribute '__getitem__'
It doesn't seem to make any functional impact.
** Affects: neutron
Importance: Medium
Assignee: Eugene
Importance: Undecided
Assignee: Eugene Nikanorov (enikanorov)
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/bugs/1564144
Title:
Sometimes L3 rpc update operations
of this deadlock various side effects could arise such as
port binding failures or resource rescheduling.
** Affects: neutron
Importance: Undecided
Assignee: Eugene Nikanorov (enikanorov)
Status: In Progress
** Changed in: neutron
Assignee: (unassigned) => Eugene Nikano
Multiple external networks are supported.
** 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://bugs.launchpad.net/bugs/1541191
Title:
Limit to create only one
Status: Confirmed => Invalid
** Changed in: neutron
Assignee: Eugene Nikanorov (enikanorov) => (unassigned)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1540555
Title:
Having multiple subnets sharing the same cidr is ok even for one tenant.
So you're observing by-design behavior.
If you want unique cidrs for the tenant, you need to use subnet pools.
** Changed in: neutron
Status: New => Opinion
--
You received this bug notification because you are a
: Wishlist
Assignee: Eugene Nikanorov (enikanorov)
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/1529100
Title:
OVSBridge.delete_port method performance could
Public bug reported:
It's being passed here and there without actual use.
Tests also pass None or mock.ANY.
It makes sense to cleanup the code a little bit.
** Affects: neutron
Importance: Wishlist
Assignee: Eugene Nikanorov (enikanorov)
Status: In Progress
--
You received
Public bug reported:
subnet listing of 100 subnets takes about 2 seconds on a powerfull hardware.
60% of the time is consumed by the calculation of 'shared' attribute of the
subnet which involves rbac rules.
This makes horizon barely usable as number of networks grow.
** Affects: neutron
Removing duplicate to perform additional checks
** This bug is no longer a duplicate of bug 1478925
Instances on the same compute node unable to connect to each other's ports
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
*** This bug is a duplicate of bug 1478925 ***
https://bugs.launchpad.net/bugs/1478925
** This bug has been marked a duplicate of bug 1478925
Instances on the same compute node unable to connect to each other's ports
--
You received this bug notification because you are a member of
That looks like a support request rhather than a bug.
You should not add iptables rules directly to neutron namespaces, because
they're managed by neutron.
There's no guarantee that that manually added rule will persist.
You should be doing this via security groups or floatingips using
neutorn
, however it's better to provide
a consistentsy over operations with bridges's flows.
** Affects: neutron
Importance: Low
Assignee: Eugene Nikanorov (enikanorov)
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which
I would question the issue itself.
Processing 860 networks in 30 seconds is much much better than Juno has.
Since we had rootwrap demon, processing time reduced significantly.
You can increase num_sync_threads in dhcp_agent.ini from default value
of 4 to higher and see if it helps.
** Changed
** Changed in: neutron
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1394165
Title:
L3 and DHCP agents may hang while processing a router or a
Assignee: Eugene Nikanorov (enikanorov)
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/bugs/1509959
Title:
Stale DHCP ports remain in DHCP namespace
Status in neutron
for each of networks.
** Affects: neutron
Importance: Medium
Assignee: Eugene Nikanorov (enikanorov)
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/1506092
Title
*** This bug is a duplicate of bug 1388698 ***
https://bugs.launchpad.net/bugs/1388698
** This bug has been marked a duplicate of bug 1388698
dhcp_agents_per_network does not work appropriately.
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
ailed or conflicting state
(dhcp/router namespaces, ports with binding_failed).
They should be either deleted or syncronized with server state.
** Affects: neutron
Importance: Undecided
Assignee: Eugene Nikanorov (enikanorov)
Status: In Progress
--
You received this bug noti
connectivity.
** Affects: neutron
Importance: Undecided
Assignee: Eugene Nikanorov (enikanorov)
Status: In Progress
** Tags: neutron-core
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https
*** This bug is a duplicate of bug 1411163 ***
https://bugs.launchpad.net/bugs/1411163
** This bug has been marked a duplicate of bug 1411163
No fdb entries added when failover dhcp and l3 agent together
--
You received this bug notification because you are a member of Yahoo!
Engineering
I'm not sure whole use case is valid.
DHCP for the subnet should be managed by neutron only, otherwise subnet should
have DHCP disabled and IPs should be allocated via other means.
** Changed in: neutron
Status: In Progress => Opinion
--
You received this bug notification because you
>From API perspective, there is no restriction on port ownership within one
>tenant.
If tenant wants to change the ownership - it can do that. Also, there is no
problems with atomicity, because API calls act quite atomically.
What you are looking for is transactional semantics where such
://paste.openstack.org/show/474339/
That may indicate that the table is a contention point.
Slowdown may be caused by constant retries.
** Affects: neutron
Importance: High
Assignee: Eugene Nikanorov (enikanorov)
Status: Confirmed
** Tags: scale
--
You received this bug notification
** Also affects: mos
Importance: Undecided
Status: New
** No longer affects: neutron
** Changed in: mos
Assignee: (unassigned) => Eugene Nikanorov (enikanorov)
** Changed in: mos
Importance: Undecided => High
** Changed in: mos
Status: New => Confirmed
Please file a bug against SUSE, upstream project doesn't track packaging
for particular distros
** 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.
Seems to be invalid for neutron
** 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://bugs.launchpad.net/bugs/1499381
Title:
Openstack Kilo Nova-Docker:P of
** Project changed: neutron => nova
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1499383
Title:
Openstack Kilo Nova-Docker:Container will be hung in "powering-on"
** Project changed: neutron => nova
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1499393
Title:
Openstack Kilo Nova-Docker:Container states are not sync up between
** Project changed: neutron => nova
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1499397
Title:
openstack Kilo Nova-Docker:Container will be hung in "powering-on"
Public bug reported:
Currently only parent neutron process consumes messages from service queues
such as l3-plugin.
In case of DVR with many L3 agents on computes that can quickly lead to
different issues because there is not enough speed of RPC requests processing.
That is actually a problem
That can't be a neutron/lbaas bug. Please file for CentOS/haproxy
** 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://bugs.launchpad.net/bugs/1498506
Title:
scheduling which loads neutron-server even
more, creating self-sustaining loop.
** Affects: neutron
Importance: Undecided
Assignee: Eugene Nikanorov (enikanorov)
Status: New
** Tags: neutron-core
--
You received this bug notification because you are a member of Yahoo!
Engine
Public bug reported:
This is important for DVR clusters with lots of L3 agents.
Right now L3 queue is only consumed by parent process of neutron-server.
** Affects: neutron
Importance: Undecided
Assignee: Eugene Nikanorov (enikanorov)
Status: New
** Tags: neutron-core
** No longer affects: mos
** No longer affects: mos/7.0.x
** No longer affects: mos/8.0.x
** Description changed:
Neutron tries to bind port on compute where instance is launched. It
- doesn't make sense when hypervisor_type is ironic, since VM not lives
- on hypervisor in this case.
s: neutron
Importance: Medium
Assignee: Eugene Nikanorov (enikanorov)
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/bugs/1491361
Title:
Trace seen in L3
** Changed in: neutron
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1174657
Title:
metadata IP 169.254.169.254 routing breaks RFC3927 and does
lized-SNAT port %s already seen on "),
port.vif_id)
LOG.error(_LE("a different subnet %s"), subs[0])
return
** Affects: neutron
Importance: Medium
Assignee: Eugene Nikanorov (enikanorov)
Status: Invalid
**
not there,
tries to add it - it's already there, then it tries to fetch it again, but due
to REPEATABLE READ isolation method, the query returns empty result.
As a result, such logic will hang in the loop forever.
** Affects: neutron
Importance: High
Assignee: Eugene Nikanorov (enikanorov
** 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://bugs.launchpad.net/bugs/1465687
Title:
use fixed ip address cannot ping/ssh instance from controller node
binding:vif_type is an attribute from a different table, not 'ports'
table, you can't filter by that attribute.
** Changed in: neutron
Status: New = Opinion
** Tags added: api
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed
** Changed in: neutron
Importance: Undecided = Medium
** Project changed: neutron = python-neutronclient
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1467504
Title:
Health monitor
The only way to get external connectivity via tenant network is to setup
so-called provider network.
It would be a tenant network going through specifically configured bridges and
having fixed cidr which is a part of global ipv4 pool.
Other than that VMs can't be plugged into an external
Please use ask.openstack.org for usage questions.
** 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://bugs.launchpad.net/bugs/1419760
Title:
nova
for
DHCP agents to do full sync or request available networks.
This can be solved from agent side, but preferable way is to not remove
network from agents if there are no alive agents available.
** Affects: neutron
Importance: Medium
Assignee: Eugene Nikanorov (enikanorov
to let DHCP agent inject such route by default via
dnsmasq config.
** Affects: neutron
Importance: Medium
Assignee: Eugene Nikanorov (enikanorov)
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron
Agree with Itzik's analysis.
Closing as '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://bugs.launchpad.net/bugs/1456809
Title:
L3-agent not
this is not a neutron bug, please be more attentive.
** Project changed: neutron = nova
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1439870
Title:
Fixed IPs not
: High
Assignee: Eugene Nikanorov (enikanorov)
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/1458119
Title:
Improve stability and robustness of periodic agent
Doesn't apply for master, only applies for Juno+
** Changed in: neutron
Status: New = Won't Fix
** Changed in: neutron
Assignee: Eugene Nikanorov (enikanorov) = (unassigned)
** Summary changed:
- Improve user-facing log message of ovs agent when it can't find an interface
+ message
Public bug reported:
In case ovs-agent can't find interface by given VM id, it prints a
warning Unable to parse interface details. Exception: list index out
of range
That doesn't look user-friendly and is misleading.
** Affects: neutron
Importance: Medium
Status: Won't Fix
**
After going deeper into recent network mtu feature, it appeared that it
solves this issue by allowing to configure mtu for the external network.
** Changed in: neutron
Status: New = Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which
-
** Affects: neutron
Importance: Undecided
Assignee: Eugene Nikanorov (enikanorov)
Status: New
** Tags: l3-ipam-dhcp
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs
, or its row is otherwise
not present.
** Affects: neutron
Importance: Medium
Assignee: Eugene Nikanorov (enikanorov)
Status: New
** Tags: db
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https
not be enough in some rare unlucky cases under extreme concurrency.
We need to randomize segmentation_id selection to avoid such issues.
** Affects: neutron
Importance: Medium
Assignee: Eugene Nikanorov (enikanorov)
Status: New
--
You received this bug notification because you
-08_00_54_04_657
** Affects: neutron
Importance: High
Assignee: Eugene Nikanorov (enikanorov)
Status: Confirmed
** Tags: db
** Changed in: neutron
Assignee: (unassigned) = Eugene Nikanorov (enikanorov)
** Tags added: db
** Changed in: neutron
Importance: Undecided = High
Assignee: Eugene Nikanorov (enikanorov)
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/1453320
Title:
Create periodic task that logs agent's state
Status in OpenStack
are not logged at all on server side.
Since on a large cluster that could create too much logging (even for
troubleshooting cases), it might make sense to make this configurable both on
neutron-server side and on agent-side.
** Affects: neutron
Importance: Wishlist
Assignee: Eugene Nikanorov
** Project changed: neutron = python-neutronclient
** Changed in: python-neutronclient
Importance: Undecided = Low
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1451391
Title:
I believe cidr should go last per command help, isn't it?
** Project changed: neutron = python-neutronclient
** Changed in: python-neutronclient
Status: New = Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Usually new features are tracked via blueprints, not bugs, and require
spec to be merged.
Is there a blueprint regarding this feature?
** Changed in: neutron
Status: New = Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
what auth_url are you providing when making the call?
** Project changed: neutron = python-neutronclient
** Changed in: python-neutronclient
Status: New = Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
** Project changed: neutron = horizon
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1449544
Title:
Neutron-LB Health monitor association mismatch in horizon and
** Project changed: neutron = horizon
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1449546
Title:
Neutron-LB Health monitor association not listed in Horizon
It's by design behavior, marking bus as Invalid
** Summary changed:
- When VM security group is not choose,the packets is still block by security
group
+ When VM security group is not choosen, the packets are still blocked by
default
** Summary changed:
- When VM security group is not
I'm not sure this bug should be filed against upstream neutron. Marking
as 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.
This behavior is a result of commit
https://review.openstack.org/#/c/113339/
It should have had DocImpact in commit msg.
Anyway, marking the bug as Invalid since behavior is by-design.
** Changed in: neutron
Status: Confirmed = Invalid
--
You received this bug notification because you
that test base plugin as a DB mixin.
** Affects: neutron
Importance: Wishlist
Assignee: Eugene Nikanorov (enikanorov)
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https
Public bug reported:
Currently many of l3dvrdb mixin method names are not started with
underscore where they are really local to the l3dvr mixin class.
Let's make code a little bit clearer for a reader and clean up the
naming.
** Affects: neutron
Importance: Wishlist
Assignee: Eugene
IMO, this just needs to be documented.
Obviously ports that go first get their fixed IPs allocated and later port
creation may fail if some port specifies already-allocated IP.
I don't think it makes sense to arrange input port list in anyway.
** Changed in: neutron
Status: Confirmed =
Public bug reported:
Logstash query:
Changing back to high as it was discovered another condition which could
lead autorescheduling loop to fail
** Changed in: neutron
Status: Fix Released = In Progress
** Changed in: neutron
Importance: Medium = High
--
You received this bug notification because you are a member of
This bug was apparently fixed by
https://review.openstack.org/#/c/160913/
** Also affects: devstack
Importance: Undecided
Status: New
** Changed in: devstack
Status: New = Fix Committed
** No longer affects: neutron
--
You received this bug notification because you are a
I'm afraid it's not correct to file a bug against neutron, but referring
to cisco-openstack repository
** 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.
This has been raised multiple times in the past.
Neutron doesn't verify tenant_id against keystone. It's assumed that regular
user calls neutron being authenticated.
And admin presumably know what he is doing.
I don't think we need to do anything with this issue, especially in the
scope of such
That's hard to triage such kind of bugs without of knowledge of particular
backend.
Is there an evidence that neutron needs to be fixed and it's not a backend
issue?
** Changed in: neutron
Importance: Undecided = Low
** Changed in: neutron
Status: New = Opinion
--
You received this
that might be a bug with migrations in icehouse version which probably
will not be fixed.
** Changed in: neutron
Status: New = Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
This probably is too old report to be relevant for current project
status
** Changed in: neutron
Status: In Progress = Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
This is a problem of keystone which in turn causes failures in neutron-nova
communication.
I don't think neutron can be fixed to avoid this.
** Changed in: neutron
Status: In Progress = Confirmed
** Changed in: neutron
Status: Confirmed = Invalid
--
You received this bug
That's better to be discussed with fwaas team first. Description doesn't
look like a valid bug report.
** Changed in: neutron
Status: New = Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
Public bug reported:
Use oslo.db common retrying decorator rather than retrying library.
Also, get rid of home-grown code in favor of oslo.db
** Affects: nova
Importance: Undecided
Assignee: Eugene Nikanorov (enikanorov)
Status: New
** Changed in: nova
Assignee
Looking at discussion on the review I have doubts that we should fix
that at all
** Tags added: api
** Changed in: neutron
Status: New = Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
This looks like deep rework of current messaging strategy and probably
should be worked on within a scope of a blueprint rather than a bug.
So I would suggest to file a bp for this and provide a spec explaining
these ideas so spec review could be a better place to discuss these
ideas.
** Changed
** Also affects: openstack-api-site
Importance: Undecided
Status: New
** No longer affects: neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1418635
Title:
Neutron API
Public bug reported:
Start protected method names with underscores to indicate how they're
going to be used.
This is convinient when understanding class relationships.
** Affects: neutron
Importance: Wishlist
Assignee: Eugene Nikanorov (enikanorov)
Status: In Progress
://logs.openstack.org/17/165117/6/check/check-tempest-dsvm-neutron-
pg/7017248/logs/screen-q-svc.txt.gz?level=TRACE
** Affects: neutron
Importance: High
Assignee: Eugene Nikanorov (enikanorov)
Status: Confirmed
** Description changed:
- The following traceback has been observed
** 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://bugs.launchpad.net/bugs/1430832
Title:
Rally error Failed to delete network for tenant with scenario
devices.
Total time needed to process all such RPC requests that were caused by 1 VM
spawn may reach tens of cpu-seconds.
** Affects: neutron
Importance: Medium
Assignee: Eugene Nikanorov (enikanorov)
Status: New
--
You received this bug notification because you are a member
the agent hosts the more chances that processing of some
network.delete.end notification would appear after dhcp is enabled on
that network.
** Affects: neutron
Importance: Medium
Assignee: Eugene Nikanorov (enikanorov)
Status: New
--
You received this bug notification because you
not present.
Need to avoid accessing db object after it has been deleted from db as
attribute access may trigger this exception.
This issue terminates periodic task of rescheduling networks.
** Affects: neutron
Importance: High
Assignee: Eugene Nikanorov (enikanorov)
Status: New
2015-02-21 14:45:15.927 1417 TRACE neutron.db.agentschedulers_db
Need to print saved agent_id instead of using db object.
** Affects: neutron
Importance: Low
Assignee: Eugene Nikanorov (enikanorov)
Status: New
--
You received this bug notification because you are a member
So apparently this issue along with some others were caused by unstable
work of rabbitmq in certain conditions in certain environment.
I don't see an issue on neutron side for now.
** Changed in: neutron
Status: New = Invalid
** Changed in: neutron
Assignee: Eugene Nikanorov
Removing Neutron project.
** Also affects: tempest
Importance: Undecided
Status: New
** No longer affects: neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1424099
** Changed in: neutron
Status: Fix Released = In Progress
** Changed in: neutron
Milestone: kilo-2 = kilo-3
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1382064
Title:
** Changed in: neutron
Status: In Progress = Invalid
** Changed in: neutron
Assignee: Eugene Nikanorov (enikanorov) = (unassigned)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net
Observed behavior applies to Juno release and was fixed later.
** Changed in: neutron
Status: In Progress = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1419745
Title:
leads to connectivity failure of whole
node, because tunnels are not set up properly.
** Affects: neutron
Importance: High
Assignee: Eugene Nikanorov (enikanorov)
Status: New
** Tags: ovs
** Description changed:
- The following trace was observed:
+ The following trace
1 - 100 of 304 matches
Mail list logo
