[Yahoo-eng-team] [Bug 1876026] [NEW] need a support to not allow 0.0.0.0/8 , 0.0.0.0/32 or ::/0
Public bug reported: With VIO, We also support 0.0.0.0/8 , 0.0.0.0/32 and ::/0 however while sending api , we are making it as 0.0.0.0/0 only as it invalid cidr and not needed from openstack point of view. We can add support so that it wont be alloewd only ** 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/1876026 Title: need a support to not allow 0.0.0.0/8 , 0.0.0.0/32 or ::/0 Status in OpenStack Compute (nova): New Bug description: With VIO, We also support 0.0.0.0/8 , 0.0.0.0/32 and ::/0 however while sending api , we are making it as 0.0.0.0/0 only as it invalid cidr and not needed from openstack point of view. We can add support so that it wont be alloewd only To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1876026/+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 1876021] [NEW] create multiple reserved_dhcp_port doesn't work as expected
Public bug reported: I create a subnet 172.30.0.0/24, gateway 172.30.0.254, disabled dhcp, 3 dhcp servers per network. In order not to occupy addresses like: 172.30.0.1, 172.30.0.2, 172.30.0.3, I want to specify dhcp port address use `reserved_dhcp_port` feature: root@mgt01:~# openstack port create --network 6a0f68ff-1382-4959-aa22-c52da91177f2 --device reserved_dhcp_port --host mgt04 --fixed-ip subnet=e80b4163-2308-4b3d-afe3-45992e1b652c,ip-address=172.30.0.251 --disable-port-security dhcp-port-1 +---+-+ | Field | Value | +---+-+ | admin_state_up| UP | | allowed_address_pairs | | | binding_host_id | mgt04 | | binding_profile | | | binding_vif_details | datapath_type='system', ovs_hybrid_plug='True', port_filter='True' | | binding_vif_type | ovs | | binding_vnic_type | normal | | created_at| 2020-04-30T02:46:33Z | | data_plane_status | None | | description | | | device_id | reserved_dhcp_port | | device_owner | | | dns_assignment| None | | dns_domain| None | | dns_name | None | | extra_dhcp_opts | | | fixed_ips | ip_address='172.30.0.251', subnet_id='e80b4163-2308-4b3d-afe3-45992e1b652c' | | id| e3ed1ba5-7cd8-4464-9bad-c71aadb85ff9 | | mac_address | fa:16:3e:fc:0b:ac | | name | dhcp-port-1 | | network_id| 6a0f68ff-1382-4959-aa22-c52da91177f2 | | port_security_enabled | False | | project_id| 0606e9bf4e9c4334b6cb9a5012c60fb8 | | qos_policy_id | None | | revision_number | 1 | | security_group_ids| | | status| DOWN | | tags | | | trunk_details | None | | updated_at| 2020-04-30T02:46:33Z | +---+-+ root@mgt01:~# openstack port create --network 6a0f68ff-1382-4959-aa22-c52da91177f2 --device reserved_dhcp_port --host mgt05 --fixed-ip subnet=e80b4163-2308-4b3d-afe3-45992e1b652c,ip-address=172.30.0.252 --disable-port-security dhcp-port-2 +---+-+ | Field | Value | +---+-+ | admin_state_up| UP | | allowed_address_pairs | | | binding_host_id | mgt05 | | binding_profile |
[Yahoo-eng-team] [Bug 1875951] [NEW] Release 20.2
Public bug reported: == Release Notes == Cloud-init release 20.2 is now available The 20.2 release: * spanned about 9 weeks * had 20 contributors from 20 domains * fixed 14 Launchpad issues Highlights: == Changelog == - doc/format: reference make-mime.py instead of an inline script (#334) - Add docs about creating parent folders (#330) [Adrian Wilkins] - DataSourceNoCloud/OVF: drop claim to support FTP (#333) (LP: #1875470) - schema: ignore spurious pylint error (#332) - schema: add json schema for write_files module (#152) - BSD: find_devs_with_ refactoring (#298) [Gonéri Le Bouder] - nocloud: drop work around for Linux 2.6 (#324) [Gonéri Le Bouder] - cloudinit: drop dependencies on unittest2 and contextlib2 (#322) - distros: handle a potential mirror filtering error case (#328) - log: remove unnecessary import fallback logic (#327) - .travis.yml: don't run integration test on ubuntu/* branches (#321) - More unit test documentation (#314) - conftest: introduce disable_subp_usage autouse fixture (#304) - YAML align indent sizes for docs readability (#323) [Tak Nishigori] - network_state: add missing space to log message (#325) - tests: add missing mocks for get_interfaces_by_mac (#326) (LP: #1873910) - test_mounts: expand happy path test for both happy paths (#319) - cc_mounts: fix incorrect format specifiers (#316) (LP: #1872836) - swap file "size" being used before checked if str (#315) [Eduardo Otubo] - HACKING.rst: add pytest version gotchas section (#311) - docs: Add steps to re-run cloud-id and cloud-init (#313) [Joshua Powers] - readme: OpenBSD is now supported (#309) [Gonéri Le Bouder] - net: ignore 'renderer' key in netplan config (#306) (LP: #1870421) - Add support for NFS/EFS mounts (#300) [Andrew Beresford] (LP: #1870370) - openbsd: set_passwd should not unlock user (#289) [Gonéri Le Bouder] - tools/.github-cla-signers: add beezly as CLA signer (#301) - util: remove unnecessary lru_cache import fallback (#299) - HACKING.rst: reorganise/update CLA signature info (#297) - distros: drop leading/trailing hyphens from mirror URL labels (#296) - HACKING.rst: add note about variable annotations (#295) - CiTestCase: stop using and remove sys_exit helper (#283) - distros: replace invalid characters in mirror URLs with hyphens (#291) (LP: #1868232) - rbxcloud: gracefully handle arping errors (#262) [Adam Dobrawy] - Fix cloud-init ignoring some misdeclared mimetypes in user-data. [Kurt Garloff] - net: ubuntu focal prioritize netplan over eni even if both present (#267) (LP: #1867029) - cloudinit: refactor util.is_ipv4 to net.is_ipv4_address (#292) - net/cmdline: replace type comments with annotations (#294) - HACKING.rst: add Type Annotations design section (#293) - net: introduce is_ip_address function (#288) - CiTestCase: remove now-unneeded parse_and_read helper method (#286) - .travis.yml: allow 30 minutes of inactivity in cloud tests (#287) - sources/tests/test_init: drop use of deprecated inspect.getargspec (#285) - setup.py: drop NIH check_output implementation (#282) - Identify SAP Converged Cloud as OpenStack [Silvio Knizek] - add Openbsd support (#147) [Gonéri Le Bouder] - HACKING.rst: add examples of the two test class types (#278) - VMWware: support to update guest info gc status if enabled (#261) [xiaofengw-vmware] - Add lp-to-git mapping for kgarloff (#279) - set_passwords: avoid chpasswd on BSD (#268) [Gonéri Le Bouder] - HACKING.rst: add Unit Testing design section (#277) - util: read_cc_from_cmdline handle urlencoded yaml content (#275) - distros/tests/test_init: add tests for _get_package_mirror_info (#272) - HACKING.rst: add links to new Code Review Process doc (#276) - freebsd: ensure package update works (#273) [Gonéri Le Bouder] - doc: introduce Code Review Process documentation (#160) - tools: use python3 (#274) - cc_disk_setup: fix RuntimeError (#270) (LP: #1868327) - cc_apt_configure/util: combine search_for_mirror implementations (#271) - bsd: boottime does not depend on the libc soname (#269) [Gonéri Le Bouder] - test_oracle,DataSourceOracle: sort imports (#266) - DataSourceOracle: update .network_config docstring (#257) - cloudinit/tests: remove unneeded with_logs configuration (#263) - .travis.yml: drop stale comment (#255) - .gitignore: add more common directories (#258) - ec2: render network on all NICs and add secondary IPs as static (#114) (LP: #1866930) - ec2 json validation: fix the reference to the 'merged_cfg' key (#256) [Paride Legovini] - releases.yaml: quote the Ubuntu version numbers (#254) [Paride Legovini] - cloudinit: remove six from packaging/tooling (#253) - util/netbsd: drop six usage (#252) - workflows: introduce stale pull request workflow (#125) - cc_resolv_conf: introduce tests and stabilise output across Python versions (#251) - fix minor issue with resolv_conf template (#144) [andreaf74] - doc: CloudInit also support NetBSD (#250) [Gonéri Le
[Yahoo-eng-team] [Bug 1829062] Re: nova placement api non-responsive due to eventlet error
Based on Chris' comment above[1] I'm closing this issue on Nova. Since Stein it is not an issue and Rocky is already in extended maintenance. If somebody want's to fix this in Rocky and older branches the please set the bug back to New. [1] https://bugs.launchpad.net/nova/+bug/1829062/comments/19 ** Changed in: nova Status: New => Won't Fix -- 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/1829062 Title: nova placement api non-responsive due to eventlet error Status in OpenStack Compute (nova): Won't Fix Status in StarlingX: Fix Released Status in tripleo: Triaged Bug description: In starlingx setup, we're running a nova docker image based on nova stable/stein as of May 6. We're seeing nova-compute processes stalling and not creating resource providers with placement. openstack hypervisor list ++-+-+-+---+ | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State | ++-+-+-+---+ | 5 | worker-1| QEMU| 192.168.206.247 | down | | 8 | worker-2| QEMU| 192.168.206.211 | down | ++-+-+-+---+ Observe this error in nova-placement-api logs related to eventlet at same time: 2019-05-14 00:44:03.636229 Traceback (most recent call last): 2019-05-14 00:44:03.636276 File "/var/lib/openstack/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 460, in fire_timers 2019-05-14 00:44:03.636536 timer() 2019-05-14 00:44:03.636560 File "/var/lib/openstack/lib/python2.7/site-packages/eventlet/hubs/timer.py", line 59, in _call_ 2019-05-14 00:44:03.636647 cb(*args, **kw) 2019-05-14 00:44:03.636661 File "/var/lib/openstack/lib/python2.7/site-packages/eventlet/semaphore.py", line 147, in _do_acquire 2019-05-14 00:44:03.636774 waiter.switch() 2019-05-14 00:44:03.636792 error: cannot switch to a different thread This is a new behaviour for us in stable/stein and suspect this is due to merge of eventlet related change on May 4: https://github.com/openstack/nova/commit/6755034e109079fb5e8bbafcd611a919f0884d14 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1829062/+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 1875847] Re: Neutron api not coming up with mod_wsgi
Using wsgi is not supported until Rocky,
https://review.opendev.org/#/c/555608/
The doc link you cite is for "latest" and doesn't exist under
https://docs.openstack.org/neutron/queens/admin/index.html
** 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/1875847
Title:
Neutron api not coming up with mod_wsgi
Status in neutron:
Invalid
Bug description:
I started the neutron api with apache with mod_wsgi approach mentioned in the
below document:
https://docs.openstack.org/neutron/latest/admin/config-wsgi.html
I have /etc/httpd/conf.d/wsgi-neutron.conf defined as below:
Listen :9696
Require all granted
:9696>
WSGIProcessGroup neutron-server
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
WSGIDaemonProcess neutron-server processes=8 threads=1 user=neutron
group=neutron
WSGIScriptAlias / /usr/bin/neutron-api
= 2.4>
ErrorLogFormat "%M"
ErrorLog /var/log/neutron/neutron-server.log
Alias /networking /usr/bin/neutron-api
SetHandler wsgi-script
Options +ExecCGI
WSGIProcessGroup neutron-server
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
The following traceback occurs in /var/log/neutron/neutron-server.log
when i run any neutron operation with openstack client:
2020-04-28 09:34:11.356 23 INFO neutron.common.config
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] Logging enabled!
2020-04-28 09:34:11.356 23 INFO neutron.common.config
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] mod_wsgi version 12.1.0
2020-04-28 09:34:11.356 23 DEBUG neutron.common.config
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] command line: mod_wsgi
setup_logging /usr/lib/python2.7/site-packages/neutron/common/config.py:104
2020-04-28 09:34:11.357 23 DEBUG oslo.service.wsgi
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] Loading app neutron from
/usr/share/neutron/api-paste.ini load_app
/usr/lib/python2.7/site-packages/oslo_service/wsgi.py:352
2020-04-28 09:34:11.362 23 ERROR neutron.api.extensions
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] Unable to process
extensions (l3-flavors) because the configured plugins do not satisfy their
requirements. Some features will not work as expected.
mod_wsgi (pid=23): Target WSGI script '/usr/bin/neutron-api' cannot be loaded
as Python module.
mod_wsgi (pid=23): Exception occurred processing WSGI script
'/usr/bin/neutron-api'.
Traceback (most recent call last):
File "/usr/bin/neutron-api", line 54, in
application = get_application()
File "/usr/lib/python2.7/site-packages/neutron/server/__init__.py", line
52, in get_application
return config.load_paste_app('neutron')
File "/usr/lib/python2.7/site-packages/neutron/common/config.py", line 122,
in load_paste_app
app = loader.load_app(app_name)
File "/usr/lib/python2.7/site-packages/oslo_service/wsgi.py", line 353, in
load_app
return deploy.loadapp("config:%s" % self.config_path, name=name)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 247,
in loadapp
return loadobj(APP, uri, name=name, **kw)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 272,
in loadobj
return context.create()
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710,
in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 144,
in invoke
**context.local_conf)
File "/usr/lib/python2.7/site-packages/paste/deploy/util.py", line 55, in
fix_call
val = callable(*args, **kw)
File "/usr/lib/python2.7/site-packages/paste/urlmap.py", line 25, in
urlmap_factory
app = loader.get_app(app_name, global_conf=global_conf)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 350,
in get_app
name=name, global_conf=global_conf).create()
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710,
in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 144,
in invoke
**context.local_conf)
File "/usr/lib/python2.7/site-packages/paste/deploy/util.py", line 55, in
fix_call
val = callable(*args, **kw)
File "/usr/lib/python2.7/site-packages/neutron/auth.py", line 47, in
pipeline_factory
app = loader.get_app(pipeline[-1])
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 350,
in get_app
name=name, global_conf=global_conf).create()
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710,
in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 146,
in invoke
return
[Yahoo-eng-team] [Bug 1875814] Re: libvirt：instance binding core failed.
I don't see any connection with Nova. You are using libvirt to manage your VMs so this cannot be a nova bug. I suggests to re-target the bug to libvirt project. ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1875814 Title: libvirt：instance binding core failed. Status in OpenStack Compute (nova): Invalid Bug description: Description === instance binding core failed. Steps to reproduce == 1.The host is 64 cores and three virtual machines are set up, one of which is bound to the core. 'virsh vcpupin 1 0 0-1 --live --config' 2.uname -a : Linux infra06 4.4.131-20190726.kylin.server-generic #kylin SMP Tue Jul 30 16:44:09 CST 2019 aarch64 aarch64 aarch64 GNU/Linux 3.virsh -version :4.0.0 Logs & Configs == 1.Return error report in the attachment. 2.Libvirt:error : virProcessSetAffinity:464 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1875814/+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 1875865] [NEW] SRIOV OVN metadata namespaces not cleaned up after ports are unbounded
Public bug reported: Description of problem: See 'Steps to Reproduce' below. The external port is deleted from the port_binding table instead of chassis removed and then deleted so the PortBindingUpdate event is never generated. The metadata agent reacts on Port Binding Update event only. That means when there is a VM and we delete it, it first calls port update to remove the chassis from the port binding, so the port binding is chassis=[] before the PB gets deleted. In SRIOV scenario we don't do that and we delete a port that is bound. We need a special event for the sriov deletion case. Steps to Reproduce: 1. create an SRIOV port on either a tenant or a prov network + create a VM attached to that port - check ovn metadata namespace has been created on a GW node 2. remove that VM - the ovn metadata namespace is not removed from that GW node 3. even after removing the port, the namespace is not removed Actual results: OVN metadata namespaces clean up mechanism not working with SRIOV ports Expected results: Namespaces should be removed after port is removed ** Affects: neutron Importance: Undecided Assignee: Jakub Libosvar (libosvar) Status: New ** Tags: ovn -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1875865 Title: SRIOV OVN metadata namespaces not cleaned up after ports are unbounded Status in neutron: New Bug description: Description of problem: See 'Steps to Reproduce' below. The external port is deleted from the port_binding table instead of chassis removed and then deleted so the PortBindingUpdate event is never generated. The metadata agent reacts on Port Binding Update event only. That means when there is a VM and we delete it, it first calls port update to remove the chassis from the port binding, so the port binding is chassis=[] before the PB gets deleted. In SRIOV scenario we don't do that and we delete a port that is bound. We need a special event for the sriov deletion case. Steps to Reproduce: 1. create an SRIOV port on either a tenant or a prov network + create a VM attached to that port - check ovn metadata namespace has been created on a GW node 2. remove that VM - the ovn metadata namespace is not removed from that GW node 3. even after removing the port, the namespace is not removed Actual results: OVN metadata namespaces clean up mechanism not working with SRIOV ports Expected results: Namespaces should be removed after port is removed To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1875865/+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 1841363] Re: nova cannot attach volume whose source_type='block' when setting disk_cache_modes as writethrough or writeback
Reviewed: https://review.opendev.org/682772 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=af2405e1181d70cdf60bcd0e40b3e80f2db2e3a6 Submitter: Zuul Branch:master commit af2405e1181d70cdf60bcd0e40b3e80f2db2e3a6 Author: Arthur Dayne Date: Tue Sep 17 19:08:59 2019 +0800 libvirt:driver:Disallow AIO=native when 'O_DIRECT' is not available Because of the libvirt issue[1], there is a bug[2] that if we set cache mode whose write semantic is not O_DIRECT (.i.e unsafe, writeback or writethrough), there will be a problem with the volume drivers (.i.e nova.virt.libvirt.volume.LibvirtISCSIVolumeDriver, nova.virt.libvirt.volume.LibvirtNFSVolumeDriver and so on), which designate native io explicitly. That problem will generate a libvirt xml for the instance, whose content contains ``` ... ... ``` In turn, it will fail to start the instance or attach the disk. > When qemu is configured with a block device that has aio=native set, but > the cache mode doesn't use O_DIRECT (i.e. isn't cache=none/directsync or any > unnamed mode with explicit cache.direct=on), then the raw-posix block driver > for local files and block devices will silently fall back to aio=threads. > The blockdev-add interface rejects such combinations, but qemu can't > change the existing legacy interfaces that libvirt uses today. [1]: https://github.com/libvirt/libvirt/commit/058384003db776c580d0e5a3016a6384e8eb7b92 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1086704 Closes-Bug: #1841363 Change-Id: If9acc054100a6733f3659a15dd9fc2d462e84d64 ** Changed in: nova Status: In Progress => Fix Released ** Bug watch added: Red Hat Bugzilla #1086704 https://bugzilla.redhat.com/show_bug.cgi?id=1086704 -- 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/1841363 Title: nova cannot attach volume whose source_type='block' when setting disk_cache_modes as writethrough or writeback Status in OpenStack Compute (nova): Fix Released Bug description: Wheh nova.conf is set as ... [libvirt] ... disk_cachemodes = block=writethrough ... OR [libvirt] ... disk_cachemodes = block=writeback ... Nova cannot attache volume whose source_type is 'block', because of a libvirt issue: https://bugzilla.redhat.com/show_bug.cgi?id=1086704 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1841363/+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 1875344] Re: Cleanup in neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON may fail in dvr deployments
Reviewed: https://review.opendev.org/723387
Committed:
https://git.openstack.org/cgit/openstack/neutron-tempest-plugin/commit/?id=03700aa12b4e22552f8626ffb9d5261d7a7c44c8
Submitter: Zuul
Branch:master
commit 03700aa12b4e22552f8626ffb9d5261d7a7c44c8
Author: Slawek Kaplonski
Date: Mon Apr 27 13:31:01 2020 +0200
Ensure that external network don't have any ports before deletion
In module
neutron_tempest_plugin.api.admin.test_external_network_extension
we need to ensure that there is no any leftover ports, like e.g.
floatingip_agent_gateway port before network deletion.
Closes-bug: #1875344
Change-Id: I8226e999d9ec8e521b39ab915aaa503425174987
** 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/1875344
Title:
Cleanup in
neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON
may fail in dvr deployments
Status in neutron:
Fix Released
Bug description:
I saw it couple of times in our d/s testing job with DVR enabled that
test
neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net
was failing in cleanup phase.
Error was like
ft4.1: tearDownClass
(neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON)testtools.testresult.real._StringException:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/tempest/test.py", line 242, in
tearDownClass
six.reraise(etype, value, trace)
File "/usr/lib/python3.6/site-packages/six.py", line 675, in reraise
raise value
File "/usr/lib/python3.6/site-packages/tempest/test.py", line 214, in
tearDownClass
teardown()
File "/usr/lib/python3.6/site-packages/neutron_tempest_plugin/api/base.py",
line 196, in resource_cleanup
subnet['id'])
File "/usr/lib/python3.6/site-packages/neutron_tempest_plugin/api/base.py",
line 281, in _try_delete_resource
delete_callable(*args, **kwargs)
File
"/usr/lib/python3.6/site-packages/neutron_tempest_plugin/services/network/json/network_client.py",
line 112, in _delete
resp, body = self.delete(uri)
File "/usr/lib/python3.6/site-packages/tempest/lib/common/rest_client.py",
line 314, in delete
return self.request('DELETE', url, extra_headers, headers, body)
File "/usr/lib/python3.6/site-packages/tempest/lib/common/rest_client.py",
line 687, in request
self._error_checker(resp, resp_body)
File "/usr/lib/python3.6/site-packages/tempest/lib/common/rest_client.py",
line 808, in _error_checker
raise exceptions.Conflict(resp_body, resp=resp)
tempest.lib.exceptions.Conflict: Conflict with state of target resource
Details: {'type': 'SubnetInUse', 'message': 'Unable to complete operation on
subnet 7f774581-bb05-4c71-ac4e-1a338c1e3fa1: One or more ports have an IP
allocation from this subnet.', 'detail': ''}
The issue is that in the dvr deployment, when router with external
network is created, Neutron creates in the background floatingip
gateway port. And as test is performing fast it may happen that this
port is created after router is already deleted so it's not cleaned
properly and causes failure during network removal.
We didn't saw it in u/s CI as we don't have any dvr based job which
would run neutron_tempest_plugin.api tests.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1875344/+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 1875852] [NEW] [OVN] SRIOV routing on VLAN Tenant networks
Public bug reported: Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1826364 Right now, the SRIOV support with ML2/OVN is limited to: 1) SRIOV ports on provider networks with external DHCP 2) SRIOV ports on provider networks with OVN DHCP and OVN Metadata service 3) SRIOV ports on VLAN tenant networks and E/W Neutron routing This BZ is to track the implementation of a 4th scenario that covers: 4) SRIOV ports on VLAN tenant networks and N/S Neutron routing with and without FIPs There are two ways of achieving this (possibly more) but let me explain why it doesn't work right now. SRIOV ports are mapped into OVN 'external' ports that are all scheduled into one controller (or network node). Example: CH1: compute node where SRIOV VM1 (192.168.1.10 - FIP: 10.0.0.10) is running CH2: chassis where OVN external port is bound to CH3: chassis where gateway port is bound to CH4: chassis on the provider network - external PING from CH4 to VM1: CH4 -> CH3 -> CH2 -> CH1 When an external node CH4 pings the FIP of the VM, the traffic will go to CH3 which will perform the NAT and route the traffic to CH1 which will send it to the SRIOV NIC at CH1. As the ICMP request is delivered to the VM, the VM will try to resolve the router interface IP (e.g 192.168.1.1) and will send an ARP broadcast request on the VLAN tenant network. Right now, this ARP packet will be unanswered because: * There are flows to drop the ARP packet from the external port VM for the router IP on all chassis except the chassis claiming the external port, so ideally CH2 would reply. However, * Router ports have the 'reside-on-redirect-chassis' that will make the VLAN traffic centralized [0], meaning that only the chassis hosting the gateway port (CH3 in our example) would reply to it. In this context we have two possibilities to get this working: 1) Co-locating external and gateway ports. This is non trivial as it may require moving things around that would cause dataplane disruption. For example: when the external port is first created, it'll be scheduled on CH1 (no gateways involved yet). However, if the network that it belongs to is later attached to a router with a gateway, it may require moving the external port to achieve that co-location with the gateway port. Moving the external port can create disruption as DHCP/metadata will be unavailable for a certain window of time until everything settles. This time window is unknown and clearly depends on factors such as how many ports need to be moved. In this scenario, the packet flow in the example above would go this way: Echo request: CH4 -> CH3 (gateway & external port) -> CH1 Echo reply: CH1 -> CH3 (gateway & external port) -> CH4 2) Supporting distributed traffic on VLAN tenant networks: Tracked here [1] In this case, there's no need to co-locate things as routing can happen automatically where the external port is bound. This eliminates the burden explained at 1). Option number 2) seems the more reasonable and efficient way of achieving N/S routing for SRIOV ports on ML2/OVN. Hence I'm marking this bug as dependent on [1] and TestOnly for validation. [0] https://opendev.org/openstack/networking-ovn/src/tag/7.1.0/networking_ovn/common/ovn_client.py#L1406 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1766930 ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: ovn rfe ** Changed in: neutron Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1875852 Title: [OVN] SRIOV routing on VLAN Tenant networks Status in neutron: Confirmed Bug description: Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1826364 Right now, the SRIOV support with ML2/OVN is limited to: 1) SRIOV ports on provider networks with external DHCP 2) SRIOV ports on provider networks with OVN DHCP and OVN Metadata service 3) SRIOV ports on VLAN tenant networks and E/W Neutron routing This BZ is to track the implementation of a 4th scenario that covers: 4) SRIOV ports on VLAN tenant networks and N/S Neutron routing with and without FIPs There are two ways of achieving this (possibly more) but let me explain why it doesn't work right now. SRIOV ports are mapped into OVN 'external' ports that are all scheduled into one controller (or network node). Example: CH1: compute node where SRIOV VM1 (192.168.1.10 - FIP: 10.0.0.10) is running CH2: chassis where OVN external port is bound to CH3: chassis where gateway port is bound to CH4: chassis on the provider network - external PING from CH4 to VM1: CH4 -> CH3 -> CH2 -> CH1 When an external node CH4 pings the FIP of the VM, the traffic will go to CH3 which will perform the NAT and route the traffic to CH1 which will send it to the SRIOV NIC at CH1. As the ICMP request is delivered to
[Yahoo-eng-team] [Bug 1875849] [NEW] not ensure default security group exists when filter by project_id
Public bug reported: when we filter security groups by 'tenant_id', neutron will ensure this project has default security group. when we filter by 'project_id', neutron not ensure this project has default security group. if it is new project, filter by 'tenant_id' will return one security group. filter by 'project_id' will return empty list. ** Affects: neutron Importance: Medium Assignee: ZhouHeng (zhouhenglc) Status: In Progress ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1875849 Title: not ensure default security group exists when filter by project_id Status in neutron: In Progress Bug description: when we filter security groups by 'tenant_id', neutron will ensure this project has default security group. when we filter by 'project_id', neutron not ensure this project has default security group. if it is new project, filter by 'tenant_id' will return one security group. filter by 'project_id' will return empty list. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1875849/+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 1875847] [NEW] Neutron api not coming up with mod_wsgi
Public bug reported:
I started the neutron api with apache with mod_wsgi approach mentioned in the
below document:
https://docs.openstack.org/neutron/latest/admin/config-wsgi.html
I have /etc/httpd/conf.d/wsgi-neutron.conf defined as below:
Listen :9696
Require all granted
:9696>
WSGIProcessGroup neutron-server
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
WSGIDaemonProcess neutron-server processes=8 threads=1 user=neutron
group=neutron
WSGIScriptAlias / /usr/bin/neutron-api
= 2.4>
ErrorLogFormat "%M"
ErrorLog /var/log/neutron/neutron-server.log
Alias /networking /usr/bin/neutron-api
SetHandler wsgi-script
Options +ExecCGI
WSGIProcessGroup neutron-server
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
The following traceback occurs in /var/log/neutron/neutron-server.log
when i run any neutron operation with openstack client:
2020-04-28 09:34:11.356 23 INFO neutron.common.config
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] Logging enabled!
2020-04-28 09:34:11.356 23 INFO neutron.common.config
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] mod_wsgi version 12.1.0
2020-04-28 09:34:11.356 23 DEBUG neutron.common.config
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] command line: mod_wsgi
setup_logging /usr/lib/python2.7/site-packages/neutron/common/config.py:104
2020-04-28 09:34:11.357 23 DEBUG oslo.service.wsgi
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] Loading app neutron from
/usr/share/neutron/api-paste.ini load_app
/usr/lib/python2.7/site-packages/oslo_service/wsgi.py:352
2020-04-28 09:34:11.362 23 ERROR neutron.api.extensions
[req-e8519f3d-d7f6-481c-9e71-493028f1b08a - - - - -] Unable to process
extensions (l3-flavors) because the configured plugins do not satisfy their
requirements. Some features will not work as expected.
mod_wsgi (pid=23): Target WSGI script '/usr/bin/neutron-api' cannot be loaded
as Python module.
mod_wsgi (pid=23): Exception occurred processing WSGI script
'/usr/bin/neutron-api'.
Traceback (most recent call last):
File "/usr/bin/neutron-api", line 54, in
application = get_application()
File "/usr/lib/python2.7/site-packages/neutron/server/__init__.py", line 52,
in get_application
return config.load_paste_app('neutron')
File "/usr/lib/python2.7/site-packages/neutron/common/config.py", line 122,
in load_paste_app
app = loader.load_app(app_name)
File "/usr/lib/python2.7/site-packages/oslo_service/wsgi.py", line 353, in
load_app
return deploy.loadapp("config:%s" % self.config_path, name=name)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 247,
in loadapp
return loadobj(APP, uri, name=name, **kw)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 272,
in loadobj
return context.create()
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710,
in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 144,
in invoke
**context.local_conf)
File "/usr/lib/python2.7/site-packages/paste/deploy/util.py", line 55, in
fix_call
val = callable(*args, **kw)
File "/usr/lib/python2.7/site-packages/paste/urlmap.py", line 25, in
urlmap_factory
app = loader.get_app(app_name, global_conf=global_conf)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 350,
in get_app
name=name, global_conf=global_conf).create()
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710,
in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 144,
in invoke
**context.local_conf)
File "/usr/lib/python2.7/site-packages/paste/deploy/util.py", line 55, in
fix_call
val = callable(*args, **kw)
File "/usr/lib/python2.7/site-packages/neutron/auth.py", line 47, in
pipeline_factory
app = loader.get_app(pipeline[-1])
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 350,
in get_app
name=name, global_conf=global_conf).create()
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710,
in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 146,
in invoke
return fix_call(context.object, context.global_conf, **context.local_conf)
File "/usr/lib/python2.7/site-packages/paste/deploy/util.py", line 55, in
fix_call
val = callable(*args, **kw)
File "/usr/lib/python2.7/site-packages/neutron/api/v2/router.py", line 25, in
_factory
return pecan_app.v2_factory(global_config, **local_config)
File "/usr/lib/python2.7/site-packages/neutron/pecan_wsgi/app.py", line 47,
in v2_factory
startup.initialize_all()
File "/usr/lib/python2.7/site-packages/neutron/pecan_wsgi/startup.py", line
41, in initialize_all
ext_mgr.extend_resources("2.0", attributes.RESOURCE_ATTRIBUTE_MAP)
File
[Yahoo-eng-team] [Bug 1875814] [NEW] libvirt：instance binding core failed.
Public bug reported: Description === instance binding core failed. Steps to reproduce == 1.The host is 64 cores and three virtual machines are set up, one of which is bound to the core. 'virsh vcpupin 1 0 0-1 --live --config' 2.uname -a : Linux infra06 4.4.131-20190726.kylin.server-generic #kylin SMP Tue Jul 30 16:44:09 CST 2019 aarch64 aarch64 aarch64 GNU/Linux 3.virsh -version :4.0.0 Logs & Configs == 1.Return error report in the attachment. 2.Libvirt:error : virProcessSetAffinity:464 ** Affects: nova Importance: Undecided Status: New ** Attachment added: "Execute the bind kernel command to return an error message." https://bugs.launchpad.net/bugs/1875814/+attachment/5363256/+files/log.png -- 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/1875814 Title: libvirt：instance binding core failed. Status in OpenStack Compute (nova): New Bug description: Description === instance binding core failed. Steps to reproduce == 1.The host is 64 cores and three virtual machines are set up, one of which is bound to the core. 'virsh vcpupin 1 0 0-1 --live --config' 2.uname -a : Linux infra06 4.4.131-20190726.kylin.server-generic #kylin SMP Tue Jul 30 16:44:09 CST 2019 aarch64 aarch64 aarch64 GNU/Linux 3.virsh -version :4.0.0 Logs & Configs == 1.Return error report in the attachment. 2.Libvirt:error : virProcessSetAffinity:464 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1875814/+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
