[Yahoo-eng-team] [Bug 1759473] Re: Avoid InstanceNotRunning reporting
Reviewed: https://review.opendev.org/541152 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ad78f24812df8e83c188b100d05b1c5a577c8f84 Submitter: Zuul Branch:master commit ad78f24812df8e83c188b100d05b1c5a577c8f84 Author: jichenjc Date: Fri Feb 2 21:29:02 2018 +0800 Avoid raise InstanceNotRunning exception when instance is being snapshot, it's possible that the instance is deleted by another thread concurrently, libvirt driver translate this InstanceNotFound exception into InstanceNotRunning and we didn't catch and handle the exception and it leads to backtrace in compute log. Also, fixes to catch the Exception and return a debug info as the instance is anyway deleted already. Change-Id: Ic6d0ac894fbbbf03fe967ee4f9ec93b2491cf073 Closes-Bug: 1759473 ** Changed in: nova Status: In Progress => Fix Released -- 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/1759473 Title: Avoid InstanceNotRunning reporting Status in OpenStack Compute (nova): Fix Released Bug description: This is found during bug analysis 1737024 and discussion on https://review.openstack.org/#/c/541152/ and it turn out InstanceNotRunning is not handled in current implementation and can lead to potential back trace so better to handle it To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1759473/+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 1853651] [NEW] Horizon Install Guide - missing 'WEBROOT' directive in horizon config file
Public bug reported: 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: By following the instructions to setup the /etc/openstack- dashboard/local_settings configuration file on CentOS 7, I received a "Not Found" error when attempting to load horizon at /dashboard in a browser. It appears horizon tries to re- direct to a URL outside of the /dashboard URL, causing the 404. This is due to not having a "WEBROOT" setting in the file. By adding the following to the config file (and restarting httpd), the horizon dashboard then loads without issue: WEBROOT = '/dashboard' My apologies if this is the incorrect place to request this documentation addition. Thanks! 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: on 2019-04-11 17:44:22 SHA: fd9839a0768842308b3f9ecabafc04b120453994 Source: https://opendev.org/openstack/horizon/src/doc/source/install/install-rdo.rst URL: https://docs.openstack.org/horizon/train/install/install-rdo.html ** Affects: horizon Importance: Undecided Status: New ** Tags: documentation -- 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/1853651 Title: Horizon Install Guide - missing 'WEBROOT' directive in horizon config file Status in OpenStack Dashboard (Horizon): New 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: By following the instructions to setup the /etc/openstack- dashboard/local_settings configuration file on CentOS 7, I received a "Not Found" error when attempting to load horizon at /dashboard in a browser. It appears horizon tries to re-direct to a URL outside of the /dashboard URL, causing the 404. This is due to not having a "WEBROOT" setting in the file. By adding the following to the config file (and restarting httpd), the horizon dashboard then loads without issue: WEBROOT = '/dashboard' My apologies if this is the incorrect place to request this documentation addition. Thanks! 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: on 2019-04-11 17:44:22 SHA: fd9839a0768842308b3f9ecabafc04b120453994 Source: https://opendev.org/openstack/horizon/src/doc/source/install/install-rdo.rst URL: https://docs.openstack.org/horizon/train/install/install-rdo.html To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1853651/+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 1753676] Re: Live migration not working as Expected when Restarting nova-compute service while migration from source node
Reviewed: https://review.opendev.org/678016 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ebcf6e4ce576285949c5a202f2d7d21dc03156ef Submitter: Zuul Branch:master commit ebcf6e4ce576285949c5a202f2d7d21dc03156ef Author: Alexandre Arents Date: Tue Aug 20 13:37:33 2019 + Abort live-migration during instance_init When compute service restart during a live-migration, we lose live-migration monitoring thread. In that case it is better to early abort live-migration job before resetting state of instance, this will avoid API to accept further action while unmanaged migration process still run in background. It also avoid unexpected/dangerous behavior as describe in related bug. Change-Id: Idec2d31cbba497dc4b20912f3388ad2341951d23 Closes-Bug: #1753676 ** Changed in: nova Status: In Progress => Fix Released -- 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/1753676 Title: Live migration not working as Expected when Restarting nova-compute service while migration from source node Status in OpenStack Compute (nova): Fix Released Bug description: Description === Environment: Ubuntu 16.04 Openstack Version: Pike I am trying to migrate VM ( live migration ( block migration ) ) form one compute node to another compute node...Everything looks good unless I restart nova-compute service, live migration still running underneath with help of libvirt, once the vm reaches destination, database is not updated properly. Steps to reproduce: === nova.conf ( libvirt setting on both compute nodes ) [libvirt] live_migration_bandwidth=1200 live_migration_downtime=100 live_migration_downtime_steps =3 live_migration_downtime_delay=10 live_migration_flag = VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE virt_type = kvm inject_password = False disk_cachemodes = network=writeback live_migration_uri = "qemu+tcp://nova@%s/system" live_migration_tunnelled = False block_migration_flag = VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_NON_SHARED_INC ( default openstack live migration configuration ( pre-copy with no tunneling ) Source vm root disk ( boot from volume with one ephemernal disk (160GB) ) Trying to migrate vm from compute1 to compute2, below is my source vm. | OS-EXT-SRV-ATTR:host | compute1 | | OS-EXT-SRV-ATTR:hostname | testcase1-all-ephemernal-boot-from-vol | | OS-EXT-SRV-ATTR:hypervisor_hostname | compute1 | | OS-EXT-SRV-ATTR:instance_name| instance-0153 1) nova live-migration --block-migrate compute2 [req-48a3df61-3974-46ac-8019-c4c4a0f8a8c8 4a8150eb246a4450829331e993f8c3fd f11a5d3631f14c4f879a2e7dddb96c06 - default default] pre_live_migration data is LibvirtLiveMigrateData(bdms=,block_migration=True,disk_available_mb=6900736,disk_over_commit=,filename='tmpW5ApOS',graphics_listen_addr_spice=x.x.x.x,graphics_listen_addr_vnc=127.0.0.1,image_type='default',instance_relative_path='504028fc-1381 -42ca-ad7c- def7f749a722',is_shared_block_storage=False,is_shared_instance_path=False,is_volume_backed=True,migration=,serial_listen_addr=None,serial_listen_ports=,supported_perf_events=,target_connect_addr=) pre_live_migration /openstack/venvs/nova-16.0.6/lib/python2.7/site- packages/nova/compute/manager.py:5437 Migration started, able to see the data and memory transfer ( using iftop ) Data transfer between compute nodes using iftop <= 4.94Gb 4.99Gb 5.01Gb Restarted Nova-compute service on source compute node ( where the vm is migrating) Live migration still it is going, once migration completes, below is my total data transfer ( using iftop ) TX: cum: 17.3MB peak: 2.50Mb rates: 11.1Kb 7.11Kb 463Kb RX:97.7GB 4.97Gb 3.82Kb 1.93Kb 1.87Gb TOTAL: 97.7GB 4.97Gb Once migration completes, from the destination compute node ( we can able to see the virsh domain running) root@compute2:~# virsh list --all IdName State 3 instance-0153
[Yahoo-eng-team] [Bug 1853637] [NEW] Assign floating IP to port owned by another tenant is not override-able with RBAC policy
Public bug reported:
In neutron/db/l3_db.py:
def _internal_fip_assoc_data(self, context, fip, tenant_id):
"""Retrieve internal port data for floating IP.
Retrieve information concerning the internal port where
the floating IP should be associated to.
"""
internal_port = self._core_plugin.get_port(context, fip['port_id'])
if internal_port['tenant_id'] != tenant_id and not context.is_admin:
port_id = fip['port_id']
msg = (_('Cannot process floating IP association with '
'Port %s, since that port is owned by a '
'different tenant') % port_id)
raise n_exc.BadRequest(resource='floatingip', msg=msg)
This code does not allow operators to override the ability to assign
floating IPs to ports on another tenant using RBAC policy. It also does
not allow members of the advsvc role to take this action.
This code should be fixed to use the standard neutron RBAC and allow the
advsvc role to take this action.
** 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/1853637
Title:
Assign floating IP to port owned by another tenant is not override-
able with RBAC policy
Status in neutron:
New
Bug description:
In neutron/db/l3_db.py:
def _internal_fip_assoc_data(self, context, fip, tenant_id):
"""Retrieve internal port data for floating IP.
Retrieve information concerning the internal port where
the floating IP should be associated to.
"""
internal_port = self._core_plugin.get_port(context, fip['port_id'])
if internal_port['tenant_id'] != tenant_id and not context.is_admin:
port_id = fip['port_id']
msg = (_('Cannot process floating IP association with '
'Port %s, since that port is owned by a '
'different tenant') % port_id)
raise n_exc.BadRequest(resource='floatingip', msg=msg)
This code does not allow operators to override the ability to assign
floating IPs to ports on another tenant using RBAC policy. It also
does not allow members of the advsvc role to take this action.
This code should be fixed to use the standard neutron RBAC and allow
the advsvc role to take this action.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1853637/+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 1840638] Re: network/subnet resources cannot be read and written separated
Reviewed: https://review.opendev.org/677166 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4afba466e04fb74c8915f9f1b40686008b2503fb Submitter: Zuul Branch:master commit 4afba466e04fb74c8915f9f1b40686008b2503fb Author: zhanghao Date: Sun Nov 17 20:17:35 2019 -0500 Make network support read and write separation When 'slave_connection' is configured in neutron.conf, executing the 'neutron port-show' command will read the port information from the slave database nodes, but the network will not be able to read the information from the slave database nodes. Change-Id: I572cecace1016740584757e5f926d246ead2d9a0 Closes-Bug: #1840638 ** 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/1840638 Title: network/subnet resources cannot be read and written separated Status in neutron: Fix Released Bug description: openstack environment: 1 controller 1 compute(install mariadb) neutron.conf [database] connection = mysql+pymysql://neutron:***@controller/neutron slave_connection = mysql+pymysql://neutron: ***@compute/neutron create network(name=net10)、subnet(name=subnet10)、port(name=port01) in controller node. sync controller node database to compute node. update network.name=test_net10、subnet.name=test_subnet10、port.name=test_port01 in compute node database. neutron port-show PORT_ID name:test_port01 neutron net-show NET_ID name:net10 neutron subnet-show SUBNET_ID name:subnet10 When slave_connection is configured in neutron.conf, executing the 'neutron port-show' command will read the port information from the slave database nodes, but the network/subnet will not be able to read the information from the slave database nodes. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1840638/+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 1853632] [NEW] designate dns driver does not use domain settings for auth
Public bug reported: The designate external dns driver does not use domain settings for authentication **if** there is more than one openstack domain. If you have only the 'Default' domain the authentication system seems to have no doubt on which domain to use so it will use that. In our deployment we support federated authentication and we have this issue. The issue lies in the external dns driver as it also does not support all of the documented options. You can test this by setting invalid one of (or all): user_domain_name project_domain_name project_name it should yield the same results. @oammis initially found this issue, so credit where it's due. We have a Queens deployment, although by what we can see from the code it should be transverse to all releases. I'll post a fix soon. ** 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/1853632 Title: designate dns driver does not use domain settings for auth Status in neutron: New Bug description: The designate external dns driver does not use domain settings for authentication **if** there is more than one openstack domain. If you have only the 'Default' domain the authentication system seems to have no doubt on which domain to use so it will use that. In our deployment we support federated authentication and we have this issue. The issue lies in the external dns driver as it also does not support all of the documented options. You can test this by setting invalid one of (or all): user_domain_name project_domain_name project_name it should yield the same results. @oammis initially found this issue, so credit where it's due. We have a Queens deployment, although by what we can see from the code it should be transverse to all releases. I'll post a fix soon. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1853632/+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 1853635] [NEW] Config_drive file throws Request is too large
Public bug reported: Openstack Version: QUEENS I am trying to instantiate VM with config-drive option with two files config1.xml(size 200KB) and config2.xml(100KB). openstack server create config-drive=true --file config1.xml=config1.xml -flavor m1.tiny --image cirros instance creation was failed with error "OverLimit: Request is too large" My Quota is already with 50 nova quota-show command output: injected_file_content_bytes | 50 | Even I have updated the following in nova.conf injected_file_content_bytes = 50 Any suggestion is highly appreciated. ** 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/1853635 Title: Config_drive file throws Request is too large Status in OpenStack Compute (nova): New Bug description: Openstack Version: QUEENS I am trying to instantiate VM with config-drive option with two files config1.xml(size 200KB) and config2.xml(100KB). openstack server create config-drive=true --file config1.xml=config1.xml -flavor m1.tiny --image cirros instance creation was failed with error "OverLimit: Request is too large" My Quota is already with 50 nova quota-show command output: injected_file_content_bytes | 50 | Even I have updated the following in nova.conf injected_file_content_bytes = 50 Any suggestion is highly appreciated. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1853635/+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 1853613] [NEW] VMs don't get ip from dhcp after compute restart
Public bug reported: Env: pike + ovs + vxlan + l2pop + iptables_hybrid. Dhcp agent on differnt node than compute. Steps: 1. Boot 4 or more vms to same compute and same vxlan net. 2. Wait until they are fully running and reboot compute node. 3. After boot the vms are in status SHUTOFF. Start the vms. Vms don't get an ip address from neutron dhcp. The flood to tunnels flow (br-tun table 22) for the network is missing, so broadcasts like dhcp requests don't get on a tunnel to the node with dhcp agent. Neutron server did not send the flooding entry to the agent. It only does that for the first or second active port, or if the agent is restarted. After the compute boots, neutron-ovs-cleanup runs first and deletes the qvo ports from br-int [4]. Then the ovs-agent starts and nova-compute after it. Nova-compute destroys the domains and moves the vms to SHUTOFF status. It also (for some reason) recreates the qbr linux bridges and qvb/qvo veths connected to br-int. So neutron continues to see the ports as ACTIVE even though the vms are SHUTOFF, and agent_active_ports [1] never drops below 3. Also nova-compute might start a short time after the ovs-agent and the new ports are not detected in first iteration of the ovs agent loop, so agent_restarted will be false here [2]. Before [3] agent_restarted was true if the agent was running for less than agent_boot_time (default 180 sec) and the problem did not show. It does not happen if neutron-ovs-cleanup is disabled. Then the ovs agent first treats them as skipped_devices and they get status DOWN. [1] https://github.com/openstack/neutron/blob/21a52f7ae597f7992f32ff41cedff0c31e35c762/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L306 [2] https://github.com/openstack/neutron/blob/21a52f7ae597f7992f32ff41cedff0c31e35c762/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L310 [3] https://opendev.org/openstack/neutron/commit/62fe7852bbd70a24174853997096c52ee015e269 [4] https://bugs.launchpad.net/neutron/+bug/1853582 ** Affects: neutron Importance: Undecided Status: New ** Tags: l2-pop ovs ** Tags added: l2-pop ovs -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1853613 Title: VMs don't get ip from dhcp after compute restart Status in neutron: New Bug description: Env: pike + ovs + vxlan + l2pop + iptables_hybrid. Dhcp agent on differnt node than compute. Steps: 1. Boot 4 or more vms to same compute and same vxlan net. 2. Wait until they are fully running and reboot compute node. 3. After boot the vms are in status SHUTOFF. Start the vms. Vms don't get an ip address from neutron dhcp. The flood to tunnels flow (br-tun table 22) for the network is missing, so broadcasts like dhcp requests don't get on a tunnel to the node with dhcp agent. Neutron server did not send the flooding entry to the agent. It only does that for the first or second active port, or if the agent is restarted. After the compute boots, neutron-ovs-cleanup runs first and deletes the qvo ports from br-int [4]. Then the ovs-agent starts and nova- compute after it. Nova-compute destroys the domains and moves the vms to SHUTOFF status. It also (for some reason) recreates the qbr linux bridges and qvb/qvo veths connected to br-int. So neutron continues to see the ports as ACTIVE even though the vms are SHUTOFF, and agent_active_ports [1] never drops below 3. Also nova-compute might start a short time after the ovs-agent and the new ports are not detected in first iteration of the ovs agent loop, so agent_restarted will be false here [2]. Before [3] agent_restarted was true if the agent was running for less than agent_boot_time (default 180 sec) and the problem did not show. It does not happen if neutron-ovs-cleanup is disabled. Then the ovs agent first treats them as skipped_devices and they get status DOWN. [1] https://github.com/openstack/neutron/blob/21a52f7ae597f7992f32ff41cedff0c31e35c762/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L306 [2] https://github.com/openstack/neutron/blob/21a52f7ae597f7992f32ff41cedff0c31e35c762/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L310 [3] https://opendev.org/openstack/neutron/commit/62fe7852bbd70a24174853997096c52ee015e269 [4] https://bugs.launchpad.net/neutron/+bug/1853582 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1853613/+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 1853603] [NEW] SG rules not enforced
Public bug reported: We see this in kuryr-kubernetes and test_namespace_sg_isolation test. More info can be found in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1688323 ** 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/1853603 Title: SG rules not enforced Status in neutron: New Bug description: We see this in kuryr-kubernetes and test_namespace_sg_isolation test. More info can be found in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1688323 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1853603/+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 1853587] [NEW] nova compute fails to update inventory in placement after changing [DEFAULT]/host
Public bug reported: * build a single node devstack (hostname=aio) * when everything up and running change the /etc/nova/nova-cpu.conf [DEFAULT]/host to something else than the compute host hostname * restart the nova-compute service The below exception is periodically visible in the nova-compute logs Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager [None req-46df956c-7a08-4217-a658-e44a1a8edb28 None None] Error updating resources for node aio.: nova.exception.R Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager Traceback (most recent call last): Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/opt/stack/nova/nova/compute/manager.py", line 9152, in _update_available_resource_for_node Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager startup=startup) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/opt/stack/nova/nova/compute/resource_tracker.py", line 844, in update_available_resource Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager self._update_available_resource(context, resources, startup=startup) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/usr/local/lib/python3.6/dist-packages/oslo_concurrency/lockutils.py", line 328, in inner Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager return f(*args, **kwargs) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/opt/stack/nova/nova/compute/resource_tracker.py", line 929, in _update_available_resource Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager self._update(context, cn, startup=startup) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/opt/stack/nova/nova/compute/resource_tracker.py", line 1178, in _update Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager self._update_to_placement(context, compute_node, startup) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/usr/local/lib/python3.6/dist-packages/retrying.py", line 49, in wrapped_f Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager return Retrying(*dargs, **dkw).call(f, *args, **kw) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/usr/local/lib/python3.6/dist-packages/retrying.py", line 206, in call Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager return attempt.get(self._wrap_exception) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/usr/local/lib/python3.6/dist-packages/retrying.py", line 247, in get Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager six.reraise(self.value[0], self.value[1], self.value[2]) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/usr/local/lib/python3.6/dist-packages/six.py", line 696, in reraise Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager raise value Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/usr/local/lib/python3.6/dist-packages/retrying.py", line 200, in call Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager attempt = Attempt(fn(*args, **kwargs), attempt_number, False) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/opt/stack/nova/nova/compute/resource_tracker.py", line 1112, in _update_to_placement Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager context, compute_node.uuid, name=compute_node.hypervisor_hostname) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/opt/stack/nova/nova/scheduler/client/report.py", line 857, in get_provider_tree_and_ensure_root Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager parent_provider_uuid=parent_provider_uuid) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/opt/stack/nova/nova/scheduler/client/report.py", line 644, in _ensure_resource_provider Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager parent_provider_uuid=parent_provider_uuid) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/opt/stack/nova/nova/scheduler/client/report.py", line 72, in wrapper Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager return f(self, *a, **k) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager File "/opt/stack/nova/nova/scheduler/client/report.py", line 574, in _create_resource_provider Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager raise exception.ResourceProviderCreationFailed(name=name) Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager nova.exception.ResourceProviderCreationFailed: Failed to create resource provider aio Nov 22 11:50:52 aio nova-compute[15324]: ERROR nova.compute.manager Problems: Nova fails to
[Yahoo-eng-team] [Bug 1853582] [NEW] ovs cleanup deletes nova ports
Public bug reported:
The help for ovs_all_ports says that when False, only ports that were
created by Neutron are deleted.
https://github.com/openstack/neutron/blob/67b613b795416406fb4fab143b3ec9ba8657711f/neutron/conf/agent/cmd.py#L41-L46
cfg.BoolOpt('ovs_all_ports',
default=False,
help=_('True to delete all ports on all the OpenvSwitch '
'bridges. False to delete ports created by '
'Neutron on integration and external network '
'bridges.'))
But actually ports created by Nova are also deleted. Those also have the
iface-id and attached-mac fields.
https://github.com/openstack/neutron/blob/67b613b795416406fb4fab143b3ec9ba8657711f/neutron/agent/ovsdb/impl_idl.py#L80-L81
# ovs-vsctl --columns=name,external_ids --format=table list Interface
name external_ids
-
...
"qr-868ef235-bb" {attached-mac="fa:16:3e:bb:94:ca",
iface-id="868ef235-bba4-4776-aac9-4b46a9a17def", iface-status=active}
...
"qvof43ccb24-99" {attached-mac="fa:16:3e:70:5c:b0",
iface-id="f43ccb24-999e-4f9d-a9e4-07d11b9e5128", iface-status=active,
vm-uuid="33c6fffa-f58b-4aab-b5ba-9960c1e02004"}
Not sure which is wrong, the help or the script. Is it supposed to delete ports
that were created by nova?
** Affects: neutron
Importance: Undecided
Status: New
** Tags: ovs
** Tags added: ovs
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1853582
Title:
ovs cleanup deletes nova ports
Status in neutron:
New
Bug description:
The help for ovs_all_ports says that when False, only ports that were
created by Neutron are deleted.
https://github.com/openstack/neutron/blob/67b613b795416406fb4fab143b3ec9ba8657711f/neutron/conf/agent/cmd.py#L41-L46
cfg.BoolOpt('ovs_all_ports',
default=False,
help=_('True to delete all ports on all the OpenvSwitch '
'bridges. False to delete ports created by '
'Neutron on integration and external network '
'bridges.'))
But actually ports created by Nova are also deleted. Those also have the
iface-id and attached-mac fields.
https://github.com/openstack/neutron/blob/67b613b795416406fb4fab143b3ec9ba8657711f/neutron/agent/ovsdb/impl_idl.py#L80-L81
# ovs-vsctl --columns=name,external_ids --format=table list Interface
name external_ids
-
...
"qr-868ef235-bb" {attached-mac="fa:16:3e:bb:94:ca",
iface-id="868ef235-bba4-4776-aac9-4b46a9a17def", iface-status=active}
...
"qvof43ccb24-99" {attached-mac="fa:16:3e:70:5c:b0",
iface-id="f43ccb24-999e-4f9d-a9e4-07d11b9e5128", iface-status=active,
vm-uuid="33c6fffa-f58b-4aab-b5ba-9960c1e02004"}
Not sure which is wrong, the help or the script. Is it supposed to delete
ports that were created by nova?
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1853582/+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
