Public bug reported:
It appears the neutron functional job started failing with errors
related to:
ovsdbapp.backend.ovs_idl.idlutils.RowNotFound
For example [1][2].
Based on logstash [3] it looks like this issue may have cropped up
around March 5th.
[1]
Public bug reported:
This isn't a request for a new feature per say, but rather a placeholder
for the neutron drivers team to take a look at [1].
Specifically I'm hoping for drivers team agreement that the
modules/functionality being rehomed in [1] makes sense; no actual (deep) code
review of
Public bug reported:
It appears that as of recent we've been getting some OVS timeouts in various
functional jobs [1].
One example is [2] that has a exception message with:
ovsdbapp.exceptions.TimeoutException: Commands
[, , ] exceeded timeout 10 seconds
Based on the logstash query [1] it
Best I can tell the docs already all do use -u and -p option [1].
If there's something else that's needed please reopen/clarify.
[1] http://codesearch.openstack.org/?q=mysql=nope=doc=neutron
** Changed in: neutron
Assignee: (unassigned) => Boden R (boden)
** Changed in: neut
Public bug reported:
Functional gate test(s) have been failing intermittently with the
following exception:
RuntimeError: Stale metadata proxy didn't get killed
The logstash query in [1] shows the frequency of the error.
The log in [2] shows a sample neutron-functional failure with the error.
Public bug reported:
As of December 20 2018 the python unit test jobs for the tricircle
project have been failing [1]. After going through the tricircle/neutron
commits since that date, it seems some changes went into neutron that
caused the breakage.
If I run tricircle python 3.5 unit test with
Public bug reported:
We found this bug using the vmware-nsx plugin, but should be applicable
to all plugins support L3.
Created devstack_master + vmware-nsx
Created router-interface and assigned fip's to router interface which is
allowed.
I dont find any usecase to assign ip to router port
Public bug reported:
Today it appears the neutron-vpnaas doesn't support proper env setup for
running tox targets locally. For more details see [1].
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131801.html
** Affects: neutron
Importance: Undecided
Status: New
Public bug reported:
Today it appears the neutron-vpnaas doesn't support proper env setup for
running tox targets locally. For more details see [1].
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131801.html
** Affects: neutron
Importance: Undecided
Assignee: Boden
Public bug reported:
It appears the neutron-rally-neutron job is failing intermittently with:
2018-06-25 21:27:31.654 4361 ERROR rally.task.engine [-] Invalid Task:
PluginNotFound: There is no plugin
`NeutronTrunks.create_and_list_trunk_subports` in in any platform.
For example [1]
** Changed in: neutron
Status: Fix Released => 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/1750353
Title:
_get_changed_synthetic_fields() does not guarantee
Public bug reported:
It appears the landing of [1] into stable/queens has broken some
consumers, at least vmware-nsx.
When running with [1] in neutron/queens, we now get:
security_group_rule is already registered
Loaded quota_driver: .
Loaded quota_driver: .
create failed: No details.:
Reopening. It appears this work was never completed; the api def never
made it into neutron-lib and was consumed, so I'll do that.
** Changed in: neutron
Status: Fix Released => In Progress
** Changed in: neutron
Assignee: Ahmed Zaid (ahmedzaid10) => Boden R (boden)
--
You re
Public bug reported:
As discussed in [1], the
POST /v2.0/agents/{agent_id}/l3-routers
does not return a response body. This seems inconsistent with our other
APIs as POSTs typically return the created resource. This is even true
with other APIs that 'add' something to a resource.
It seems we
Public bug reported:
As discussed in [1], the
POST /v2.0/agents/{agent_id}/l3-routers
does not return a response body. This seems inconsistent with our other
APIs as POSTs typically return the created resource. This is even true
with other APIs that 'add' something to a resource.
It seems we
Public bug reported:
The commit [1] to use neutron-lib's segment API def surfaced an issue
[2] whereupon the standardattrdescription's update of the 'description'
attribute clobbers existing defs.
For example the segment API def has a 'description' [3] allowing it to be set
to 'None'.
However
Public bug reported:
As part of my dev process, I run the py27 target frequently on my local
workspace dev env to verify changes/fixes.
Over the past few months I've begun to get intermittent failures in the
test_l3_agent_scheduler module. I've collected the failures from the past week
and
Public bug reported:
Today the neutron-lib/api-ref/source/v2/parameters.yaml has a bunch of
unused params.
For example:
name_39
name_41
etc..
Any params in parameters.yaml that's not used in any .inc, is not needed
and should be removed from parameters.yaml (it's dead code per say).
**
Public bug reported:
As of recent there appears to be an intermittent failure in
neutron.tests.functional.agent.test_dhcp_agent.DHCPAgentOVSTestCase.test_notify_port_ready_after_enable_dhcp;
it fails with:
RuntimeError: 'dhcp_ready_on_ports' not be called
For example [1].
As of right now I
Public bug reported:
The subnetallocation extension appears to be a shim extension that
doesn't add any attrs/resources. However we should still document this
extension in a subsection to describe what it does.
** Affects: neutron
Importance: Undecided
Status: Confirmed
** Tags:
Public bug reported:
The subnet_service_types extension is not documented in our api-ref:
- The subnet api-ref needs a subsection atop it describing the extn.
- Any attrs added by the extn need to be doc'd as params on the subnet api-ref.
** Affects: neutron
Importance: Undecided
Public bug reported:
While the params added by router_availability_zone extension do appear
to be documented in the routers api-ref, the extension needs a
subsection atop the routers api-ref describing the extn itself. See
other api-refs for examples.
** Affects: neutron
Importance:
Public bug reported:
The routerservicetype extension is not doc'd in our api-ref:
- The routerservicetype extension needs a subsection atop the router api-ref
describing the extn itself.
- Any params added by the extn need to be doc'd.
** Affects: neutron
Importance: Undecided
Public bug reported:
The qos_default extension is not documented in our api-ref:
- The qos policy api-ref needs a subsection atop it describing the extn.
- Any params added by the extn need to be doc'd therein as well.
** Affects: neutron
Importance: Undecided
Status: Confirmed
Public bug reported:
While the qos_bw_limit_direction extension params are documented in the
qos api-ref, the extension needs a subsection atop the bw limit rule
section describing the extension itself. See other api-refs for
examples.
** Affects: neutron
Importance: Undecided
Public bug reported:
While the qos_rule_type_details extension's params appear to be doc'd in
the qos rule types api-ref, the rule types api-ref needs a subsection
atop it describing the extension itself. See other api-refs for
examples.
** Affects: neutron
Importance: Undecided
Public bug reported:
The l3_flavors extension is not doc'd in our api-ref:
- The routers api-ref needs a subsection atop it doc'ing the extn.
- Any params added by the extn also needed to be doc'd therein.
** Affects: neutron
Importance: Undecided
Status: Confirmed
** Tags:
Public bug reported:
The l3_ext_ha_mode extension is not documented in our api-ref:
- The routers api-ref needs a subsection atop it describing the extension.
- Any params added by the extension also need to be doc'd therein.
** Affects: neutron
Importance: Undecided
Status:
Public bug reported:
The l3_ext_gw_mode extension is not documented in our api-ref:
- The routers api-ref needs a subsection atop it describing the extension.
- The routers api-ref needs to doc any params added by the extension.
** Affects: neutron
Importance: Undecided
Status:
Public bug reported:
The network_availability_zone is not documented in our api-ref:
- The networks api-ref needs a subsection atop it doc'ing the extension.
- Any params added by the extension need to included in the network api-ref.
** Affects: neutron
Importance: Undecided
Public bug reported:
The l3agentscheduler extension is not documented in our api-ref:
- The agents api-ref needs a subsection atop it describing the extension. Any
params added by the extension also need to be doc'd therein.
- The routers api-ref needs a subsection atop it describing the
Public bug reported:
The extra_dhcp_opt is not properly doc'd in our api-ref. While the ports
api-ref does doc the extra_dhcp_opts request/response param, the
extra_dhcp_opt extension needs to be described in a subnsection atop to
the ports api-ref like others do.
** Affects: neutron
Public bug reported:
The external_net extension is not completely documented yet. While it
appears the networks api-ref does doc the router:external params, the
external_net extension needs to be described in a subsection atop the
networks api-ref (see others for examples).
** Affects: neutron
Public bug reported:
The ip_allocation extension is not documented in our api-ref:
- The port api-ref needs a subsection describing the extn.
- The params added by the extn need to be documented in the port api-ref.
** Affects: neutron
Importance: Undecided
Status: Confirmed
**
Public bug reported:
The l2_adjacency extension is not documented in our api-ref:
- The networks api-ref needs a subsection atop it describing the extension.
- Any params added by the extension need to be included in the network api-ref.
** Affects: neutron
Importance: Undecided
Public bug reported:
The dhcpagentscheduler extension is not documented in our api-ref:
- The extension needs to be documented on the agents resource as well as the
attr(s) it adds.
- The extension needs to be documented on the networks resource as well as the
attr(s) it adds.
** Affects:
Public bug reported:
The dvr extension is not documented in our API-ref:
- The routers api-ref needs to have a subsection for the extension as well as
included the param(s) the extension adds.
** Affects: neutron
Importance: Undecided
Status: Confirmed
** Tags: api-ref
**
Reviving this bug.
The address scopes extension doesn't appear to be documented in the API ref.
- The address scopes resource itself isn't in the api-ref.
- The networks and subnetpools resources need to note the extension and include
in their params.
** Changed in: neutron
Status:
Public bug reported:
The auto-allocated-topology extension is not documented in our current api-ref:
- The auto_allocated_topologies resource is not documented.
- The extension is not explained for the network resource nor is the is_default
option for networks.
** Affects: neutron
Public bug reported:
The availability_zone extension is not documented in the API ref:
- The availability_zones resource is not documented.
- The az extension is not documented on the agent api-ref nor is the
availability_zone attribute added to agents.
** Affects: neutron
Importance:
Public bug reported:
I've started noticing the following error in our legacy-tempest-dsvm-
neutron-full jobs:
--
volume 3c34fd82-8d3d-4d87-8290-f3c119587b94 failed to reach ['available']
status (current detaching) within the required time (196 s).
--
Based on [2] this does not appear to be
Best I can tell from comment #6 and the current neutron/docs/source
tree, this is no longer valid and doc'd in neutron.
If it is, please reopen and reference the openstack docs site URL that has the
doc needing updating.
thanks
** Changed in: neutron
Status: New => Invalid
--
You
Best I can tell, from a neutron perspective this is now being driven under the
referenced RFE [1].
Under that assumption I'm getting this one off the bug queue.
If [1] doesn't cover this defect, please feel free to open and provide some
details on how this differs from [1].
Thanks
[1]
Moving this back to fix released. It's not clear why it was moved back to "New"
on 10-03. If there's still an issue, please update with additional information
as to why its re-opened and the original fix isn't sufficient.
Thanks
** Changed in: neutron
Status: New => Fix Released
--
You
Not sure there's anything to doc here.
The agent config guide [1] refs over to the linuxbridge agent config opts [2]
that documents the multicast_ranges option.
[1] https://docs.openstack.org/neutron/latest/admin/config-ml2.html#l2-agent
[2]
** 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/1719516
Title:
Networking Option 1: Provider networks in neutron
Status in
Public bug reported:
Patch [1] added the quota detail API.
However to the best of my knowledge this support didn't make it into the CLI
(neutron neutronclient or OSC).
This bug is to track the integration of quota details into the CLI.
[1] https://review.openstack.org/#/c/383673/
**
Based on Armando's comment #2 moving this to invalid.
Given comment#2, if folks still feel doc tweaking is necessary, please reopen.
** Changed in: neutron
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
After looking through our current docs, I don't see any place we
specifically talk in depth about l3 agent HA. Therefore if we want to
spend the time with a new agent HA guide (or something) I think that
should come in as a stand alone request.
The config option added as part of this change is
Best I can tell this one is already accounted for and there's nothing
left to do.
The API ref already includes 'direction' for applicable API operations [1].
In addition the qos config guide also includes direction [2].
If there's other doc hits that are unaccounted for, please reopen.
[1]
Public bug reported:
Today we have no validation of links (internal, relative or static) as
part of our doc build. As a result we can end up with dead links over
time that are typically noticed by our users... Less than optimal.
As part of the comments in [1], it was suggested we try to validate
This bug has been idle for a long time. Moving to invalid.
If comment #1 doesn't address this issue, please reopen with additional details.
Thanks
** Changed in: neutron
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering
Based on what I see the change introduced the vif type of 'hostdev_physical'.
This is already documented as a vif type for ports in our API ref, for example
[1].
The response parameters show:
---
binding:vif_type
The type of which mechanism is used for the port. An API consumer like nova can
Public bug reported:
In ocata we had config reference for l2pop config opts [1].
However these seem to be missing in pike [2] and are referenced in the
config-ml2.rst doc.
[1]
After scanning our docs, I'm not seeing any updates that need to be made
here.
We touch on linuxbridge agent config in [1], but without much depth and
just refer to the config reference. Given the config options added as
part of this feature are well documented, IMO the config reference is
release.
[1] http://codesearch.openstack.org/?q=ocata=nope==neutron
** Affects: neutron
Importance: Medium
Assignee: Boden R (boden)
Status: New
** Tags: doc
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed
This doc work was completed with
Ia5630ceb97d833b85d88cef323bcd2d6c9780c81 under bug
https://bugs.launchpad.net/neutron/+bug/1711992
** Changed in: neutron
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which
Based on the latest contents of the config qos guide [1], this has
already been fixed.
[1] https://github.com/openstack/neutron/blob/master/doc/source/admin
/config-qos.rst
** Changed in: neutron
Status: Confirmed => Fix Released
--
You received this bug notification because you are a
Today I don't see gateway_external_network_id documented other than a
blank use of it in sample CLI output [1]. That said I don't see any
reason to leave this open as I'm not sure what needs to be documented.
When the deprecated option is removed, that should be marked with a doc
impact tag and
** 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/1683102
Title:
Port data plane status extension implementation
This implementation was reverted in
I88a216951d8996ac8bc90078b4239f0d25392e58 and therefore no doc changes
are necessary here.
** Changed in: neutron
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
://docs.openstack.org/neutron/latest/contributor/internals/index.html
** Affects: neutron
Importance: Undecided
Assignee: Boden R (boden)
Status: New
** Tags: doc
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https
We still need to document this extension and its updatable nature in the
api-ref
** Changed in: neutron
Status: New => Fix Released
** Changed in: neutron
Status: Fix Released => Confirmed
** Changed in: neutron
Importance: Undecided => Medium
** Tags added: api-ref lib
**
** 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/1705755
Title:
[RFE] Plugin support for API resource attribute
Unable to reproduce. Tried running py27 with fwaas and a few others, but
didn't see the WARNING called out in this bug.
If I'm missing some details to reproduce, please provide them and
reopen.
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because
Public bug reported:
This is a feature request for API extensions.
Based on the discussion in [1], it seems there maybe some use in
introducing a 'api_status' attribute on all API extensions. This
attribute would be defined in the API's definition
(neutron_lib.api.defintions.) and would be
Public bug reported:
A number of gate tests appear to be intermittently failing with::
testtools.matchers._impl.MismatchError: u'host0' != u'standby'
For example [1][2].
50 hits found in the last 7 days [3].
[1]
** Changed in: neutron
Status: Fix Committed => 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/1642426
Title:
attributes.PLURALS is never used
Status in neutron:
Public bug reported:
The gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial gate failed in a
recent neutron change [1]. Digging into the logs [2] it appears to be DB
related::
--
2017-03-01 15:47:17.800 1412 ERROR oslo_messaging.rpc.server
ObjectDeletedError: Instance '' has been
deleted, or
Public bug reported:
Today the neutron auto-allocated-topology (aka "get me a network")
plugin/service allocates a router using the default enable_snat value for
routers (True); so the resulting topology always has SNAT enabled. Some
deployments would benefit from the ability to provision
Nothing to do in the neutron project; closing that side of the bug.
** 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/1656355
Moving to invalid/unassigned and will timeout in 60 days as-is.
If additional work is needed and in scope please reassign.
** Changed in: neutron
Status: Confirmed => Invalid
** Changed in: neutron
Importance: Medium => Undecided
** Changed in: neutron
Assignee: Anthony Chow
OpenStack manual's config reference already includes these [1].
The neutron patch contained a release note.
Best I can tell no neutron or other work is needed here.
[1]
http://docs.openstack.org/newton/config-reference/networking/networking_options_reference.html
** Changed in: neutron
Marking this as incomplete with the following reasoning:
- The openstack-manuals team marked it as invalid and thus don't plan to update
the docs/manuals.
- Unless we have someone willing to create/drive the change into the
openstack-manuals, I don't see how this will get done.
If we have
The original patch included a release note.
The networking guide is already updated to include documentation on
access_as_external [1].
That said I don't see any work left here. Closing out as invalid.
[1]
Based on [1] this has already been fixed in the api-ref.
Nothing else to do from a neutron perspective, so closing out.
[1]
https://developer.openstack.org/api-ref/networking/v2/?expanded=show-network-details-provider-network-detail,show-network-details-detail,show-port-details-detail
**
The manual's config reference is already updated [1].
The original patch already included a release note [2].
Marking as invalid as I don't see any work left here.
[1]
http://docs.openstack.org/newton/config-reference/networking/networking_options_reference.html#api
[2]
sha256 has already been added to the API ref [1].
Marking as invalid.
[1] https://developer.openstack.org/api-ref/networking/v2/?expanded
=show-ipsec-policy-detail
** Changed in: neutron
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of
>From a neutron perspective I'm not seeing anything needed.
However from an openstack-manuals POV it seems like we should note the
IPv4 requirement for floating IPs (e.g. can't create floating IPs on net
with no IPv4 subnets, etc. see commit message for more details). When
searching the openstack
As per comment #2, a docs change already landed. I also confirmed in the
newton L3 agent config docs; the opt is not there.
Nothing left to do from a neutron POV so closing out.
** Changed in: neutron
Status: Confirmed => Invalid
--
You received this bug notification because you are a
quota_items was removed from the manuals with [1] and I couldn't find
any other refs to it in the newton docs (to confirm).
>From a neutron POV I don't see anything left to do.
[1] https://review.openstack.org/#/c/344325/
** Changed in: neutron
Status: Confirmed => Invalid
--
You
Manuals have already been updated (see comment #2).
>From a neutron POV, the initial patch [1] already contained a release
note. Marking as invalid from a neutron perspective since nothing else
appears to be needed.
[1] https://review.openstack.org/#/c/336805/
** Changed in: neutron
While a networking guide change did go out for this (see comment #3),
after looking at what we have in this regard I still feel the docs are
confusing. As a result I generated another openstack-manuals defect [1].
>From a neutron perspective I'm not seeing other docs needed; if a devref
was
Added openstack-manuals as affected project to all them to triage the
ability to update the networking guide with "flavors" support. The spec
linked in the description of this defect has a nice overview of the
functionality.
Leaving the neutron bug as-is; we would like to also have a devref for
** Also affects: openstack-manuals
Importance: Undecided
Status: New
** Changed in: openstack-manuals
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
Marking as invalid; see review comments - we don't fix typos in old
specs.
** 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.
As noted in the commit message; a new config option has been introduced.
Moving this to the manual team so they can consume.
Note this is for master and there are separate bugs for other branches.
** Changed in: neutron
Status: Confirmed => New
** Changed in: neutron
Importance: Low
As noted in commit message; this change adds a new config option.
However please note this defect is for Mitaka which is about 3 months from EOL
and therefore may not make sense to add at this point in time.
Moving to manuals team so they can decide if they want to consume this
mitaka config
This change is for liberty which is already EOL; therefore I'm marking this as
won't fix.
Note: there are separate defects for this in other releases.
** Changed in: neutron
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering
As noted in the commit message of the fix, this one requires updates to
the install/upgrade/deploy guide. Also note this is for newton; a
separate bug is out there for master (ocata).
Moving to openstack-manuals to get the proper docs updated.
** Project changed: neutron => openstack-manuals
--
As noted in the commit message, this one impacts the
install/upgrade/deploy guide; so I'm moving it to openstack-manuals for
the appropriate updates.
Note this is for master; there's a separate bug for the newton changes.
** Project changed: neutron => openstack-manuals
--
You received this
As noted in the commit message, this introduces a new config option that
needs to be doc'd in the manuals; moving to openstack-manuals.
Note this is for newton; there's a separate bug for master.
** Changed in: neutron
Status: Triaged => New
** Changed in: neutron
Importance: Low =>
Based on what I'm seeing, we should update [1] to include the ability to
keystone v3 in the [designate] config. See change for more details.
Moving this to openstack-manuals as I don't see any docs in the neutron
repo that need updating as a part of this.
[1]
I agree with comment #1 and I didn't find any direct refs to the agent
and DSCP other than a generic reference about DSCP in [1].
However to be on the safe side I'm moving to openstack-manuals in case
there's a ref or work in progress I'm missing; otherwise it can safely
be closed out as invalid
Best I can tell, there's nothing needed herein from a neutron doc
(devref or apiref) POV. The respective change that generated this bug
already contained devref updates [1].
As per [2] the 'notification_drivers' config option is deprecated for
QoS; therefore we need to update the associated
Best I can tell, nothing needs updating in neutron (devref or apiref).
The manuals were already updated as per the related project bug.
Thus marking as invalid for neutron as per [1] since there's nothing we
need to do in the neutron repo.
[1]
** 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/1642280
Title:
Adopt ExtensionDescriptor from neutron-lib
Status in neutron:
As discussed in [1] placing strict validation around the attributes of
this request is likely dangerous at this point in time as extensions
maybe adding additional attrs that would then be blocked. If we can get
some stricter versioning in place we can revisit this one. Please see
discussion in
Going to close this one out; it's more or less noise.
The change in [1] addresses the issue, but continue to discuss the best way to
deal with hacking checks in lib. For example [2]. That said, I don't see a
reason to leave this bug open; it's unnecessary.
[1]
This doc impact bug affects the designate DNS driver configuration
reference.
** Project changed: neutron => openstack-manuals
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1655785
1 - 100 of 141 matches
Mail list logo
