As noted in comment #5 a patch has been merged which removes the
comments in test_virt_drivers indicating a hypervisor matrix should be
generated from the unit test compute driver subclass execution. As
discussed (above) in this bug; if hypervisor support matrix dynamic
generation is needed, we
Public bug reported:
With the current impl of the nova-docker virt driver and the docker-
registry (https://github.com/dotcloud/docker-registry) snapshotting a
docker container does not return the image ID of the final image created
from the snapshot operation.
For example consumer code should
Public bug reported:
During the instance boot (spawn/run) process, neutron ports are
allocated for the instance if necessary. If the instance fails to spawn
(say as a result of a compute host failure), the default behavior is to
reschedule the instance and leave it's networking resources in-tact
Public bug reported:
As part of [1] and [2], support was added to load service plugins at
start-up.
Specifically [1] added the 'auto-allocated-topology' (aka 'get me a
network') as a default service plugin for neutron.
However, this auto-allocated-topology when loaded as a default service
Public bug reported:
In [1] support was added to auto-start service plugins in neutron core.
As part of this change, the default auto-started plugins is defined in
the plugin's constants file [2]. While this surely works, it would be
beneficial to provide a neutron.conf property to specify the
"tapcf35e3b7-06"
ovs_version: "2.0.2"
As shown in the output, a port device is left over, even after the
network + subnets are deleted.
** Affects: neutron
Importance: Undecided
Assignee: Boden R (boden)
Status: New
** Changed in: neu
After munking with this a bit, 'service_plugins' in neutron.conf already
fulfills this bug description. See [1].
That said it makes sense to leave [2] as-is -- intended for core plugins
users should be able to setup via the conf.
If someone disagrees, please reopen.
[1]
Public bug reported:
[Overview + Motivation]
Cloud software is complex. Resources abstracted at the Cloud layer must be
realized on backend system(s) (native Operating System or other potentially
distributed service(s)) and an association between the Cloud and backend
resource must be
I haven't been able to reproduce this lately using my single node devstack
w/ovs env.
Closing as invalid. If the issue (re)crops up, I'll reopen the dug accordingly.
** Changed in: neutron
Status: In Progress => Invalid
--
You received this bug notification because you are a member of
See comment #8 for summary.
** Project changed: neutron => devstack
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1542282
Title:
Q_PLUGIN_EXTRA_CONF_FILES documented with incorrect
I'm going to mark this as "Invalid" assuming comment #4 (existing
functionality) resolves the issue. If this does not address the root
issue please reopen with additional information as to the problem and
I'll be happy to dig into it.
** Changed in: neutron
Status: Triaged => Invalid
--
#/c/340580/
** Affects: neutron
Importance: Undecided
Assignee: Boden R (boden)
Status: New
** Tags: lib
** Changed in: neutron
Assignee: (unassigned) => Boden R (boden)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which
er/532d25b/console.html#_2016-08-03_06_12_19_093990
** Affects: neutron
Importance: Undecided
Assignee: Boden R (boden)
Status: New
** Tags: lib
** Changed in: neutron
Assignee: (unassigned) => Boden R (boden)
--
You received this bug notification because you are a member
is to track the clean-up of this formatting.
[1] https://review.openstack.org/#/c/339643/1/api-ref/source/v2/networks.inc
** Affects: neutron
Importance: Undecided
Assignee: Boden R (boden)
Status: New
** Tags: lib
** Changed in: neutron
Assignee: (unassigned) => Bode
Public bug reported:
I'm seeing intermittent failures via ml2.plugin
_setup_dhcp_agent_provisioning_component().
ATM, logstash is only showing 3 hits with my query [1]; not all the same
test (2 hits on 8/01/2016 and 1 hit on 7/25/2016). There's also a hit
from today [3] that's not showing up in
neutron_lib.constants import Sentinel
singleton = Sentinel()
print(copy.deepcopy(singleton) == copy.copy(singleton))
---
Outputs 'False'.
[1]
https://github.com/openstack/neutron-lib/blob/master/neutron_lib/constants.py#L255
** Affects: neutron
Importance: Undecided
Assignee: Boden R
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
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 =>
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 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
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
** 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.
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
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
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]
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
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
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
**
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
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
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]
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
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, 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]
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
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]
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]
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
** 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:
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
://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/validators.py#L215
** Affects: neutron
Importance: Undecided
Assignee: Boden R (boden)
Status: New
** Tags: lib
** Changed in: neutron
Assignee: (unassigned) => Boden R (boden)
** Tags added: lib
--
Public bug reported:
It appears we have an intermittent error related to auto-allocating
networks. The failure stack looks something like this:
2016-08-30 14:26:03.961058 | Captured traceback:
2016-08-30 14:26:03.961078 | ~~~
2016-08-30 14:26:03.961105 | Traceback (most
@Brian: I think you are right. I missed the q-svc errors.
I'll address via the offending patch.
** 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.
-
f8d50ee8f7928145d126ae36c0d16900L259
** Affects: neutron
Importance: Undecided
Assignee: Boden R (boden)
Status: In Progress
** Tags: lib
** Changed in: neutron
Assignee: (unassigned) => Boden R (boden)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, wh
-lib/blob/master/doc/source/review-guidelines.rst
** Affects: neutron
Importance: Undecided
Assignee: Boden R (boden)
Status: New
** Tags: lib
** Changed in: neutron
Assignee: (unassigned) => Boden R (boden)
--
You received this bug notification because you are a mem
Public bug reported:
neutron_lib.api.validator validate_ip_pools [1], defines the
valid_values kwarg, but does nothing with it.
We can leverage the work done in [2] to add some basic verification of
this kwarg.
[1]
Public bug reported:
Best I can tell, the neutron agent extension [1], is not documented in
the api-ref (see the output from any recent neutron-lib patch's gate-
neutron-lib-api-ref job).
It would be nice to have this API documented with the others in the api-ref
[2]. e.g.
GET /v2.0/agents
Marking as won't fix:
- We don't have a hard policy on docstrings, tho they are welcomed and
encouraged. That said we've been doing just fine enforcing via code reviews.
- We have a lot of other work right now so this item doesn't make sense at this
point in time.
** Changed in: neutron
Marking neutron bug as invalid as per [1]. The openstack-manuals as
added as an affected project. Manuals need updating as per DoctImpact
comment.
[1]
http://docs.openstack.org/developer/neutron/policies/bugs.html#bug-triage-process
** Also affects: openstack-manuals
Importance: Undecided
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
** 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/bugs/1636269
Title:
neutron-lib validate_ip_address doesn't use valid_values
** 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/bugs/1636279
Title:
neutron-lib validate_non_negative doesn't use valid_values
** Changed in: neutron
Status: Confirmed => 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/1636280
Title:
neutron-lib validate_subports doesn't use valid_values kwarg
** 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/bugs/1636278
Title:
neutron-lib validate_uuid doesn't use valid_values kwarg
** Changed in: neutron
Status: Confirmed => 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/1636272
Title:
neutron-lib validate_fixed_ips doesn't use valid_values kwarg
** 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/bugs/1636274
Title:
neutron-lib validate_nameservers doesn't use valid_values
** 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/bugs/1636268
Title:
neutron-lib validate_mac_address doesn't use valid_values
** 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/bugs/1615088
Title:
neutron-lib validate_boolean doesn't use valid_values kwarg
** 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/bugs/1636277
Title:
neutron-lib validate_subnetpool_id doesn't use valid_values
** Changed in: neutron
Status: Confirmed => 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/1636275
Title:
neutron-lib validate_hostroutes doesn't use valid_values kwarg
** 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/bugs/1636270
Title:
neutron-lib validate_ip_pools doesn't use valid_values kwarg
** 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/bugs/1636276
Title:
neutron-lib validate_subnet doesn't use valid_values kwarg
** Project changed: openstack-manuals => neutron
** Also affects: openstack-manuals
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/1655196
As long as the FIP given via --floating-ip-address is within the CIDR of
the external net it's valid. The allocation pool is for automatic
allocations.
Try your scenario above and pass a --floating-ip-address that's not in the
external net CIDR.
You should get something like this:
** Changed in: neutron
Importance: Undecided => Medium
** Changed in: neutron
Status: New => Triaged
** Project changed: neutron => openstack-manuals
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to 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/1654887
Title:
Upgrade to 3.6.0 causes AttributeError: 'SecurityGroup' object has no
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
** 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:
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
**
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
** 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
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]
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
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
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]
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
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]
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
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
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:
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/
**
://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
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
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]
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
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
** 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
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
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
** 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
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]
1 - 100 of 141 matches
Mail list logo
