- openstack-discuss - lists.openstack.org

RE: [nova][neutron][kolla]failing to create a vm with SR-IOV (through neutron) - device not found but not listed under libvirt devices
by Manuel Sopena Ballesteros 26 Feb '19

26 Feb '19

I also tried the devices like this, but still getting the same error message passthrough_whitelist = [... {"devname": "ens2f0", "physical_network": "sriovtenant1"}, {"devname": "ens2f1", "physical_network": "sriovtenant1"}] thank you Manuel From: Manuel Sopena Ballesteros [mailto:manuel.sb@garvan.org.au] Sent: Tuesday, February 26, 2019 4:08 PM To: openstack(a)lists.openstack.org Cc: Adrian Chiris (adrianc(a)mellanox.com) Subject: failing to create a vm with SR-IOV (through neutron) - device not found but not listed under libvirt devices Dear Openstack community, I am facing an issue trying to setup neutron with SR-IOV and would like to ask for some help: openstack server show fault. My environment is Openstack Rocky deployed with kolla-ansible. I have edited the configuration files as suggested by the documentation but for some reason nova can't find the PCI device for pass-through. This is my setup [root@zeus-59 ~]# lspci -nn | grep -i mell 88:00.0 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx] [15b3:1015] 88:00.1 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx] [15b3:1015] 88:00.2 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.3 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.4 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.5 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.6 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.7 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.0 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.1 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.2 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.3 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.4 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.5 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.6 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.7 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:02.0 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:02.1 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] sriov_agent.ini in compute node content: [sriov_nic] physical_device_mappings = sriovtenant1:ens2f0,sriovtenant1:ens2f1 exclude_devices = [securitygroup] firewall_driver = neutron.agent.firewall.NoopFirewallDriver nova.conf (nova-compute): ... [pci] passthrough_whitelist = [{ "vendor_id": "10de", "product_id": "1db1" }, { "vendor_id": "15b3", "product_id": "1015", "physical_network": "sriovtenant1" }] alias = { "vendor_id":"10de", "product_id":"1db1", "device_type":"type-PCI", "name":"nv_v100" } ml2_conf.ini (neutron-server): [ml2] type_drivers = flat,vlan,vxlan tenant_network_types = vxlan mechanism_drivers = openvswitch,l2population,sriovnicswitch extension_drivers = port_security [ml2_type_vlan] network_vlan_ranges = physnet1, sriovtenant1 [ml2_type_flat] flat_networks = sriovtenant1 ... Sriov_agent.ini (compute node): [sriov_nic] physical_device_mappings = sriovtenant1:ens2f0,sriovtenant1:ens2f1 exclude_devices = [securitygroup] firewall_driver = neutron.agent.firewall.NoopFirewallDriver Create network and subnet: openstack network create \ --provider-physical-network sriovtenant1 \ --provider-network-type flat \ sriovnet1 openstack subnet create --network sriovnet1 \ --subnet-range=10.0.0.0/16 \ --allocation-pool start=10.0.32.10,end=10.0.32.20 \ sriovnet1_sub1 Create port: openstack port create --network sriovnet1 --vnic-type direct sriovnet1-port1 Create server: openstack server create --flavor m1.large \ --image centos7.5-image \ --nic port-id=373fe020-7b89-40ab-a8e4-76b82cb47490 \ --key-name mykey \ --availability-zone nova:zeus-59.localdomain \ vm-sriov-neutron-1 The server does not gets created with the following error: | fault | {u'message': u'PCI device not found for request ID 419c5fa0-1b7a-4a83-b691-2fcb0fba94cc.', u'code': 500, u'details': u' File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1940, in _do_build_and_run_instance\n filter_properties, request_spec)\n File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2229, in _build_and_run_instance\n instance_uuid=instance.uuid, reason=six.text_type(e))\n', u'created': u'2019-02-26T04:21:01Z'} | Nova logs 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager Traceback (most recent call last): 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 7778, in _update_available_resource_for_node 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager rt.update_available_resource(context, nodename) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py", line 705, in update_available_resource 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager resources = self.driver.get_available_resource(nodename) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 6551, in get_available_resource 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager self._get_pci_passthrough_devices() 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5978, in _get_pci_passthrough_devices 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager pci_info.append(self._get_pcidev_info(name)) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5939, in _get_pcidev_info 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager device.update(_get_device_capabilities(device, address)) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5910, in _get_device_capabilities 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager pcinet_info = self._get_pcinet_info(address) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5853, in _get_pcinet_info 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager virtdev = self._host.device_lookup_by_name(devname) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line 873, in device_lookup_by_name 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager return self.get_connection().nodeDeviceLookupByName(name) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in doit 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager result = proxy_call(self._autowrap, f, *args, **kwargs) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in proxy_call 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager rv = execute(f, *args, **kwargs) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in execute 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager six.reraise(c, e, tb) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in tworker 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager rv = meth(*args, **kwargs) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4305, in nodeDeviceLookupByName 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager if ret is None:raise libvirtError('virNodeDeviceLookupByName() failed', conn=self) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager libvirtError: Node device not found: no node device with matching name 'net_enp136s1f2_36_cc_24_fb_76_e3' Devices [root@zeus-59 ~]# docker exec nova_libvirt sudo virsh nodedev-list block_sda_SATA_SSD_7F2F0759012400117253 computer drm_card0 net_enp136s1_66_0f_f8_42_3b_bb net_enp136s1f1_82_e4_57_39_4c_bf net_enp136s1f2_6e_52_31_b0_04_b7???? net_enp136s1f3_e6_be_60_01_f3_9f net_enp136s1f4_be_d1_8e_9e_46_ef net_enp136s1f5_4e_61_1c_40_98_dc net_enp136s1f6_4a_75_ee_f7_c9_68 net_enp136s1f7_de_3e_da_36_48_02 net_enp136s2_3e_dc_23_b4_ca_c4 net_enp136s2f1_c6_12_aa_52_fa_34 net_enp1s0f0_0c_c4_7a_a4_82_ae net_enp1s0f1_0c_c4_7a_a4_82_af net_ens1f0_90_e2_ba_03_4c_c8 net_ens1f1_90_e2_ba_03_4c_c9 net_ens2f0_7c_fe_90_12_22_b4 net_ens2f1_7c_fe_90_12_22_b5 net_ens2f2_36_cc_24_fb_76_e3 net_ens2f3_82_42_06_38_9a_b7 net_ens2f4_7e_c0_bb_98_72_f4 net_ens2f5_be_9c_1c_25_ff_0d net_ens2f6_2e_01_90_f8_44_b5 net_ens2f7_7e_6a_6d_4e_89_1b pci_0000_00_00_0 pci_0000_00_01_0 pci_0000_00_02_0 pci_0000_00_02_1 pci_0000_00_02_2 pci_0000_00_03_0 pci_0000_00_03_1 pci_0000_00_03_2 ... Note: documentation says to use vlan but I am using flat networks Why is nova looking for a device that libvirt doesn't know about? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed. NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

2 1

[nova]Supporting volume_name when booting from volume
by Rambo 26 Feb '19

26 Feb '19

Hi,all Currently, when creating a new boot-from-volume instance, the user can only control the name of the volume by pre-creating a bootable image-backed volume with the desired name in cinder and providing it to nova during the boot process. It is not friendly to the user when we want to use the desired name volume to boot instance. What do you think of this suggestion? Can you tell me more about this ?Thank you very much. Best Regards Rambo

2 1

failing to create a vm with SR-IOV (through neutron) - device not found but not listed under libvirt devices
by Manuel Sopena Ballesteros 26 Feb '19

26 Feb '19

Dear Openstack community, I am facing an issue trying to setup neutron with SR-IOV and would like to ask for some help: openstack server show fault. My environment is Openstack Rocky deployed with kolla-ansible. I have edited the configuration files as suggested by the documentation but for some reason nova can't find the PCI device for pass-through. This is my setup [root@zeus-59 ~]# lspci -nn | grep -i mell 88:00.0 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx] [15b3:1015] 88:00.1 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx] [15b3:1015] 88:00.2 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.3 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.4 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.5 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.6 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:00.7 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.0 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.1 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.2 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.3 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.4 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.5 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.6 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:01.7 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:02.0 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] 88:02.1 Ethernet controller [0200]: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] [15b3:1016] sriov_agent.ini in compute node content: [sriov_nic] physical_device_mappings = sriovtenant1:ens2f0,sriovtenant1:ens2f1 exclude_devices = [securitygroup] firewall_driver = neutron.agent.firewall.NoopFirewallDriver nova.conf (nova-compute): ... [pci] passthrough_whitelist = [{ "vendor_id": "10de", "product_id": "1db1" }, { "vendor_id": "15b3", "product_id": "1015", "physical_network": "sriovtenant1" }] alias = { "vendor_id":"10de", "product_id":"1db1", "device_type":"type-PCI", "name":"nv_v100" } ml2_conf.ini (neutron-server): [ml2] type_drivers = flat,vlan,vxlan tenant_network_types = vxlan mechanism_drivers = openvswitch,l2population,sriovnicswitch extension_drivers = port_security [ml2_type_vlan] network_vlan_ranges = physnet1, sriovtenant1 [ml2_type_flat] flat_networks = sriovtenant1 ... Sriov_agent.ini (compute node): [sriov_nic] physical_device_mappings = sriovtenant1:ens2f0,sriovtenant1:ens2f1 exclude_devices = [securitygroup] firewall_driver = neutron.agent.firewall.NoopFirewallDriver Create network and subnet: openstack network create \ --provider-physical-network sriovtenant1 \ --provider-network-type flat \ sriovnet1 openstack subnet create --network sriovnet1 \ --subnet-range=10.0.0.0/16 \ --allocation-pool start=10.0.32.10,end=10.0.32.20 \ sriovnet1_sub1 Create port: openstack port create --network sriovnet1 --vnic-type direct sriovnet1-port1 Create server: openstack server create --flavor m1.large \ --image centos7.5-image \ --nic port-id=373fe020-7b89-40ab-a8e4-76b82cb47490 \ --key-name mykey \ --availability-zone nova:zeus-59.localdomain \ vm-sriov-neutron-1 The server does not gets created with the following error: | fault | {u'message': u'PCI device not found for request ID 419c5fa0-1b7a-4a83-b691-2fcb0fba94cc.', u'code': 500, u'details': u' File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1940, in _do_build_and_run_instance\n filter_properties, request_spec)\n File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2229, in _build_and_run_instance\n instance_uuid=instance.uuid, reason=six.text_type(e))\n', u'created': u'2019-02-26T04:21:01Z'} | Nova logs 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager Traceback (most recent call last): 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 7778, in _update_available_resource_for_node 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager rt.update_available_resource(context, nodename) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py", line 705, in update_available_resource 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager resources = self.driver.get_available_resource(nodename) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 6551, in get_available_resource 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager self._get_pci_passthrough_devices() 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5978, in _get_pci_passthrough_devices 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager pci_info.append(self._get_pcidev_info(name)) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5939, in _get_pcidev_info 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager device.update(_get_device_capabilities(device, address)) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5910, in _get_device_capabilities 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager pcinet_info = self._get_pcinet_info(address) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5853, in _get_pcinet_info 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager virtdev = self._host.device_lookup_by_name(devname) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/host.py", line 873, in device_lookup_by_name 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager return self.get_connection().nodeDeviceLookupByName(name) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in doit 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager result = proxy_call(self._autowrap, f, *args, **kwargs) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in proxy_call 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager rv = execute(f, *args, **kwargs) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in execute 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager six.reraise(c, e, tb) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in tworker 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager rv = meth(*args, **kwargs) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4305, in nodeDeviceLookupByName 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager if ret is None:raise libvirtError('virNodeDeviceLookupByName() failed', conn=self) 2019-02-26 15:36:42.595 7 ERROR nova.compute.manager libvirtError: Node device not found: no node device with matching name 'net_enp136s1f2_36_cc_24_fb_76_e3' Devices [root@zeus-59 ~]# docker exec nova_libvirt sudo virsh nodedev-list block_sda_SATA_SSD_7F2F0759012400117253 computer drm_card0 net_enp136s1_66_0f_f8_42_3b_bb net_enp136s1f1_82_e4_57_39_4c_bf net_enp136s1f2_6e_52_31_b0_04_b7???? net_enp136s1f3_e6_be_60_01_f3_9f net_enp136s1f4_be_d1_8e_9e_46_ef net_enp136s1f5_4e_61_1c_40_98_dc net_enp136s1f6_4a_75_ee_f7_c9_68 net_enp136s1f7_de_3e_da_36_48_02 net_enp136s2_3e_dc_23_b4_ca_c4 net_enp136s2f1_c6_12_aa_52_fa_34 net_enp1s0f0_0c_c4_7a_a4_82_ae net_enp1s0f1_0c_c4_7a_a4_82_af net_ens1f0_90_e2_ba_03_4c_c8 net_ens1f1_90_e2_ba_03_4c_c9 net_ens2f0_7c_fe_90_12_22_b4 net_ens2f1_7c_fe_90_12_22_b5 net_ens2f2_36_cc_24_fb_76_e3 net_ens2f3_82_42_06_38_9a_b7 net_ens2f4_7e_c0_bb_98_72_f4 net_ens2f5_be_9c_1c_25_ff_0d net_ens2f6_2e_01_90_f8_44_b5 net_ens2f7_7e_6a_6d_4e_89_1b pci_0000_00_00_0 pci_0000_00_01_0 pci_0000_00_02_0 pci_0000_00_02_1 pci_0000_00_02_2 pci_0000_00_03_0 pci_0000_00_03_1 pci_0000_00_03_2 ... Note: documentation says to use vlan but I am using flat networks Why is nova looking for a device that libvirt doesn't know about? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

1 0

[baremetal-sig][ironic] Proposing Formation of Bare Metal SIG
by Chris Hoge 26 Feb '19

26 Feb '19

This morning at the OpenStack Foundation board meeting we announced that we will focusing more our open infrastructure messaging efforts on bare-metal, and the promotion of Ironic in particular. To support these efforts, I'd like to form a Bare Metal SIG to bring together community members to collaborate on this work. The purpose of the Bare Metal SIG will be to promote the development and use of Ironic and other OpenStack bare-metal software. This will include marketing efforts like case studies of Ironic clusters in industry and academia, supporting integration of Ironic with projects like Airship and the Kubernetes Cluster API, coordinating presentations for industry events, developing documentation and tutorials, gathering feedback from the community on usage and feature gaps, and other broader community-facing efforts to encourage the adoption of Ironic as a bare-metal management tool. If you would like to participate, please indicate your interest in the linked planning etherpad. Ideally we would like to have broad engagement from across the community, from developers and practitioners alike. We'd like to highlight all of the efforts and usage across our community communicate how powerful Ironic is for hardware management. https://etherpad.openstack.org/p/bare-metal-sig Thanks in advance to everyone. I’ve been using Ironic to manage my home cluster for quite a while now, and I’m really excited to be working on the SIG and in supporting the efforts of the Ironic team and the users who are running Ironic in production. Chris Hoge Strategic Program Manager OpenStack Foundation

4 5

Re: [nova][dev][ops] can we get rid of 'project_only' in the DB layer?
by Alex Xu 26 Feb '19

26 Feb '19

Add the maillist back, I missed from the previous reply... melanie witt <melwittt(a)gmail.com> 于2019年2月16日周六上午12:22写道： > Thanks for the reply, Alex. Response is inline. > > On Fri, 15 Feb 2019 15:49:19 +0800, He Jie Xu <soulxu(a)gmail.com> wrote: > > We need to ensure all the APIs check the policy with real instance's > > project and user id, like this > > > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/ev… > > Otherwise, any user can get any other tenant's instance. > > > > Some of APIs doesn't check like this, for example: > > > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/at… > > While I agree with this (policy check instance project/user instead of > request context project/user), I'm not sure it's related to the > project_only=True at the database layer. The project_only=True at the > database layer only enforces request context project, which is what the > second example here will also do, if policy contains > 'project_id:%(project_id)s'. It seems to me that if we remove > project_only=True from the database layer, we will get proper > enforcement of request context project/user by the existing policy > checks, if the policy is configured as such. And we default policy to > either rule:admin_api or rule:admin_or_owner: > > https://docs.openstack.org/nova/latest/configuration/sample-policy.html > > So, it seems to me that changing policy enforcement from request context > project/user => instance project/user would be a separate change. Please > let me know if I'm misunderstanding you. > > One thing I do notice though, in your first example, is that the > get_instance is done _before_ the policy check, which would need to be > moved after the policy check, in the same change that would remove > project_only=True. So I'm glad you pointed that out. > Emm...no, the first example is the right example. project_only=True will ensure db call return the instance belong to the project in the request context. If project_only=False, the db call may return other project's instance. Then when the rule is 'project_id:%(project_id)s' and the target is instance's project_id, the policy enforcement will ensure the request context's project id match the instance's project_id, then the user won't get other project's instance. > > > I'm trying to memory why we didn't do that in the beginning, sounds like > > we refused to support user-id based policy. But > > in the end for the backward-campatible for the user like CERN, we > > support user-id based policy for few APIs. > > > https://review.openstack.org/#/q/topic:bp/user_id_based_policy_enforcement+… > > > > This is probably why some APIs checks policy with real instance's > > project id and user id and some APIs not. > > > > melanie witt <melwittt(a)gmail.com <mailto:melwittt@gmail.com>> 于2019年2 > > 月15日周五上午1:23写道： > > > > Hey all, > > > > Recently, we had a customer try the following command as a non-admin > > with a policy role granted in policy.json to allow live migrate: > > > > "os_compute_api:os-migrate-server:migrate_live": "rule:admin_api > or > > role:Operator" > > > > The scenario is that they have a server in project A and a user in > > project B with role:Operator and the user makes a call to live > migrate > > the server. > > > > But when they call the API, they get the following error response: > > > > {"itemNotFound": {"message": "Instance <uuid server 1> could not > be > > found.", "code": 404}} > > > > A superficial look through the code shows that the live migrate > should > > work, because we have appropriate policy checks in the API, and the > > request makes it past those checks because the policy.json has been > set > > correctly. > > > > A common pattern in our APIs is that we first compute_api.get() the > > instance object and then we call the server action (live migrate, > stop, > > start, etc) with it after we retrieve it. In this scenario, the > > compute_api.get() fails with NotFound. > > > > And the reason it fails with NotFound is because, much lower level, > at > > the DB layer, we have a keyword arg called 'project_only' which, when > > True, will scope a database query to the RequestContext.project_id > > only. > > We have hard-coded 'project_only=True' for the instance get query. > > > > So, when the user in project B with role:Operator tries to retrieve > the > > instance record in project A, with appropriate policy rules set, it > > will > > fail because 'project_only=True' and the request context is project > B, > > while the instance is in project A. > > > > My question is: can we get rid of the hard-coded 'project_only=True' > at > > the database layer? This seems like something that should be > > enforced at > > the API layer and not at the database layer. It reminded me of an > > effort > > we had a few years ago where we removed other hard-coded policy > > enforcement from the database layer [1][2]. I've uploaded a WIP > > patch to > > demonstrate the proposed change [3]. > > > > Can anyone think of any potential problems with doing this? I'd like > to > > be able to remove it so that operators are able use policy to allow > > non-admin users with appropriately configured roles to run server > > actions. > > > > Cheers, > > -melanie > > > > [1] > > > https://blueprints.launchpad.net/nova/+spec/nova-api-policy-final-part > > [2] > > > https://review.openstack.org/#/q/topic:bp/nova-api-policy-final-part+(statu… > > [3] https://review.openstack.org/637010 > > > > > > >

4 4

[dev][keystone] App Cred Capabilities Update
by Colleen Murphy 26 Feb '19

26 Feb '19

I have an initial draft of application credential capabilities available for review[1]. The spec[2] was not straightforward to implement. There were a few parts that I found unintuitive, user-unfriendly, and overcomplicated. The current proposed implementation differs from the spec in some ways that I want to discuss with the team. Given that non-client library freeze is next week, and the changes we need in keystonemiddleware also require changes in keystoneclient, I'm not sure there is enough time to properly flesh this out and allow for thorough code review, but if we miss the deadline we can be ready to get this in in the beginning of next cycle (with apologies to everyone waiting on this feature - I just want to make sure we get it right with minimal regrets). * Naming As always, naming is hard. In the spec, we've called the property that is attached to the app cred "capabilities" (for the sake of this email I'm going to call it user-created-rules), and we've called the operator-configured list of available endpoints "permissible path templates" (for the sake of this email I'm going to call it operator-created-rules). I find both confusing and awkward. "Permissible path templates" is not a great name because the rule is actually about more than just the path, it's about the request as a whole, including the method. I'd like to avoid saying "template" too because that evokes a picture of something like a Jinja or ERB template, which is not what this is, and because I'd like to avoid the whole string substitution thing - more on that below. In the implementation, I've renamed the operator-created-rules to "access rules". I stole this from Istio after Adam pointed out they have a really similar concept[3]. I really like this name because I think it well-describes the thing we're building without already being overloaded. So far, I've kept the user-created-rules as "capabilities" but I'm not a fan of it because it's an overloaded word and not very descriptive, although in my opinion it is still more descriptive than "whitelist" which is what we were originally going to call it. It might make sense to relate this property somehow to the operator-created-rules - perhaps by calling it access_rules_list, or granted_access_rules. Or we could call *this* thing the access rules, and call the other thing allowed_access_rules or permitted_access_rules. * Substitutions The way the spec lays out variable components of the URL paths for both user-created-rules and operator-created-rules is unnecessarily complex and in some cases faulty. The only way I can explain how complicated it is is to try to give an example: Let's say we want to allow a user to create an application credential that allows the holder to issue a GET request on the identity API that looks like /v3/projects/ef7284b4-3a75-4570-8ea8-b30214f18538/tags/foobar. The spec says that the string '/v3/projects/{project_id}/tags/{tag}' is what should be provided verbatim in the "path" attribute of a "capability", then there should be a "substitutions" attribute that sets {"tag": "foobar"}, then the project_id should be taken from the token scope at app cred usage time. When the capability is validated against the operator-created-rules at app cred creation time, it needs to check that the path string matches exactly, that the keys of the "substitutions" dict matches the "user template keys" list, and that keys required by the "context template keys" are provided by the token context. Taking the project ID, domain ID, or user ID from the token scope is not going to work because some of these APIs may actually be system-scoped APIs - it's just not a hard and fast rule that a project/domain/user ID in the URL maps to the same user and scope of the token used to create it. Once we do away with that, it stops making sense to have a separate attribute for the user-provided substitutions when they could just include that in the URL path to begin with. So the proposed implementation simply allows the wildcards * and ** in both the operator-created-rules and user-created-rules, no python-formatting variable substitutions. * UUIDs The spec says each operator-created-rule should have its own UUID, and the end user needs to look up and provide this UUID when they create the app cred rule. This has the benefit of having a fast lookup because we've put the onus on the user to look up the rule themselves, but I think it is very user-unfriendly. In the proposed implementation, I've done away with UUIDs on the operator-created-rules, and instead a match is looked up based on the service type, request path and method, and the "allow_chained" attribute (more on that next). Depending on how big we think this list of APIs will get, this will have some impact on performance on creation time (not at token validation time). UUIDs make sense for singleton resources that are created in a database. I imagine this starting as an operator-managed configuration file, and maybe some day in the future a catalog of this sort could be published by the services so that the operator doesn't have to maintain it themselves. To that end, I've implemented the operator-created-rules driver with a JSON file backend. But with this style of implementation, including UUIDs for every rule is awkward - it only makes sense if we're generating the resources within keystone and storing them in a database. * allow_chained The allow_chained attribute looks and feels awkward and adds complexity to the code Is there really a case when either the user or operator would not want to allow a service to make a request on behalf of a user who is making a more general request? Also, can we find a better name for it? Those are all the major question marks for me. There are some other minor differentiations from the spec and I will propose an update that makes it consistent with reality after we have these other questions sorted out. Colleen [1] https://review.openstack.org/#/q/topic:bp/whitelist-extension-for-app-creds [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/ca… [3] https://istio.io/docs/reference/config/authorization/istio.rbac.v1alpha1/#A…

2 6

[senlin] Forum session brainstorming
by Duc Truong 26 Feb '19

26 Feb '19

I have created an etherpad to capture ideas for Senlin forum sessions [1]. Please add your ideas along with your irc name. We especially would like to hear from Senlin users and operators on what you would like to see discussed. [1] https://etherpad.openstack.org/p/DEN-train-senlin-forum-brainstorming

1 0

UC Feb 2019 Election results
by Mohamed Elsakhawy 26 Feb '19

26 Feb '19

Good Afternoon all On behalf of the User Committee Elections officers, I am pleased to announce the results of the UC elections for Feb 2019. Please join me in congratulating the winners of the 3 seats : - Amy Marrich - Belmiro Moreira - John Studarus Thank you to all of the candidates and all of you who voted * https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_8760d5969c6275f1&rkey=7…

6 5

[dev][swift] Regarding fstab entries in a Swift controller
by Vedartham Bharath 26 Feb '19

26 Feb '19

Hi all, This is with regards to an issue in the documentation of Openstack Swift and mostly an issue to system administrators operating Swift.(Sorry if the subject tags are wrong!!) In the Swift Multiserver docs, When setting up an object storage server, the docs tell to use the disk labels in the disk's /etc/fstab entries. eg: /dev/sda /srv/node/sda xfs noatime............. I feel that we should encourage people to use UUIDs rather than disk labels. I have had a lot of issues with my Swift storage servers crashing whenever I reboot them. I have found out that the issue is with the /etc/fstab as the disk labels change whenever a disk is removed or added(depends on the OS's "mood" i.e boot order). I don't want to change my ring configuration every time I reboot my storage servers. Thank you Bharath

1 0

[openstack-dev] [Monasca] How to get “aggregated value of one metric statistics” ?
by Mohan Kumar 26 Feb '19

26 Feb '19

Hi Team, How to get “aggregated value of one metric statistics” from starting of month to till now . If I try to group metrics using * --period* based on timestamp it including data from previous month metrics as well [1] In below example , trying to get last ~24.5 days of metrics from particular tenant , But I can see 2019-01-26 data . With UTC_START_TIME “2019-02-01T00:00:00Z” [2] does *--merge_metrics * not Merge multiple metrics into a single result ? Please suggest how to customise my API call to get “AVG (aggregated) value of one metric statistics” from starting of month to till now . *Regards.,* Mohankumar N "*Confidentiality Warning*: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system. *Virus Warning:* Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

2 2