Public bug reported:
When doing a port update (put) specifying the allowed address pair
attribute, the api returns a 200, but the attribute is not actually
updated. An example from a Tempest test run follows:
1) The following request was executed:
Request: PUT
http://172.16.0.2:9696//v2.0/ports
enstack.org/quantum/api/v2.0";
xmlns:quantum="http://openstack.org/quantum/api/v2.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Invalid data
format for extra-dhcp-opt: {'extra_dhcp_opt': {'opt_value': '123.123.123.45',
Why is this a bug? I looked in the entire Neutron code.
global_request_id is only used once here:
https://github.com/openstack/neutron/blob/a33588b08639bd4bb78e632eb1fb2600a96aeb44/neutron/notifiers/nova.py#L83.
And it is generated. So how is the absence of global_request_id in the
Neutron context
Invalid for now, unless submitter further clarifies
** 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/1939374
Title:
[OVN] Support bare
In that case I'll mark it invalid for now. We can change it if we find
more evidence
** 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/193
:
exit_trap
This terminates the execution of devstack/stack.sh
This job currently runs on Fedora 34
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: Confirmed
** Changed in: neutron
Status: New => Confirmed
** Changed in: neutron
Fix was merged and job is green again:
https://zuul.opendev.org/t/openstack/build/a063fb7cd33e4f858d42e5613b246f64
** 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 neu
accordingly.
The docs that need update are:
- https://docs.openstack.org/neutron/latest/admin/config-dns-int.html
- https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: Confirmed
Based on the information at hand, I don't think this is a bug. The
upstream Neutron team tests the linuxbridge agent with every patch that
is submitted for the stable/xena branch:
https://review.opendev.org/q/project:openstack%252Fneutron+branch:stable%252Fxena+status:open
. One example is
https://
Haven't heard back from submitter in two months. Will mark it invalid.
Please feel free to restore it in case there is interest in continuing
this conversation
** Changed in: neutron
Importance: Wishlist => Undecided
** Changed in: neutron
Status: New => Invalid
--
You received this b
It's been more than four months since last time we heard from submitter.
Marking this RFE as invalid. If there is interest in continue the
conversation, please fell free to change the status back to "New"
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification
This bug should be filed against python-openstackclient
** Project changed: neutron => python-openstackclient
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1821311
Title:
openstack rou
%22test_connectivity_through_2_routers%5C%22%20AND%20build_status:%5C%22FAILURE%5C%22%20AND%20build_branch:%5C%22master%5C%22%20AND%20build_name:%5C
%22neutron-tempest-plugin-dvr-multinode-
scenario%5C%22%20AND%20project:%5C%22openstack%2Fneutron%5C%22
** Affects: neutron
Importance: High
Assignee: Miguel Lavalle
Hi Yang,
Thanks for the follow up. Closing this RFE
** Tags removed: rfe
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1825336
Ti
** Changed in: neutron
Status: Fix Released => Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1824571
Title:
l3agent can't create router if there are multiple external n
Marking it as "Won't fix" since it is not a Neutron bug
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1832574
Title:
Able to upda
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: Confirmed
** Changed in: neutron
Importance: Undecided => Medium
** Changed in: neutron
Assignee: (unassigned) => Miguel Lavalle (minsel)
** Description changed:
As of the reporting of th
This is not a bug. Please read carefully the doc string for the
network_vlan_ranges config option:
https://github.com/openstack/neutron/blob/78aae12a88e8b3cc0609c830527533b8a8a92d60/neutron/conf/plugins/ml2/drivers/driver_type.py#L71-L77.
In particular, please note the last part of that doc string:
Thanks for your report. While the server shouldn't return a 500, your
request is incorrect. I tested this in my local environment with the
following request:
PUT $APIIP:9696/v2.0/policies//tags
Request body:
{
"tags": ["sss","v"]
}
and the response
Public bug reported:
Ironic events notifier needs to be migrated from ironicclient to
openstacksdk
** Affects: neutron
Importance: High
Assignee: Harald Jensås (harald-jensas)
Status: In Progress
** Changed in: neutron
Status: New => Confirmed
** Changed in: neutron
This bug seems to be closed by https://review.opendev.org/#/c/744753, so
closing it here as well
** Changed in: 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.launc
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: New
** Changed in: neutron
Assignee: (unassigned) => Miguel Lavalle (minsel)
** Changed in: neutron
Importance: Undecided => Medium
--
You received this bug notification because you are a member
Public bug reported:
RESOURCE_NAME and COLLECTION_NAME are incorrectly defined in neutron-
lib: https://github.com/openstack/neutron-
lib/blob/2dabcc5cf7d68bf2a4640f07d5e170aa8b911390/neutron_lib/api/definitions/address_group.py#L25-L26
Their definitions should have '_' instead of '-'. This incor
sn't carry the deleted resource,
because it was already deleted. In fact,
https://review.opendev.org/c/openstack/neutron/+/876716/1/neutron/api/rpc/handlers/securitygroups_rpc.py
tried to fix the bug processing a security group AFTER_DELETE event,
which seems logically consistent to
Gerrit to illustrate the
intent of this proposal:
https://review.opendev.org/c/openstack/neutron/+/883988
** Affects: neutron
Importance: Wishlist
Assignee: Miguel Lavalle (minsel)
Status: In Progress
** Changed in: neutron
Importance: Undecided => Wishlist
** Changed
Public bug reported:
In the neutron-tempest-plugin-ovn job, the neutron server log is full of
the following error:
Jun 16 12:44:13.388278 np0034319125 neutron-server[83462]: DEBUG
neutron.plugins.ml2.drivers.ovn.mech_driver.ovsdb.ovsdb_monitor [None
req-7cbd9fa8-94fb-4740-b7e9-afa577da1f57 None
*** This bug is a duplicate of bug 2024447 ***
https://bugs.launchpad.net/bugs/2024447
Never mind, fix merged
https://review.opendev.org/c/openstack/neutron/+/886457
** This bug has been marked a duplicate of bug 2024447
[OVN] "_load_hash_ring" is couting the hash righ nodes without openin
This LP doesn't seem to be a valid bug, based on the feedback provided
in the associated code review:
https://review.opendev.org/c/openstack/neutron/+/899374. Let's continue
the conversation in Gerrit and we can reclassify this LP based on that
conversation
** Changed in: neutron
Status: In
As you can see in the unit test failures of your proposed patch
(https://739b5b5aed9a6d447975-907323b417218f46df6192f35c6995f8.ssl.cf2.rackcdn.com/899373/1/check/openstack-
tox-py39/5433f4e/testr_results.html), the possibility of having subnet
empty allocation pools has long been assumed as valid b
Public bug reported:
While implementing router flavors providers for L3 OVN
(https://review.opendev.org/c/openstack/neutron/+/883988), it was
discovered that the Service Type Framework doesn't support loading those
providers using stevedore shortcuts. When that is attempted. the neutron
server gen
-+
The expected result is:
+---+---+
| Field | Value |
+---+---+
| ha| False |
+---+---+
[1] https://review.opendev.org/c/openstack/neutron/+/910889
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: Confirmed
**
ail:
https://github.com/openstack/neutron/blob/e003fd73f6ba17328f3e15a2cc2d199a630229ca/neutron/services/ovn_l3/service_providers/user_defined.py#L47
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: Confirmed
** Changed in: neutron
Status: New =&
mportance: High
Assignee: Miguel Lavalle (minsel)
Status: New
** Changed in: neutron
Importance: Undecided => High
** Changed in: neutron
Assignee: (unassigned) => Miguel Lavalle (minsel)
--
You received this bug notification because you are a member of Yahoo!
Engin
ns for
the eventual removal of the router interface.
** Affects: neutron
Importance: High
Assignee: Miguel Lavalle (minsel)
Status: New
** Changed in: neutron
Importance: Undecided => High
** Changed in: neutron
Assignee: (unassigned) => Miguel Lavalle (minsel)
** Also affects: neutron-vpnaas-dashboard
Importance: Undecided
Status: New
** Summary changed:
- Adding the "rekey" parameter to the api for strongswan like "dpd_action"
+ [RFE] Adding the "rekey" parameter to the api for strongswan like "dpd_action"
** Changed in: neutron
Importan
tion(expiration=2016-03-31T14:30:00Z,id=d35a8cb9-9dc1-46fe-af6d-b5b507d25d5d,project_id=,resource_deltas=[])]
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: Confirmed
** Changed in: neutron
Status: New => Confirmed
** Changed in: n
Public bug reported:
The following jobs in networking-ovn stable/train are failing:
networking-ovn-tempest-dsvm-ovs-release
networking-ovn-tempest-dsvm-ovs-release-python2
networking-ovn-rally-task
networking-ovn-octavia-v2-dsvm-scenario
The failure is:
Traceback (most recent call last):
File
Proposed fix in devstack-gate solved the problem
** 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/1992379
Title:
[stable/tr
Assignee: Miguel Lavalle (minsel)
Status: Confirmed
** Changed in: neutron
Importance: Undecided => Medium
** Changed in: neutron
Status: New => Confirmed
** Changed in: neutron
Assignee: (unassigned) => Miguel Lavalle (minsel)
--
You received this bug not
Hi,
Same comments as in #1 and #2 above from Neutron. To treat this as a
bug, we need more specific data. Marking it invalid until more is
reported
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, whi
Whereas we have discussed this in the past and we agreed to comply with
the spec for internal dns resolution
(https://specs.openstack.org/openstack/neutron-specs/specs/liberty
/internal-dns-resolution.html) as recorded here
http://eavesdrop.openstack.org/meetings/neutron_l3/2019/neutron_l3.2019-05-
I lean towards Neutron not having to handle infra-structure, especially
since the split brain partition state should be a transient and can be
handled by the deployment admin. I am marking this bug as won't fix. If
you think more discussion is warranted please feel free to change the
satus
** Chan
** Changed in: neutron
Status: In Progress => 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/1650678
Title:
[RFE] Allow specifying dns_domain when creating a port
St
** 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/1746996
Title:
bagpipe: IPAllocation DB query failing, engine facade mismat
** Changed in: neutron
Status: Expired => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1730845
Title:
[RFE] support a port-behind-port API
Status in neutron:
Incom
Mar 26 15:21:41 compute2 neutron-dhcp-agent[31181]: ERROR
neutron.agent.dhcp.agent
This traceback is due to the fact that the non-local subnet in question
has no interface in the DHCP agent namespace, so it is not found when:
subnet_dhcp_ip = subnet_to_interface_ip[subnet.id]
is executed
** Affec
@Sam,
It is in fact discoverable through the API since that is what the
"router:external=True" is for. We will update our documentation to be
clearer on this point
** Tags removed: rfe rfe-triaged
** Changed in: neutron
Status: Confirmed => Opinion
--
You received this bug notification
The OVS agent in the compute where you are trying to bind the port
reports its state here:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L316
with a state built here
https://github.com/openstack/neutron/blob/master/neutron/plugin
I just created a devstack with Postgress to verify this report. I used
master branch instead of Queens. But these branches are not that far
apart that if I can accomplish such a basic operation as creating a
network in master I won't be able to do the same in Queens. As you can
see here, I can crea
xample) in 'dstport':
$ netstat -vaun
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp0 0 0.0.0.0:47890.0.0.0:*
** Affects: neutron
Importance: Medium
Assignee: Migu
calling the new method by calling it with predefined
values. This is breaking at least some of the VPNaaS unit tests. Other
sub-projects might be affected as well
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: In Progress
** Changed in: neutron
** Affects: neutron
Importance: Low
Assignee: Miguel Lavalle (minsel)
Status: New
** Changed in: neutron
Importance: Undecided => Low
** Changed in: neutron
Assignee: (unassigned) => Miguel Lavalle (minsel)
--
You received this bug notification because you are a me
Public bug reported:
Today I found the same failure in two unrelated patches:
http://logs.openstack.org/61/567461/1/check/openstack-tox-py27/1bbd80a
/job-output.txt.gz#_2018-05-10_03_52_48_299412
http://logs.openstack.org/73/566673/2/gate/openstack-tox-cover/a8914e0
/job-output.txt.gz#_2018-05-1
** Changed in: neutron
Status: Expired => Triaged
** Tags removed: rfe
** Tags added: rfe-triaged
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1460177
Title:
[RFE] Support meta
Based on the submitter's description and code, we already have this
extension:
1) This is the spec approved and implemented back in Kilo:
https://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-
trunks.html
2) This is the neutron-lib definition: https://github.com/openstack
/neutr
** 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/1711463
Title:
TestNetworkBasicOps.test_network_basic_ops failed with "Timed out
Please look at
https://github.com/openstack/neutron/blob/master/neutron/tests/unit/plugins/ml2/test_port_binding.py#L102.
This test case runs fine using 'host' default value. Yours is a corner
case in which not passing host + the fact that the port is owned by
compute produces and undesired result.
Hi loonatic,
What you refer as "UNEXPECTED" three times above is actually the
expected behavior, per the subnets data model:
https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L201-L206.
Once you give other projects access to the network through RBAC
policies, its subnets are
On second thought, I think we should add a note to the documentation
stating that subnets inherit their networks RBAC policies
** Summary changed:
- Subnets accessible when project_id != my project id with multiple subnets in
single RBAC access_as_shared network
+ Networking guide doesn't clarif
Hi,
As already pointed out by Liu Yulong, Newton release does not support
this feature. Marking bug invalid. Please don't change it again unless
there is an explanation and further details added to this bug justifying
that action
** Changed in: neutron
Status: New => Invalid
--
You recei
460
wrongly tries to call is_distributed_router as though it is a method in
the L3 plugin. The real intent was to call it from module
neutron/db/l3_dvr_db.py, since it is defined there outside any classes
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
We haven't heard back from submitter for several months. I will marks
this rfe as invalid. If there is still desire to pursue it, please mark
it again as new and we will re-take the conversation
** Changed in: neutron
Status: Confirmed => Invalid
** Tags removed: rfe rfe-confirmed
--
You
** Changed in: neutron
Status: New => Won't Fix
** Tags removed: rfe
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1797140
Title:
[RFE] create port by providing parameters subne
Thanks for the update!
** Tags removed: rfe-confirmed
** Tags added: rfe-postponed
** 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.
https://bugs.launchpad.net
Thanks for the update and the submission
** Tags removed: rfe
** Tags added: rfe-postponed
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net
Thanks for the update and submission
** Tags removed: rfe
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1806316
Title:
[RFE] Add
I left comprehensive comments at:
1)
https://review.openstack.org/#/c/574058/15/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py@1594
2)
https://review.openstack.org/#/c/574058/15/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py@1595
3)
https://review.opensta
Yes, I don't think we need this RFE
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1715380
Title:
[RFE] Need Qos function based on
This RFE was reviewed in the latest drivers meeting. Team consensus was
that this functionality doesn't belong in Neutron:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-10-27-14.00.log.html#l-94
** Changed in: neutron
Status: Triaged => Won't Fix
--
You
** Changed in: neutron
Status: Expired => Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1518581
Title:
[RFE] sriov vxlan network support
Status in neutron:
Confirmed
On November 30th we decided to continue support of neutron python client
so we can support API resource attribute extension
** Changed in: neutron
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
No, there is no way to see the address assigned to the DHCP port from
the subnet creation response. That is because the subnet creation
operation is independent from the DHCP port creation operation
** Changed in: neutron
Status: New => Opinion
--
You received this bug notification becaus
** Changed in: neutron
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1649517
Title:
qos policy attached to network, qos_policy_id is reflecting on ne
** Changed in: neutron
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1705467
Title:
[RFE] project ID is not verified when creating neutron resources
Public bug reported:
Notifications for l3 flavor for resource(ROUTER_CONTROLLER) and
events(PRECOMMIT_ADD/DEL_ASSOCIATION) are needed so that l3 flavor
drivers can subscribe to them
** Affects: neutron
Importance: Medium
Assignee: Isaku Yamahata (yamahata)
Status: Confirmed
**
Public bug reported:
This bug is created to track the merging of
https://review.openstack.org/#/c/534423/ during Queens RC1
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: In Progress
--
You received this bug notification because you are a
This bug was addressed in this commit:
https://github.com/openstack/neutron/commit/cb79d09e249a47d362706b2f4d64bd58c97c344f
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscr
Doc was released: http://docs.openstack.org/newton/networking-guide
/config-bgp-dynamic-routing.html
** 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://
Fix released: https://review.openstack.org/#/c/388228/
** Changed in: 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/1593846
Title:
[Doc] Fix
Not seen over the past 4 weeks by triggering tests with this patchset:
https://review.openstack.org/#/c/374106
** 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.
h
** Changed in: neutron
Status: New => Invalid
** Changed in: neutron
Status: Invalid => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1649909
Title:
Domain-def
Since this is a questions rather than a bug report, I am flagging it as
invalid
** Changed in: neutron
Status: Incomplete => 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/1
This change would be like going back to the situation
(https://review.openstack.org/#/c/343799/25/neutron_lib/api/validators.py)
before [1], where the valid values were displayed in the message. Citing
feedback from the patchset: "Based on the work done in [1], IIRC we
intentionally display the sta
Letting the user to not specify the segmentation id is perfectly valid.
Here's an example: http://paste.openstack.org/show/592402/. Please see
additional comment in https://review.openstack.org/#/c/410107
** Changed in: neutron
Status: In Progress => Invalid
--
You received this bug notif
Public bug reported:
When creating an aggregate using the Nova API, it doesn't return the new
aggregate's uuid:
DEBUG (connectionpool:400) http://192.168.33.12:8774 "POST /v2.1/os-aggregates
HTTP/1.1" 200 179
DEBUG (session:371) RESP: [200] Content-Length: 179 Content-Type:
application/json Ope
Public bug reported:
We are seeing a spike of failures in job gate-tempest-dsvm-neutron-
linuxbridge-ubuntu-xenial, test
tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic.
As of this writing, there are 48 instances of this failure in Kibana:
http://logstash.openstack.o
** Also affects: neutron
Importance: Undecided
Status: New
** Changed in: neutron
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1696006
Tit
*** This bug is a duplicate of bug 1696125 ***
https://bugs.launchpad.net/bugs/1696125
** 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/1696006
Title:
Li
n the tearDown method
of the tempest test is executed, the following traceback can be seen in
the q-svc screen: http://paste.openstack.org/raw/612268/
** Affects: neutron
Importance: Medium
Assignee: Miguel Lavalle (minsel)
Status: New
** Changed in: neutron
Importance: Unde
under Python 3.5 generates the following exception in the
Neutron server: http://paste.openstack.org/show/612964/
** Affects: neutron
Importance: High
Assignee: Miguel Lavalle (minsel)
Status: New
** Changed in: neutron
Assignee: (unassigned) => Miguel Lavalle (minsel)
** Ch
Please see comment left in patchset
(https://review.openstack.org/481967):
"This is not a bug. Ports can be created with IP addresses outside of
the allocation pools. The allocation pools are only there to determine
where automatic addresses come from."
** Changed in: neutron
Status: In Pr
This bug was discussed today during the L3 subteam meeting and the
agreement was that is is invalid. Please see discussion log here:
http://eavesdrop.openstack.org/meetings/neutron_l3/2017/neutron_l3.2017-08-03-15.00.log.html#l-90
** Changed in: neutron
Status: In Progress => Invalid
--
Y
This is not a bug, this is the expected behavior of the floating ip API
in Neutron. Please look at this Tempest test case failure that was
triggered by the proposed fix
(https://review.openstack.org/#/c/425563/):
http://logs.openstack.org/63/425563/1/check/gate-tempest-dsvm-neutron-
linuxbridge-ub
This is not a bug either in Nova. Please take a look at this Tempest
API test:
https://github.com/openstack/tempest/blob/master/tempest/api/compute/floating_ips/test_floating_ips_actions.py#L109
and its failure as a consequence of the proposed Neutron fix:
https://github.com/openstack/tempest/b
So in both cases, (Volodymyr's) and Jens, since there are no external
DNS services involved, we are talking about the Networking service
internal DNS resolution, described here:
http://docs.openstack.org/newton/networking-guide/config-dns-int.html
#the-networking-service-internal-dns-resolution. Pl
ron
Importance: Undecided
Assignee: Miguel Lavalle (minsel)
Status: New
** Changed in: neutron
Assignee: (unassigned) => Miguel Lavalle (minsel)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
We have found this bug before:
https://bugs.launchpad.net/neutron/+bug/1579977. We fixed in the Newton
cycle here: https://review.openstack.org/#/c/313291/. Since the reported
indicates that they are upgrading to Newton, they will receive the fix.
I will marked this bug as "fix released".
** Chang
I have continued watching this bug over the past 14 days. The search:
http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22AssertionError:%20False%20is%20not%20true%20:%20Timed%20out%20waiting%20for%202003::1%20to%20become%20reachable%20from%5C%22%20AND%20tags:%5C%22con
@Drew,
Thanks. Since this is not causing continuous operational issues, I am
going to mark it invalid. If you feel we should pursue further, please
feel free to change it back
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of
/609502/
** Affects: neutron
Importance: Undecided
Assignee: Miguel Lavalle (minsel)
Status: New
** Changed in: neutron
Assignee: (unassigned) => Miguel Lavalle (minsel)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which i
1 - 100 of 117 matches
Mail list logo
