April 2021 - openstack-discuss - lists.openstack.org

Why doesn't identity providers have separate IDs and Names in Openstack?
by Kabai Zoltán 20 Apr '21

20 Apr '21

Dear Community, I just have a question what I couldn't resolve with my colleagues: Why doesn't identity providers have separate IDs and Names in Openstack? I think most of the things have a separate ID and a separate Name in Openstack (Users, Projects, virtual machines, etc). Why doesn't identity providers have separate IDs and Names? Are there other objects like this? Is there a rule why specific entities must have both IDs and Names while others can live without a separate Name? $ openstack identity provider list +----------------+---------+-------------+ | ID | Enabled | Description | +----------------+---------+-------------+ | cloud1 | True | None | +----------------+---------+-------------+ Br, Zoltán Gábor Kabai kabaiz(a)gmail.com

1 0

[Keystone][Interop] request for 15-30 min on Xena PTG for Interop
by Kanevsky, Arkady 20 Apr '21

20 Apr '21

Kristi, As chair of OpenStack Interop WG, Interop/Refstack would like 15-30 min on PTG meeting to go over Interop testing and any changes for Keystone tempest or tempest configuration in Wallaby cycle or changes planned for Xena. Once on agenda one of the Interop WG person will attend and lead the discussion. Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

2 2

dynamic vendor data and cloud-init
by Manish Mahalwal 20 Apr '21

20 Apr '21

Hi All, I am working with OpenStack Pike and cloud-init 21.1. I am able to successfully pass dynamic vendor data to the config drive of an instance. However, cloud-init 21.1 just reads all the 'x' bytes of the vendor_data2.json but it doesn't execute the contents of the json. Although, static vendor data works perfectly fine and the YAML file in the JSON is executed as expected by cloud-init 21.1 * Now, the person who wrote the code for handling dynamic vendordata in cloud-init (https://github.com/canonical/cloud-init/pull/777) says that the JSON cloud-init expects is of the form: > {"cloud-init": "#cloud-config\npackage_upgrade: True\npackages:\n - > black\nfqdn: cloud-overridden-by-vendordata2.example.org."} > * I believe that the JSON should have another outer key (as mentioned here https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/v…) which is the name of the microservice specified in nova.conf file and that the inner key should be cloud-init. In nova.conf: vendordata_dynamic_targets=name1@ http://example.com,name2@http://example2.com <http://example.com,name2@http//example2.com> { > "name1": { > "cloud-init": "#cloud-config\n..." > }, > "name2": { > "cloud-init": "#cloud-config\n..." > } > } >>Who is right and who is wrong? To read more on this please go through the following: https://bugs.launchpad.net/cloud-init/+bug/1841104

2 3

[neutron] bug deputy report for week of 2021-04-12
by Bence Romsics 20 Apr '21

20 Apr '21

Hi Neutron Team, We had the following new bugs last week: Critical * https://bugs.launchpad.net/neutron/+bug/1923633 Neutron-tempest-plugin scenario jobs failing due to metadata issues gate failure, Slawek and Rodolfo added extra logs and are analyzing them High * https://bugs.launchpad.net/neutron/+bug/1923453 and * https://bugs.launchpad.net/neutron/+bug/1923870 Some Neutron commands do not initilize privsep fix merged: https://review.opendev.org/c/openstack/neutron/+/786272 fix in the gate: https://review.opendev.org/c/openstack/neutron/+/786282 * https://bugs.launchpad.net/neutron/+bug/1924789 Since the migration to new engine facade, some operations that shouldn't be executing within a txn, are logging a "session semantic violated" warning unassigned Medium * https://bugs.launchpad.net/neutron/+bug/1923700 Report correct error when external DNS(designate) recordset quota limit exceeds fix proposed (waiting for neutron-lib release): https://review.opendev.org/c/openstack/neutron/+/786175 Low * https://bugs.launchpad.net/neutron/+bug/1923423 l3_router.service_providers DriverController's _attrs_to_driver is not py3 compatible fix merged: https://review.opendev.org/c/openstack/neutron/+/785830 Stable * https://bugs.launchpad.net/neutron/+bug/1924315 [stable/rocky] neutron-tempest-plugin-scenario-openvswitch-iptables_hybrid-rocky job fails gate failure, fix proposed: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/786657 * https://bugs.launchpad.net/neutron/+bug/1923412 [stable/stein] Tempest fails with unrecognized arguments: --exclude-regex gate failure, unassigned * https://bugs.launchpad.net/neutron/+bug/1923644 OVN agent delete support should be backported to pre-wallaby releases backport with many dependencies, recommended for stable reviewers Neutron-Dynamic-Routing * https://bugs.launchpad.net/neutron/+bug/1924237 TypeError when formating IP address for BGP plugin fix merged: https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/786371 micro-RFE * https://bugs.launchpad.net/neutron/+bug/1923592 [Routed networks] Router routes to other segment CIDRs should have a gateway IP Edit still following up with the triage: * https://bugs.launchpad.net/neutron/+bug/1924776 [ovn] use of address scopes does not automatically disable router snat * https://bugs.launchpad.net/neutron/+bug/1924765 [ovn] fip assignment to instance via router with snat disabled is broken * https://bugs.launchpad.net/neutron/+bug/1922089 [ovn] enable_snat cannot be disabled once enabled Cheers, Bence

1 0

[Multi-arch SIG] success to run full tempest tests on Arm64 env. What's next?
by Rico Lin 20 Apr '21

20 Apr '21

Dear all, I'm glad to tell everyone that we finally succeeded to build Devstack and run full tempest tests on it [1]. As the test build result shows [2], the job is stable enough to run. For earlier 13+ job results. (will do more recheck later) One Timeout, and two failure cases (Which are targeted by increase `BUILD_TIMEOUT` to 900 secs). The job `devstack-platform-arm64` runs around 2.22 hrs to 3.04 hrs, which is near two times slower than on x86 environment. It's not a solid number as the performance might change a lot with different cloud environments and different hardware. But I think this is a great chance for us to make more improvements. At least now we have a test job ready (Not merged yet) for you to do experiments with. And we should also add suggestions to Multi-arch SIG documentation so once we make improvements, other architecture can share the efforts too. *So please join us if you are also interested in help tuning the performance :)* *Also, we need to discuss what kind of way we should run this job, should we separate it into small jobs? Should we run it as a periodic job? voting?* *On the other hand, I would hope to collect more ideas on how we should move forward.* *Please provide your idea for this on our Xena PTG etherpad* *https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig <https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig>* Our PTG is scheduled around 4/20 Tuesday from 07:00-08:00 and 15:00-16:00 (UTC time) If you plan to join our PTG, feel free to update our PTG etherpad to suggest other topics. And our Meeting time is scheduled biweekly on Tuesday (host on demand) Please join our IRC #openstack-multi-arch [1] https://review.opendev.org/c/openstack/devstack/+/708317 [2] https://zuul.openstack.org/builds?job_name=devstack-platform-arm64+ *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

3 2

[Multi-arch SIG][PTG] Multi-arch SIG PTG 07:00 and 15:00 UTC today!
by Rico Lin 20 Apr '21

20 Apr '21

Dear all Multi-arch SIG will have our PTG session from 07:00-08:00 and 15:00-16:00 (UTC time) Feel free to join us PTG: http://ptg.openstack.org/ptg.html Etherpad: https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

1 0

[ptg][swift][ops] Operator feedback session 21 Apr 13:00-14:00 UTC
by Timothy Burke 20 Apr '21

20 Apr '21

Later this week, the Swift community will have an operator feedback session during one of our PTG slots [0]. If you're running a swift cluster, large or small, we'd love to see you there! As we've done in the past [1], we'll have an etherpad going [2] -- feel free to start filling it in and adding discussion items today! Even if you won't make the meeting, we'd appreciate your feedback. Looking forward to hearing from you! Tim [0] 21 Apr at 1300 UTC in https://www.openstack.org/ptg/rooms/ocata [1] https://wiki.openstack.org/wiki/Swift/Etherpads#List_of_Ops_Feedback_Etherp… [2] https://etherpad.opendev.org/p/swift-xena-ops-feedback

1 0

[tacker] PTG meeting
by Yasufumi Ogawa 20 Apr '21

20 Apr '21

Hi team, As a reminder, we will have PTG meeting from 6am UTC (3pm JST/KST) today [1]. You can find the link of room from here [2]. I'd like to skip irc meeting this week without if we have something to discuss after the meeting. [1] https://etherpad.opendev.org/p/tacker-xena-ptg [2] http://ptg.openstack.org/ptg.html Thanks, Yasufumi

1 0

[ops][nova][victoria] Migrate cross CPU?
by DHilsbos＠performair.com 19 Apr '21

19 Apr '21

All; I seem to have generated another issue for myself... I built our Victoria cloud initially on Intel Atom servers. We recently received the first of our AMD Epyc (7002 series) servers, which are intended to take over the Nova Compute responsibilities. I've had success in the past doing live migrates, but live migrating from one of the Atom servers to the new server fails, with an error indicating CPU compatibility problems. Ok, I can understand that. My problem is that I don't seem to understand the openstack server migrate command (non-live). It doesn't seem to do anything, whether the instance is Running or Shut Down. I can't find errors in the logs from the API / conductor / scheduler host. I also can't find an option to pass to the openstack server start command which requests a specific host. Can I get these existing instances moved from the Atom servers to the Epyc server(s), or do I need to recreate them to do this? Thank you, Dominic L. Hilsbos, MBA Director - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

2 8

cinder + Unity
by Albert Shih 19 Apr '21

19 Apr '21

Hi everyone, I'm a total newbie with openstack, currently I'm trying to put a POC with a Unity storage element, 4 computes, and few servers (cinder, keystone, glance, neutron, nova, placement and horizon). I think my keystone, glance, placement are working (at least they past the test). Currently I'm trying to make cinder working with my Unity (480), the objectif are to use iSCSI. Here the configuration of my /etc/cinder/cinder.conf [DEFAULT] rootwrap_config = /etc/cinder/rootwrap.conf api_paste_confg = /etc/cinder/api-paste.ini iscsi_helper = tgtadm volume_name_template = volume-%s volume_group = cinder-volumes verbose = True auth_strategy = keystone state_path = /var/lib/cinder lock_path = /var/lock/cinder volumes_dir = /var/lib/cinder/volumes enabled_backends = unity transport_url = rabbit://openstack:XXXXXX@amqp-cloud.private.FQDN/openstack auth_strategy = keystone debug = True verbose = True [database] connection = mysql+pymysql://cinder:XXXXXXX@mariadb-cloud.private.FQDN/cinder [keystone_authtoken] www_authenticate_uri = http://keystone.private.FQDN:5000/v3 auth_url = http://keystone.private.FQDN:5000 identity_uri = http://keystone.private.FQDN:5000 memcached_servers = memcached-cloud.private.FQDN:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = cinder password = XXXXXX [oslo_concurrency] lock_path = /var/lib/cinder/tmp [unity] # Storage protocol storage_protocol = iSCSI # Unisphere IP san_ip = onering-remote.FQDN # Unisphere username and password san_login = openstack san_password = "XXXXX" # Volume driver name volume_driver = cinder.volume.drivers.dell_emc.unity.Driver # backend's name volume_backend_name = Unitiy_ISCSI unity_io_ports = *_enp1s0 unity_storage_pool_names = onering When I'm trying to create a storage through a openstack volume create volumetest --type thick_volume_type --size 100 I don't even see (with tcpdump) the cinder server trying to connect to onering-remote.FQDN Inside my /var/log/cinder/cinder-scheduler.log I have 2021-04-19 18:06:56.805 21315 INFO cinder.scheduler.base_filter [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] Filtering removed all hosts for the request with volume ID '06e5f07d-766f-4d07-b3bf-6153a2cf6abd'. Filter results: AvailabilityZoneFilter: (start: 0, end: 0), CapacityFilter: (start: 0, end: 0), CapabilitiesFilter: (start: 0, end: 0) 2021-04-19 18:06:56.806 21315 WARNING cinder.scheduler.filter_scheduler [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] No weighed backend found for volume with properties: {'id': '5f16fc1f-76ff-41ee-8927-56925cf7b00f', 'name': 'thick_volume_type', 'description': None, 'is_public': True, 'projects': [], 'extra_specs': {'provisioning:type': 'thick', 'thick_provisioning_support': 'True'}, 'qos_specs_id': None, 'created_at': '2021-04-19T15:07:09.000000', 'updated_at': None, 'deleted_at': None, 'deleted': False} 2021-04-19 18:06:56.806 21315 INFO cinder.message.api [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] Creating message record for request_id = req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 2021-04-19 18:06:56.811 21315 ERROR cinder.scheduler.flows.create_volume [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] Failed to run task cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create: No valid backend was found. No weighed backends available: cinder.exception.NoValidBackend: No valid backend was found. No weighed backends available It seem (for me) cinder don't try to use unity.... Any help ? Regards -- Albert SHIH Observatoire de Paris Heure local/Local time: Mon Apr 19 08:01:37 PM CEST 2021

1 0