[Yahoo-eng-team] [Bug 1829343] [NEW] requirements-check job fails
Public bug reported:
requirements-check job will always fail with current Nova doc
requirements:
2019-05-14 15:14:03.375075 | TASK [Run requirements check script]
2019-05-14 15:14:15.756135 | ubuntu-bionic | sys.version_info(major=3, minor=6,
micro=7, releaselevel='final', serial=0)
2019-05-14 15:14:15.756335 | ubuntu-bionic | selecting default requirements
directory for normal mode
2019-05-14 15:14:15.756388 | ubuntu-bionic | Branch: master
2019-05-14 15:14:15.756464 | ubuntu-bionic | Source:
src/opendev.org/openstack/nova
2019-05-14 15:14:15.756573 | ubuntu-bionic | Requirements:
/home/zuul/src/opendev.org/openstack/requirements
2019-05-14 15:14:15.756631 | ubuntu-bionic | git log -n 1 --format=%H
2019-05-14 15:14:15.756735 | ubuntu-bionic | Patch under test:
b'f029534938012a19e4eee2d0927f4ccb2747b8fe'
2019-05-14 15:14:15.756870 | ubuntu-bionic | git --git-dir
/home/zuul/src/opendev.org/openstack/requirements/.git rev-parse HEAD
2019-05-14 15:14:15.756988 | ubuntu-bionic | requirements git sha:
b'85f9aad798323c5f6dd8ce1a3dd5e009c2f944a1'
2019-05-14 15:14:15.757056 | ubuntu-bionic | virtualenv /tmp/tmp62m_7g3d/venv
2019-05-14 15:14:15.757192 | ubuntu-bionic | /tmp/tmp62m_7g3d/venv/bin/pip
install /home/zuul/src/opendev.org/openstack/requirements
2019-05-14 15:14:15.757289 | ubuntu-bionic | Checking
b'f029534938012a19e4eee2d0927f4ccb2747b8fe'
2019-05-14 15:14:15.757350 | ubuntu-bionic | Processing requirements.txt
2019-05-14 15:14:15.757417 | ubuntu-bionic | Processing test-requirements.txt
2019-05-14 15:14:15.757482 | ubuntu-bionic | Processing doc/requirements.txt
2019-05-14 15:14:15.757539 | ubuntu-bionic | Processing .[osprofiler]
2019-05-14 15:14:15.757603 | ubuntu-bionic | Validating requirements.txt
2019-05-14 15:14:15.757671 | ubuntu-bionic | Validating test-requirements.txt
2019-05-14 15:14:15.757736 | ubuntu-bionic | Validating doc/requirements.txt
2019-05-14 15:14:15.757999 | ubuntu-bionic | Requirement(package='sphinx',
location='', specifiers='!=1.6.6,!=1.6.7,>=1.6.2', markers='', comment='# BSD',
extras=frozenset()) 'markers': '' does not match "python_version=='2.7'"
2019-05-14 15:14:15.758262 | ubuntu-bionic | Requirement(package='sphinx',
location='', specifiers='!=1.6.6,!=1.6.7,>=1.6.2', markers='', comment='# BSD',
extras=frozenset()) 'markers': '' does not match "python_version>='3.4'"
2019-05-14 15:14:15.758537 | ubuntu-bionic | Could not find a global
requirements entry to match package sphinx. If the package is already included
in the global list, the name or platform markers there may not match the local
settings.
2019-05-14 15:14:15.758596 | ubuntu-bionic | Validating osprofiler
2019-05-14 15:14:15.758684 | ubuntu-bionic | Validating lower constraints of
requirements.txt
2019-05-14 15:14:15.758777 | ubuntu-bionic | Validating lower constraints of
test-requirements.txt
2019-05-14 15:14:15.758865 | ubuntu-bionic | Validating lower constraints of
osprofiler
2019-05-14 15:14:15.758938 | ubuntu-bionic | *** Incompatible requirement found!
2019-05-14 15:14:15.759063 | ubuntu-bionic | *** See
https://docs.openstack.org/requirements/latest/
2019-05-14 15:14:16.085404 | ubuntu-bionic | ERROR
2019-05-14 15:14:16.085856 | ubuntu-bionic | {
2019-05-14 15:14:16.085977 | ubuntu-bionic | "delta": "0:00:11.176407",
2019-05-14 15:14:16.086084 | ubuntu-bionic | "end": "2019-05-14
15:14:15.781517",
2019-05-14 15:14:16.086187 | ubuntu-bionic | "msg": "non-zero return code",
2019-05-14 15:14:16.086288 | ubuntu-bionic | "rc": 1,
2019-05-14 15:14:16.086391 | ubuntu-bionic | "start": "2019-05-14
15:14:04.605110"
2019-05-14 15:14:16.086490 | ubuntu-bionic | }
2019-05-14 15:14:16.170292 |
** Affects: nova
Importance: Undecided
Assignee: Gorka Eguileor (gorka)
Status: In Progress
** Changed in: nova
Assignee: (unassigned) => Gorka Eguileor (gorka)
--
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/1829343
Title:
requirements-check job fails
Status in OpenStack Compute (nova):
In Progress
Bug description:
requirements-check job will always fail with current Nova doc
requirements:
2019-05-14 15:14:03.375075 | TASK [Run requirements check script]
2019-05-14 15:14:15.756135 | ubuntu-bionic | sys.version_info(major=3,
minor=6, micro=7, releaselevel='final', serial=0)
2019-05-14 15:14:15.756335 | ubuntu-bionic | selecting default requirements
directory for normal mode
2019-05-14 15:14:15.756388 | ubuntu-bionic | Branch: master
2019-05-14 15:14:15.756464 | ubuntu-bionic | Source:
src/opendev.org/openstack/nova
2019-05-14 15:14:15.756573 | ubuntu-bionic | Requirements:
/home/zuul/src/opendev.org/openstack/requirements
2019-05-14 15:14:15.756631 | ubuntu-bionic | git log -n 1 --format=%H
2019-05-14 15:14:15.756735 | ubuntu-bionic | Patch under test:
b'f029534938012a19e4eee2d0927f4ccb2747b8fe'
2019-05-14
[Yahoo-eng-team] [Bug 1829349] [NEW] Resource Tracker failed to update usage in case numa topology conflict happen
Public bug reported:
Let me describe when this bug will happen first.
Assume there are 2 running VMs they are booted with flavor that contain
metadata 'hw:cpu_policy=dedicated'.
And assume some of these 2 VMs' vCPUs are pinned to the same physical CPU.
Let's say VM1 pinned to {"0": 50, "1": 22, "2": 49, "3": 21}
and VM2 pinned to {"0": 27, "1": 55, "2": 50, "3": 22}
Refer to patch
https://opendev.org/openstack/nova/commit/52b89734426253f64b6d4797ba4d849c3020fb52
merged in Rocky Release.
By default live migration is disabled if instance has a numa topology. But can
still be enabled by configure CONF.workarounds.enable_numa_live_migration. As
live migration is really very important for us in daily operation work.
So when I do live migration to these 2 VMs at the same time what will
happen?
In my case, I will encounter 3 problems.
#1. Because numa related information is not reported to placement. Placement
API will return same candidates, and as schedule action is async so there is
probability that VM1 and VM2 will pick the same dest host. In my case, these 2
VMs both passed scheduler and picked the same host.
#2. And then as BP numa-aware-live-
migration[https://review.opendev.org/#/q/topic:bp/numa-aware-live-
migration] is not implement completed yet, VM1 and VM2 will use the same
numa-topology from their src host. So as a result after VM1 and VM2
start up. Conflict will happen on host CPU 50 and 22. About numa-aware-
live-migration related bug can be found at
https://bugs.launchpad.net/nova/+bug/1289064
#3. And as VM1 and VM2 have numa-topology conflict, we will hit the
third problem. That is as the title says resource tracker failed to
update usage. That is because when call _update_usage in RT, it will
eventually call numa_usage_from_instances.
nova.compute.resource_tracker:_update_usage
` nova.virt.hardware:get_host_numa_usage_from_instance
` nova.virt.hardware:numa_usage_from_instances
And numa_usage_from_instances will
if free:
if (instancecell.cpu_thread_policy ==
fields.CPUThreadAllocationPolicy.ISOLATE):
newcell.unpin_cpus_with_siblings(pinned_cpus)
else:
newcell.unpin_cpus(pinned_cpus)
else:
if (instancecell.cpu_thread_policy ==
fields.CPUThreadAllocationPolicy.ISOLATE):
newcell.pin_cpus_with_siblings(pinned_cpus)
else:
newcell.pin_cpus(pinned_cpus)
And in pin_cpus, pin_cpus_with_siblings, unpin_cpus and
unpin_cpus_with_siblings, if there is numa-topology conflict, they will
raise an Exception. The result is RT failed to update usage to
Scheduler. And Eventually cause scheduler always think this host has
enough resource to boot new VMs. So the result is disaster.
So I think, to completed solve problem with VMs has a numa-topology.
For
Problem #1, we need to report numa topology to placement API as well, and take
numa-topology into account when get candidates from placement.
Problem #2，we need to continue complete BP numa-aware-live-migration
Problem #3, numa_usage_from_instances is used in RT and scheduler.
In scheduler numa_usage_from_instances will not hit this problem because it is
used right after virt.hardware.numa_fit_instance_to_host. So I think raise an
exception has no meaning. We can just change the exception to an Error Log
instead.
Above is the summary about the live migration issue in my mind.
And this bug is focused on solving the problem#3.
** Affects: nova
Importance: Undecided
Status: New
--
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/1829349
Title:
Resource Tracker failed to update usage in case numa topology conflict
happen
Status in OpenStack Compute (nova):
New
Bug description:
Let me describe when this bug will happen first.
Assume there are 2 running VMs they are booted with flavor that
contain metadata 'hw:cpu_policy=dedicated'.
And assume some of these 2 VMs' vCPUs are pinned to the same physical CPU.
Let's say VM1 pinned to {"0": 50, "1": 22, "2": 49, "3": 21}
and VM2 pinned to {"0": 27, "1": 55, "2": 50, "3": 22}
Refer to patch
https://opendev.org/openstack/nova/commit/52b89734426253f64b6d4797ba4d849c3020fb52
merged in Rocky Release.
By default live migration is disabled if instance has a numa topology. But
can still be enabled by configure CONF.workarounds.enable_numa_live_migration.
As live migration is really very important for us in daily operation work.
So when I do live migration to these 2 VMs at the same time what will
happen?
In my case, I will encounter 3 problems.
#1. Because numa related information is not reported to placement. Placement
A
[Yahoo-eng-team] [Bug 1829357] [NEW] Firewall-as-a-Service (FWaaS) v2 scenario in neutron
Public bug reported: Fwaas_v2 can only use the openstack command line to create resources, not using the neutron command line. openstack cli restful api /v2.0/fwaas/ neutron cli restful api /v2.0/fw/ The following documents need to be updated https://docs.openstack.org/neutron/stein/admin/fwaas-v2-scenario.html This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 14.0.2.dev17 on 2019-02-28 15:57:08 SHA: 7b0c10e15cf3f85d334b7414b0406793c0e0ddc3 Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/fwaas-v2-scenario.rst URL: https://docs.openstack.org/neutron/stein/admin/fwaas-v2-scenario.html ** Affects: neutron Importance: Undecided Assignee: zhanghao (zhanghao2) Status: New ** Tags: doc ** Changed in: neutron Assignee: (unassigned) => zhanghao (zhanghao2) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1829357 Title: Firewall-as-a-Service (FWaaS) v2 scenario in neutron Status in neutron: New Bug description: Fwaas_v2 can only use the openstack command line to create resources, not using the neutron command line. openstack cli restful api /v2.0/fwaas/ neutron cli restful api /v2.0/fw/ The following documents need to be updated https://docs.openstack.org/neutron/stein/admin/fwaas-v2-scenario.html This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 14.0.2.dev17 on 2019-02-28 15:57:08 SHA: 7b0c10e15cf3f85d334b7414b0406793c0e0ddc3 Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/fwaas-v2-scenario.rst URL: https://docs.openstack.org/neutron/stein/admin/fwaas-v2-scenario.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1829357/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829387] [NEW] no way for non admin users to get networks
Public bug reported: issue similar to this -> https://bugs.launchpad.net/nova/+bug/1737050 we have read_only role defined in keystone, it can get all projects, instances, even network agents, but can't filter networks for project example rule: "ro_admin": "role:ro_admin" policy: "get_network": "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc or rule:ro_admin", -> doesn't work, returns empty response "get_agent": "rule:admin_only or rule:ro_admin", -> works as expected environment: stable/stein versions: neutron 14.0.1 keystone 15.0.0 ** 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/1829387 Title: no way for non admin users to get networks Status in neutron: New Bug description: issue similar to this -> https://bugs.launchpad.net/nova/+bug/1737050 we have read_only role defined in keystone, it can get all projects, instances, even network agents, but can't filter networks for project example rule: "ro_admin": "role:ro_admin" policy: "get_network": "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc or rule:ro_admin", -> doesn't work, returns empty response "get_agent": "rule:admin_only or rule:ro_admin", -> works as expected environment: stable/stein versions: neutron 14.0.1 keystone 15.0.0 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1829387/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1826523] Re: libvirtError exceptions during volume attach leave volume connected to host
** Also affects: cloud-archive Importance: Undecided Status: New ** Also affects: cloud-archive/stein Importance: Undecided Status: New ** Also affects: cloud-archive/queens Importance: Undecided Status: New ** Also affects: cloud-archive/rocky Importance: Undecided Status: New ** Changed in: cloud-archive/queens Importance: Undecided => Medium ** Changed in: cloud-archive/queens Status: New => Triaged ** Changed in: cloud-archive/rocky Importance: Undecided => Medium ** Changed in: cloud-archive/rocky Status: New => Triaged ** Changed in: cloud-archive/stein Importance: Undecided => Medium ** Changed in: cloud-archive/stein Status: New => Triaged -- 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/1826523 Title: libvirtError exceptions during volume attach leave volume connected to host Status in Ubuntu Cloud Archive: Triaged Status in Ubuntu Cloud Archive queens series: Triaged Status in Ubuntu Cloud Archive rocky series: Triaged Status in Ubuntu Cloud Archive stein series: Triaged Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: Fix Committed Status in OpenStack Compute (nova) rocky series: Fix Committed Status in OpenStack Compute (nova) stein series: Fix Committed Status in nova package in Ubuntu: Triaged Status in nova source package in Bionic: Triaged Status in nova source package in Cosmic: Triaged Status in nova source package in Disco: Triaged Bug description: [Impact] * This is an additional patch required for bug #1825882, when a libvirt exception that prevents the volume attachment to complete, the underlying volumes should be disconnected from the host. [Test Case] * Deploy any OpenStack version up to Pike , which includes ceph backed cinder * Create a guest VM (openstack server ...) * Create a test cinder volume $ openstack volume create test --size 10 * Force a drop on ceph traffic. Run the following command on the nova hypervisor on which the server runs. $ iptables -A OUTPUT -d ceph-mon-addr -p tcp --dport 6800 -j DROP * Attach the volume to a running instance. $ openstack server add volume 7151f507-a6b7-4f6d-a4cc-fd223d9feb5d 742ff117-21ae-4d1b-a52b-5b37955716ff * This should cause the volume attachment to fail $ virsh domblklist instance-x Target Source vda nova/7151f507-a6b7-4f6d-a4cc-fd223d9feb5d_disk No volume should attached after this step. * If the behavior is fixed: * Check that openstack server show , doesn't displays the displays the volume as attached. * If the behavior isn't fixed: * openstack server show , will display the volume in the volumes_attached property. [Expected result] * Volume attach fails and the volume is disconnected from the host. [Actual result] * Volume attach fails but remains connected to the host. [Regression Potential] * We haven't identified any regression potential on this SRU. [Other Info] * N/A To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1826523/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1825882] Re: [SRU] Virsh disk attach errors silently ignored
** Also affects: cloud-archive/queens Importance: Undecided Status: New ** Also affects: cloud-archive/rocky Importance: Undecided Status: New ** Also affects: cloud-archive/stein Importance: Undecided Assignee: Sahid Orentino (sahid-ferdjaoui) Status: New ** Changed in: cloud-archive/queens Importance: Undecided => Medium ** Changed in: cloud-archive/queens Status: New => Triaged ** Changed in: cloud-archive/rocky Importance: Undecided => Medium ** Changed in: cloud-archive/rocky Status: New => Triaged ** Changed in: cloud-archive/stein Importance: Undecided => Medium ** Changed in: cloud-archive/stein Status: New => Triaged -- 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/1825882 Title: [SRU] Virsh disk attach errors silently ignored Status in Ubuntu Cloud Archive: Triaged Status in Ubuntu Cloud Archive queens series: Triaged Status in Ubuntu Cloud Archive rocky series: Triaged Status in Ubuntu Cloud Archive stein series: Triaged Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: Fix Committed Status in OpenStack Compute (nova) rocky series: Fix Committed Status in OpenStack Compute (nova) stein series: Fix Committed Status in nova package in Ubuntu: Triaged Status in nova source package in Bionic: Triaged Status in nova source package in Cosmic: Triaged Status in nova source package in Disco: Triaged Bug description: [Impact] The following commit (1) is causing volume attachments which fail due to libvirt device attach erros to be silently ignored and Nova report the attachment as successful. It seems that the original intention of the commit was to log a condition and re-raise the exeption, but if the exception is of type libvirt.libvirtError and does not contain the searched pattern, the exception is ignored. If you unindent the raise statement, errors are reported again. In our case we had ceph/apparmor configuration problems in compute nodes which prevented virsh attaching the device; volumes appeared as successfully attached but the corresponding block device missing in guests VMs. Other libvirt attach error conditions are ignored also, as when you have already occuppied device names (i.e. 'Target vdb already exists', device is busy, etc.) (1) https://github.com/openstack/nova/commit/78891c2305bff6e16706339a9c5eca99a84e409c [Test Case] * Deploy any OpenStack version up to Pike , which includes ceph backed cinder * Create a guest VM (openstack server ...) * Create a test cinder volume $ openstack volume create test --size 10 * Force a drop on ceph traffic. Run the following command on the nova hypervisor on which the server runs. $ iptables -A OUTPUT -d ceph-mon-addr -p tcp --dport 6800 -j DROP * Attach the volume to a running instance. $ openstack server add volume 7151f507-a6b7-4f6d-a4cc-fd223d9feb5d 742ff117-21ae-4d1b-a52b-5b37955716ff * This should cause the volume attachment to fail $ virsh domblklist instance-x Target Source vda nova/7151f507-a6b7-4f6d-a4cc-fd223d9feb5d_disk No volume should attached after this step. * If the behavior is fixed: * Check that openstack server show , doesn't displays the displays the volume as attached. * Check that proper log entries states the libvirt exception and error. * If the behavior isn't fixed: * openstack server show , will display the volume in the volumes_attached property. [Expected result] * Volume attach fails and a proper exception is logged. [Actual result] * Volume attach fails but remains connected to the host and no further exception gets logged. [Regression Potential] * We haven't identified any regression potential on this SRU. [Other Info] * N/A Description To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1825882/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829411] [NEW] vendor_data2 not supported
Public bug reported: For the OpenStack datasource, I see some references to vendor_data2.json but it is not accessible via cloud.datasource.vendordata_pure or cloud.datasource.vendordata_raw or any other variable. Can full support be added for vendor_data2? It seems like it is supported, but looks like it is never requested or parsed. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1829411 Title: vendor_data2 not supported Status in cloud-init: New Bug description: For the OpenStack datasource, I see some references to vendor_data2.json but it is not accessible via cloud.datasource.vendordata_pure or cloud.datasource.vendordata_raw or any other variable. Can full support be added for vendor_data2? It seems like it is supported, but looks like it is never requested or parsed. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1829411/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1788936] Re: Network address translation in Neutron wrong RFC in documentation
** Changed in: openstack-manuals 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/1788936 Title: Network address translation in Neutron wrong RFC in documentation Status in neutron: Fix Released Status in openstack-manuals: Invalid Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ x] This doc is inaccurate in this way: Shouldn't it be RFC1918 which defines private IP address ranges on networks instead of RFC5737 which defines private ranges for use in documentation? RFC 5737 reserves the following three subnets as private addresses: 192.0.2.0/24 198.51.100.0/24 203.0.113.0/24 - [ ] This is a doc addition request. - [x] I have a fix to the document that I can paste below including example: RFC 1918 reserves the following three subnets as private addresses: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 11.0.6.dev66 on 2018-08-13 11:52 SHA: b87eb4814a1a936844a0dbd726e7cd9a0de5b492 Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/intro-nat.rst URL: https://docs.openstack.org/neutron/pike/admin/intro-nat.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1788936/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829410] [NEW] vendor_data2 not supported
Public bug reported: For the OpenStack datasource, I see some references to vendor_data2.json but it is not accessible via cloud.datasource.vendordata_pure or cloud.datasource.vendordata_raw or any other variable. Can full support be added for vendor_data2? It seems like it is supported, but looks like it is never requested or parsed. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1829410 Title: vendor_data2 not supported Status in cloud-init: New Bug description: For the OpenStack datasource, I see some references to vendor_data2.json but it is not accessible via cloud.datasource.vendordata_pure or cloud.datasource.vendordata_raw or any other variable. Can full support be added for vendor_data2? It seems like it is supported, but looks like it is never requested or parsed. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1829410/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829414] [NEW] Attribute filtering should be based on all objects instead of only first
Public bug reported: When returning a resource from neutron the resouce attribute are filtered based on the current policy and the attributes defined in the resource definition. Currently on the first object in a list of objects to be returned is checked, if it happens that there are other objects in the list that have additional attributes, those are not checked at all. I believe all attributes should be checked. Since this originally changed from checking all to only checking the first in a "efficiency of api" commit, I will propose a patchset that has minimal impact while still fixing the issue; please provide feedback here or on gerrit. ** Affects: neutron Importance: Undecided Assignee: Tom Stappaerts (tstappae) Status: New ** Changed in: neutron Assignee: (unassigned) => Tom Stappaerts (tstappae) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1829414 Title: Attribute filtering should be based on all objects instead of only first Status in neutron: New Bug description: When returning a resource from neutron the resouce attribute are filtered based on the current policy and the attributes defined in the resource definition. Currently on the first object in a list of objects to be returned is checked, if it happens that there are other objects in the list that have additional attributes, those are not checked at all. I believe all attributes should be checked. Since this originally changed from checking all to only checking the first in a "efficiency of api" commit, I will propose a patchset that has minimal impact while still fixing the issue; please provide feedback here or on gerrit. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1829414/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1806053] Please test proposed package
Hello Akihiro, or anyone else affected, Accepted neutron-fwaas-dashboard into stein-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository. Please help us by testing this new package. To enable the -proposed repository: sudo add-apt-repository cloud-archive:stein-proposed sudo apt-get update Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-stein-needed to verification-stein-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-stein-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: cloud-archive/stein Status: Fix Released => Fix Committed ** Tags added: verification-stein-needed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1806053 Title: APITestCase still needs to be patched utils.patch_middleware_get_user() Status in Ubuntu Cloud Archive: Fix Committed Status in Ubuntu Cloud Archive queens series: Invalid Status in Ubuntu Cloud Archive rocky series: Fix Committed Status in Ubuntu Cloud Archive stein series: Fix Committed Status in OpenStack Dashboard (Horizon): Fix Released Status in horizon package in Ubuntu: Fix Released Status in neutron-fwaas-dashboard package in Ubuntu: Fix Released Status in horizon source package in Bionic: Invalid Status in neutron-fwaas-dashboard source package in Bionic: Invalid Status in horizon source package in Cosmic: Fix Committed Status in neutron-fwaas-dashboard source package in Cosmic: Triaged Status in horizon source package in Disco: Fix Released Status in neutron-fwaas-dashboard source package in Disco: Fix Committed Status in horizon source package in Eoan: Fix Released Status in neutron-fwaas-dashboard source package in Eoan: Fix Released Bug description: After merging commit 0d163613265e036818fe567793a4fc88fe140d4a, we see some UT breakage in horizon plugins. bgpvpn-dashboard https://bugs.launchpad.net/bgpvpn/+bug/1805240 neutron-fwaas-dashboard https://review.openstack.org/621155 neutron-vpnaas-dashboard https://review.openstack.org/621152 Previously APITestCase called patch_middleware_get_user explicitly, but the commit above dropped it. This seems to trigger the above UT failures. - SRU Details for Ubuntu -- [Impact] See above. Also, building a horizon dashboard package, such as neutron-fwaas- dashboard, will result in several unit test failures such due to "AttributeError: 'AnonymousUser' object has no attribute 'token'". [Test Case] Build the horizon and neutron-fwaas-dashboard packages. [Regression Potential] Very minimal as the changes update test code only. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1806053/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829441] [NEW] instance-data: surface merged cloud-config through cloud-init query command
Public bug reported: It would be nice if cloud-init query could give simple cli access to the on-disk merged cloud-config. Use cases that this would help: - customers wondering ultimately what default_user was used during cloud-init setup - simple CLI to view what config modules are configured active on a given boot - datasource configuration passed to cloud-init - network configuration passed to cloud-init We sometimes get questions in IRC for non-ubuntu distributions or unofficial images where our response is to look in /etc/cloud/cloud.cfg and cloud.cfg.d to see what modules/users are configured. it'd be fairly simple to instrument this in the existing cloud-init query CLI. ** Affects: cloud-init Importance: Undecided Status: New ** Summary changed: - instance-data: surface default user in instance-data.json + instance-data: surface merged cloud-config in instance-data.json ** Summary changed: - instance-data: surface merged cloud-config in instance-data.json + instance-data: surface merged cloud-config through cloud-init query command -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1829441 Title: instance-data: surface merged cloud-config through cloud-init query command Status in cloud-init: New Bug description: It would be nice if cloud-init query could give simple cli access to the on-disk merged cloud-config. Use cases that this would help: - customers wondering ultimately what default_user was used during cloud-init setup - simple CLI to view what config modules are configured active on a given boot - datasource configuration passed to cloud-init - network configuration passed to cloud-init We sometimes get questions in IRC for non-ubuntu distributions or unofficial images where our response is to look in /etc/cloud/cloud.cfg and cloud.cfg.d to see what modules/users are configured. it'd be fairly simple to instrument this in the existing cloud-init query CLI. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1829441/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829239] Re: pyroute2 version conflict
Reviewed: https://review.opendev.org/659294 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4353d1b06ce4c966161d5fd4aeff81b93f9e2e22 Submitter: Zuul Branch:master commit 4353d1b06ce4c966161d5fd4aeff81b93f9e2e22 Author: YAMAMOTO Takashi Date: Wed May 15 13:52:59 2019 + Revert "Bump Pyroute2 version to 0.5.5" This reverts commit d2d57371dc7dd35b1f66eb6390d96dfc512eeca1. Change-Id: Ic04adae9cd27ce18324d5a2b2ec1966b38eddc2b Closes-Bug: #1829239 ** 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/1829239 Title: pyroute2 version conflict Status in networking-midonet: New Status in neutron: Fix Released Bug description: eg. http://logs.openstack.org/90/659090/3/check/openstack-tox- pep8/57bd295/job-output.txt.gz 2019-05-14 15:02:52.604303 | ubuntu-bionic | pep8 run-test: commands[0] | flake8 2019-05-14 15:02:52.604442 | ubuntu-bionic | setting PATH=/home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games 2019-05-14 15:02:52.605409 | ubuntu-bionic | [5702] /home/zuul/src/opendev.org/openstack/networking-midonet$ /home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/bin/flake8 2019-05-14 15:02:54.158191 | ubuntu-bionic | /home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/pep8.py:1186: DeprecationWarning: inspect.getargspec() is deprecated, use inspect.signature() or inspect.getfullargspec() 2019-05-14 15:02:54.158425 | ubuntu-bionic | args = inspect.getargspec(check)[0] 2019-05-14 15:02:54.158624 | ubuntu-bionic | /home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/setuptools/depends.py:2: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses 2019-05-14 15:02:54.158656 | ubuntu-bionic | import imp 2019-05-14 15:02:54.158854 | ubuntu-bionic | /home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/pep8.py:1192: DeprecationWarning: inspect.getargspec() is deprecated, use inspect.signature() or inspect.getfullargspec() 2019-05-14 15:02:54.158929 | ubuntu-bionic | if inspect.getargspec(check.__init__)[0][:2] == ['self', 'tree']: 2019-05-14 15:02:54.159102 | ubuntu-bionic | /home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/pep8.py:1192: DeprecationWarning: inspect.getargspec() is deprecated, use inspect.signature() or inspect.getfullargspec() 2019-05-14 15:02:54.159214 | ubuntu-bionic | if inspect.getargspec(check.__init__)[0][:2] == ['self', 'tree']: 2019-05-14 15:02:54.159391 | ubuntu-bionic | /home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/pep8.py:1186: DeprecationWarning: inspect.getargspec() is deprecated, use inspect.signature() or inspect.getfullargspec() 2019-05-14 15:02:54.159438 | ubuntu-bionic | args = inspect.getargspec(check)[0] 2019-05-14 15:02:54.159604 | ubuntu-bionic | /home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/pep8.py:1186: DeprecationWarning: inspect.getargspec() is deprecated, use inspect.signature() or inspect.getfullargspec() 2019-05-14 15:02:54.159650 | ubuntu-bionic | args = inspect.getargspec(check)[0] 2019-05-14 15:02:54.355548 | ubuntu-bionic | Traceback (most recent call last): 2019-05-14 15:02:54.355851 | ubuntu-bionic | File "/home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/bin/flake8", line 10, in 2019-05-14 15:02:54.355933 | ubuntu-bionic | sys.exit(main()) 2019-05-14 15:02:54.356133 | ubuntu-bionic | File "/home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/flake8/main.py", line 36, in main 2019-05-14 15:02:54.356237 | ubuntu-bionic | report = flake8_style.check_files() 2019-05-14 15:02:54.356464 | ubuntu-bionic | File "/home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/flake8/engine.py", line 181, in check_files 2019-05-14 15:02:54.356602 | ubuntu-bionic | return self._retry_serial(self._styleguide.check_files, paths=paths) 2019-05-14 15:02:54.356827 | ubuntu-bionic | File "/home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/flake8/engine.py", line 172, in _retry_serial 2019-05-14 15:02:54.356921 | ubuntu-bionic | return func(*args, **kwargs) 2019-05-14 15:02:54.357134 | ubuntu-bionic | File "/home/zuul/src/opendev.org/openstack/networking-midonet/.tox/pep8/lib/python3.6/site-packages/pep8.py", line 1670, in check_files 2019-05-14 15:02:5
[Yahoo-eng-team] [Bug 1828865] Re: Pass the correct subnet to the port creation function in "test_port_ip_update_revises"
Reviewed: https://review.opendev.org/658866 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=872dd7f48400f0ee059876b01d4034aa75f97787 Submitter: Zuul Branch:master commit 872dd7f48400f0ee059876b01d4034aa75f97787 Author: Rodolfo Alonso Hernandez Date: Mon May 13 17:06:44 2019 + Use created subnet in port generator in "test_port_ip_update_revises" We are hitting sometimes a problem in "test_port_ip_update_revises" [1]. This happens because the port created doesn't belong to the previously created subnet. We need to enforce that the port is created in the subnet specifically created in this test. [1]http://logs.openstack.org/69/650269/12/check/openstack-tox-lower-constraints/7adf36e/testr_results.html.gz Change-Id: I399f100fe30b6a03248cef5e6026204d4d1ffb2e Closes-Bug: #1828865 ** 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/1828865 Title: Pass the correct subnet to the port creation function in "test_port_ip_update_revises" Status in neutron: Fix Released Bug description: We are hitting sometimes a problem in "test_port_ip_update_revises" [1]. This happens because the port created doesn't belong to the previously created subnet. We need to enforce that the port is created in the subnet specifically created in this test. [1] http://logs.openstack.org/69/650269/12/check/openstack-tox-lower- constraints/7adf36e/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1828865/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1823038] Re: Neutron-keepalived-state-change fails to check initial router state
Reviewed: https://review.opendev.org/657849 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=aacd11ab9f8f24291f369d23662b0cb6b3fe43e3 Submitter: Zuul Branch:master commit aacd11ab9f8f24291f369d23662b0cb6b3fe43e3 Author: Rodolfo Alonso Hernandez Date: Fri May 10 10:58:08 2019 + Remove rootwrap configuration from neutron-keepalived-state-change New IP command introduced by Ie3fe825d65408fc969c478767b411fe0156e9fbc requires only privsep initialization. This patch removes the prisep error FailedToDropPrivileges when executed under neutron-rootwrap. Closes-Bug: #1823038 Change-Id: I6cde3c9dae7ffdccce49e88c3c79d1c379f291cf ** 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/1823038 Title: Neutron-keepalived-state-change fails to check initial router state Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive pike series: Fix Released Status in Ubuntu Cloud Archive queens series: Fix Released Status in Ubuntu Cloud Archive rocky series: Fix Released Status in Ubuntu Cloud Archive stein series: Fix Released Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Bionic: Fix Released Status in neutron source package in Cosmic: Fix Released Status in neutron source package in Disco: Fix Released Bug description: [Impact] Fix for bug 1818614 in *-proposed includes a regression is the deployment is not using the rootwrap-daemon. [Test Case] See bug 1818614 [Regression Potential] Low - this is a minor fix to resolve a regression due to the SRU bug 1818614. [Original Description] As fix for bug https://bugs.launchpad.net/neutron/+bug/1818614 we added to neutron-keepalived-state-change monitor possibility to check initial status of router (master or slave). Unfortunately for some reason I see now in journal log of functional job that this check is failing with error like: Apr 03 09:19:09 ubuntu-bionic-ovh-gra1-0004666718 neutron-keepalived-state-change[1553]: 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change [-] Failed to get initial status of router cd300e6b-8222-4100-8f6a-3b5c4d5fe37b: FailedToDropPrivileges: privsep helper command exited non-zero (96) 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change Traceback (most recent call last): 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change File "/home/zuul/src/git.openstack.org/openstack/neutron/neutron/agent/l3/keepalived_state_change.py", line 98, in handle_initial_state 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change for address in ip.addr.list(): 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change File "/home/zuul/src/git.openstack.org/openstack/neutron/neutron/agent/linux/ip_lib.py", line 540, in list 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change **kwargs) 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change File "/home/zuul/src/git.openstack.org/openstack/neutron/neutron/agent/linux/ip_lib.py", line 1412, in get_devices_with_ip 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change devices = privileged.get_link_devices(namespace, **link_args) 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change File "/home/zuul/src/git.openstack.org/openstack/neutron/.tox/dsvm-functional-python27/local/lib/python2.7/site-packages/oslo_privsep/priv_context.py", line 240, in _wrap 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change self.start() 2019-04-03 09:19:09.778 1553 ERROR neutron.agent.l3.keepalived_state_change File "/home/zuul/src/git.openstack.org/openstack/neutron/.tox/dsvm-functional-python27/l
[Yahoo-eng-team] [Bug 1829304] Re: Neutron returns HttpException: 500 on certain operations with modified list of policies for non-admin users
Reviewed: https://review.opendev.org/659397 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2c1098b3afb4f5d7cd1d10eaa722652624e6bb74 Submitter: Zuul Branch:master commit 2c1098b3afb4f5d7cd1d10eaa722652624e6bb74 Author: Nate Johnston Date: Wed May 15 19:18:52 2019 -0400 Use six.viewkeys instead of dict.keys to avoid py2 to py3 problems This change fixes an 'RuntimeError: dictionary changed size during iteration' error that is raised because of different behaviour between python2 and python3. We use the six library to ensure that the behavior is compatible across versions. Change-Id: I0723ae10825e1e2d86789627895e3286d8c97602 Resolves-Bug: #1829304 ** 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/1829304 Title: Neutron returns HttpException: 500 on certain operations with modified list of policies for non-admin users Status in neutron: Fix Released Bug description: Description of problem: When deploying with a modified list of Neutron API policies, post deployment, policies which worked on previous versions will result in Neutron API Server returning 'HttpException: 500' when using the API with non admin users. Additional API policies which were passed during deployment: http://paste.openstack.org/show/751347/ Example: 1. Source credentials with non admin user [stack@undercloud-0 ~]$ source /home/stack/overcloudrc_user_tenant 2. Query port list with as non admin user (overcloud) [stack@undercloud-0 ~]$ openstack port list At this point, neutron will return: HttpException: 500: Server Error for url: http://10.35.141.150:9696/v2.0/ports, Internal Server Error And the following exception will be generated inside server.log on controller nodes: server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors [req-98bfd77f-1fc1-4d13-a0fd-02e82f6caa53 2236f6cc04c04964a0b435599ffb7acb ef4de28cbec04ea785b855010e7f46a1 - default default] An error occurred during processing the request: POST /v2.0/ports HTTP/1.0 server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors Traceback (most recent call last): server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python3.6/site-packages/oslo_middleware/catch_errors.py", line 40, in __call__ server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors response = req.get_response(self.application) server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python3.6/site-packages/webob/request.py", line 1314, in send server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors application, catch_exc_info=False) server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python3.6/site-packages/webob/request.py", line 1278, in call_application server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors app_iter = application(self.environ, start_response) server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python3.6/site-packages/webob/dec.py", line 129, in __call__ server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors resp = self.call_func(req, *args, **kw) server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python3.6/site-packages/webob/dec.py", line 193, in call_func server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors return self.func(req, *args, **kwargs) server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python3.6/site-packages/osprofiler/web.py", line 112, in __call__ server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors return request.get_response(self.application) server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python3.6/site-packages/webob/request.py", line 1314, in send server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors application, catch_exc_info=False) server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python3.6/site-packages/webob/request.py", line 1278, in call_application server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors app_iter = application(self.environ, start_response) server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python3.6/site-packages/webob/dec.py", line 129, in __call__ server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors resp = self.call_func(req, *args, **kw) server.log:2019-05-08 07:33:43.076 22 ERROR oslo_middleware.catch_errors File "/usr/lib/python
[Yahoo-eng-team] [Bug 1827418] Re: Routed provider networks in neutron - placement CLI example
Reviewed: https://review.opendev.org/656913 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8f6939b4f3651c9cd0609fd5c2960681f52dd47f Submitter: Zuul Branch:master commit 8f6939b4f3651c9cd0609fd5c2960681f52dd47f Author: Lajos Katona Date: Thu May 2 20:00:19 2019 -0600 Change curl to osc for listing resource provider inventories Change-Id: I4ffca16ebd1998335132747482e85dbb18be70e7 Closes-Bug: #1827418 ** 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/1827418 Title: Routed provider networks in neutron - placement CLI example Status in neutron: Fix Released Bug description: - [x] This is a doc addition request. The section of the doc that has the curl request to placement which says "As of the writing of this guide, there is not placement API CLI client, so the curl command is used for this example.", that could be replaced with using osc-placement now: https://docs.openstack.org/osc-placement/latest/cli/index.html #resource-provider-aggregate-list --- Release: 13.0.4.dev30 on 2019-04-27 12:52 SHA: b4f3163dc4b1457755f151e1b30d89d31bec5e14 Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/config-routed-networks.rst URL: https://docs.openstack.org/neutron/rocky/admin/config-routed-networks.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1827418/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829449] [NEW] Implement consistency check and self-healing for SDN-managed fabrics
Public bug reported: When SDN mechanism driver is used in Neutron (on our site we use mlnx_sdn_assist but this issue isn’t limited just to this driver, we hear about similar issues with at least three other SDN solutions) there is no consistency checking applied to the fabric past the initial port configuration. If there is an issue with the SDN layer after Neutron issues the request to the SDN controller and the requested configuration is not implemented appropriately, there is no way for Neutron to know about this. Ideally such scenarios should not happen but the feedback from operators indicates that these issues occasionally do happen for a variety of reasons and when they happen the user impact is significant as the state of neutron and SDN needs to be merged manually which is generally non-trivial. If SDN mechanism drivers are not used and the standard openvswitch based networking is configured, neutron-openvswitch-agent periodically checks the port configuration and enforces the desired state if needed. Investigating if/how this could be applied to SDN in a general case would probably be a logical first step. It would be very valuable for the SDN-based cloud operators to be able to: Have neutron poll SDN to check the state of each of the ports and Have neutron “push” the state of each port to make sure that the SDN state is consistent with neutron state Ensure that each SDN solution supported with OpenStack provides support for those actions Initially these actions could be triggered manually (or from a monitoring system) and later on it would likely become a periodic task adding self-healing capabilities to SDN-based OpenStack installations. ** 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/1829449 Title: Implement consistency check and self-healing for SDN-managed fabrics Status in neutron: New Bug description: When SDN mechanism driver is used in Neutron (on our site we use mlnx_sdn_assist but this issue isn’t limited just to this driver, we hear about similar issues with at least three other SDN solutions) there is no consistency checking applied to the fabric past the initial port configuration. If there is an issue with the SDN layer after Neutron issues the request to the SDN controller and the requested configuration is not implemented appropriately, there is no way for Neutron to know about this. Ideally such scenarios should not happen but the feedback from operators indicates that these issues occasionally do happen for a variety of reasons and when they happen the user impact is significant as the state of neutron and SDN needs to be merged manually which is generally non-trivial. If SDN mechanism drivers are not used and the standard openvswitch based networking is configured, neutron-openvswitch-agent periodically checks the port configuration and enforces the desired state if needed. Investigating if/how this could be applied to SDN in a general case would probably be a logical first step. It would be very valuable for the SDN-based cloud operators to be able to: Have neutron poll SDN to check the state of each of the ports and Have neutron “push” the state of each port to make sure that the SDN state is consistent with neutron state Ensure that each SDN solution supported with OpenStack provides support for those actions Initially these actions could be triggered manually (or from a monitoring system) and later on it would likely become a periodic task adding self-healing capabilities to SDN-based OpenStack installations. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1829449/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1828473] Re: Dnsmasq spawned by neutron-dhcp-agent should use bind-dynamic option instead of bind-interfaces
Reviewed: https://review.opendev.org/658240 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=09ee9347864d731ce7ccf241178559815e82f57c Submitter: Zuul Branch:master commit 09ee9347864d731ce7ccf241178559815e82f57c Author: Brian Haley Date: Thu May 9 22:33:02 2019 -0400 Use --bind-dynamic with dnsmasq instead of --bind-interfaces Dnsmasq emits a warning when started in most neutron deployments: dnsmasq[27287]: LOUD WARNING: use --bind-dynamic rather than --bind-interfaces to avoid DNS amplification attacks via these interface(s) Since option --bind-dynamic is available since dnsmasq 2.63 (https://github.com/liquidm/dnsmasq/blob/master/FAQ#L239) and we require 2.67, change to use this option instead. Change-Id: Id7971bd99b04aca38180ff109f542422b1a925d5 Closes-bug: #1828473 ** 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/1828473 Title: Dnsmasq spawned by neutron-dhcp-agent should use bind-dynamic option instead of bind-interfaces Status in neutron: Fix Released Bug description: According to warning log from dnsmasq: May 09 23:08:59 devstack-ubuntu-ovs dnsmasq[27287]: LOUD WARNING: use --bind-dynamic rather than --bind-interfaces to avoid DNS amplification attacks via these interface(s) Option bind-interfaces is available since dnsmasq 2.63 (https://github.com/liquidm/dnsmasq/blob/master/FAQ#L239) and we are already requiring 2.67 at least so we should change this option in calling dnsmasq process. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1828473/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829454] [NEW] Deprecated as of Train
Public bug reported: This issue is for tracking deprecations during the Train release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that deprecate items in keystone. This issue will be closed at the end of the cycle. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1829454 Title: Deprecated as of Train Status in OpenStack Identity (keystone): New Bug description: This issue is for tracking deprecations during the Train release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that deprecate items in keystone. This issue will be closed at the end of the cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1829454/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829453] [NEW] Removed as of Train
Public bug reported: This issue is for tracking removals during the Train release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that remove deprecated items from keystone. This issue will be closed at the end of the cycle. ** Affects: keystone Importance: Undecided Status: New ** Summary changed: - Removed as of train + Removed as of Train -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1829453 Title: Removed as of Train Status in OpenStack Identity (keystone): New Bug description: This issue is for tracking removals during the Train release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that remove deprecated items from keystone. This issue will be closed at the end of the cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1829453/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829455] [NEW] tox-fast8 support which will run pep8 only on updated(delta) code
Public bug reported: tox-fast8 support which will run prp8 only on updated contents(only on git diff) ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1829455 Title: tox-fast8 support which will run pep8 only on updated(delta) code Status in OpenStack Identity (keystone): New Bug description: tox-fast8 support which will run prp8 only on updated contents(only on git diff) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1829455/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1829461] [NEW] Volume Group Under project panel not working
Public bug reported: Volume Group under project panel not working properly for master branch. Volume Group table under project panel is missing same is attached ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1829461 Title: Volume Group Under project panel not working Status in OpenStack Dashboard (Horizon): New Bug description: Volume Group under project panel not working properly for master branch. Volume Group table under project panel is missing same is attached To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1829461/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
