Public bug reported:
There may be a race condition involving dnsmasq startup and port
operations. What appears to happen is that dnsmasq is started but the
pid file isn't available when a port change occurs. The dhcp agent then
attempts to start a new dnsmasq instance even though the previous one
Public bug reported:
>From the debug logs, it looks like the dhcp agent continually checks for
an pid file for an external process that is not expected. e.g.:
DEBUG neutron.agent.linux.utils [-] Unable to access
/opt/stack/data/neutron/external/pids/17951cd9-d28e-
4ea9-9238-f97652690c59.pid {{(pi
This appears to have been fixed by
https://review.openstack.org/#/c/361315/.
** Changed in: puppet-neutron
Status: New => 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
** Also affects: tripleo
Importance: Undecided
Status: New
** Changed in: tripleo
Status: New => Triaged
** Changed in: tripleo
Importance: Undecided => Critical
** Changed in: tripleo
Milestone: None => rocky-3
--
You received this bug notification because you are a me
** Project changed: os-vif => 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/1713590
Title:
Plugging VFs no longer works without a readable phys_switch_id
Status in neutron:
T
Public bug reported:
There are sporadic failures occurring during CI testing where vif plug
notifications aren't being generated by neutron. This results in
occasional vif plug timeouts when spawning instances.
See
http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22T
Public bug reported:
Networking related commands for Bigswitch that run under rootwrap are
used by nova compute to perform VIF plug operations whether nova-network
is used or not. If an installer only includes compute.filters on compute
nodes, these operations will fail.
While I don't have a prec
Public bug reported:
In investigating an MTU issue, an accounted-for overhead of 4 bytes was
discovered. A spurious 802.1q header was discovered using tcpdump when
attempting to connect to a guest via floating IP. The tenant network
type is VXLAN and the VXLAN endpoints themselves are on a VLAN. T
** Project changed: puppet-tripleo => puppet-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/1585699
Title:
Neutron Metadata Agent Configuration - nova_metadata_ip
Status in neut
Public bug reported:
Note: This is with libvirt < 1.3.0 so may be specific to earlier
versions. This has also been verified on mitaka only so far. I haven't
had a chance to try on newton/master. It may have something to do with
the fact that PFs don't have parent_addrs'
Either with devname or add
Might be mistargeted or at the very least no longer relevant.
** Changed in: tripleo
Status: Triaged => Invalid
--
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/11745
Marking as invalid for tripleo as well.
** Changed in: tripleo
Status: Triaged => 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/1184519
Title:
after quantum API downtime
I've marked as invalid for tripleo as it isn't clear from the
description how this is specific to tripleo and the neutron aspect has
been resolved.
** Changed in: tripleo
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
Public bug reported:
In HA, there is a potential race condition between the openvswitch agent
and other agents that "own", depend on or manipulate ports. As the
neutron server resumes on a failover it will not immediately be aware of
openvswitch agents that have also been activated on failover and
Public bug reported:
LibreSwan requires that a connection's ipsec.secrets be owned by root.
This was handled in a recent patch. However, normal code flow in
neutron-vpnaas recreates the file on agent restart, which it fails to do
because the file is now owned by root and it can't overwrite it.
Th
process and
due to strict permission checks through "capabilities", this actually
results in a failure to establish connections with LibreSwan since pluto
runs as root. This seems to be LibreSwan specific.
** Affects: neutron
Importance: Undecided
Assignee: Brent Eagle
I removed neutron from this bz after confirming that the binding_failed
is a valid state and indicates a potentially transient condition.
** No longer affects: neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
http
Why doesn't neutron indicate an error has occurred through an exception?
Is the port still valid even when this error has occurred?
** Also affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, whic
/1254555
https://bugs.launchpad.net/neutron/+bug/1251982
https://bugs.launchpad.net/neutron/+bug/1280738
** Affects: neutron
Importance: Undecided
Assignee: Brent Eagles (beagles)
Status: New
** Changed in: neutron
Assignee: (unassigned) => Brent Eagles (beagles)
--
You recei
*** This bug is a duplicate of bug 1291489 ***
https://bugs.launchpad.net/bugs/1291489
It was originally reported against Havana. I would agree that the patch
and the backport should fix the issue, so I'll close this BZ. Thanks,
cyeoh for spotting this (and lcostantino for fixing :)).
** Thi
Public bug reported:
In nova/api/openstack/compute/contrib/security_groups.py, the
ServerSecurityGroupController.index(...) method does not handle the
situation where security_group_api.get_instance_security_groups()
returns None (as might be the case when neutron is the security group
impl) resul
** Changed in: nova
Status: Invalid => Incomplete
--
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/1304409
Title:
VMs can't be booted with networks without subnet
** No longer affects: 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/1328647
Title:
DeprecationWarning is globally enabled
Status in Oslo - a Library of Common Ope
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Assignee: (unassigned) => Brent Eagles (beagles)
** Changed in: oslo
Assignee: (unassigned) => Brent Eagles (beagles)
--
You received this bug notification because you are a member of
Public bug reported:
The default dhcp lease time is fairly short (120s). Is this simply a
hold-over from the time before force_dhcp_release was the default and
dhcp_release was expected throughout or is there another reason for the
default to be so brief?
** Affects: nova
Importance: Undecid
Is this really affecting the keystoneclient as well or was it simply
that the wrong project was picked when the bz was submitted?
** Also affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
** Also affects: neutron
Importance: Undecided
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/1269060
Title:
Calls to get_fixed_ip are not implemented when using ne
The above comment appears in code that is in internal RPC server, not
the nova-network API implementation. It seems reasonable that we should
implement it.
** Also affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo
The abovementioned code is not in the nova-network API implementation.
AFAICT this does need to be implemented.
** Also affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to n
Public bug reported:
The add_project_to_network method in the nova.network.neutronv2.api
module is not implemented. It is unclear that this API could reasonably
be implemented in this case, but if the use case exists for nova's api
in the first place it is worthwhile to objectively review this.
*
Public bug reported:
The following methods in nova.network.neutron.v2.api are not implemented
(well, they throw NotImplemented exceptions)
- create_private_dns_domains
- create_public_dns_domains
- get_dns_entries_by_address
- get_dns_entries_by_name
- get_dns_domains
- add_dns_entry
- modify_dns
Public bug reported:
The get_vifs_by_instance() call in the nova.network.neutronv2.api module
is not implemented.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Op
Public bug reported:
The get_vif_by_mac_address() method in the nova.network.neutronv2.api
module is not implemented.
** Affects: nova
Importance: Undecided
Status: New
** Tags: network
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, wh
Public bug reported:
The get_fixed_ip() the nova.network.neutronv2.api module is not
implemented.
** Affects: nova
Importance: Undecided
Status: New
** Tags: network
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
34 matches
Mail list logo
