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

[Diversity] Diversity & Inclusion WG Meeting reminder
by Amy Marrich 30 Apr '21

30 Apr '21

The Diversity & Inclusion WG invites members of all OSF projects to our meeting Monday May 3rd, at 17:00 UTC in the #openinfra-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity -wg-agenda. Please feel free to add any topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

[interop] Weekly meeting is at Fridays 4:00pm UTC
by Kanevsky, Arkady 30 Apr '21

30 Apr '21

Every Fridays at 16:00 UTC <16:00%20UTC > on https://meetpad.opendev.org/Interop-WG-weekly-meeting Current Meeting Logs on etherpad - https://etherpad.opendev.org/p/interop Wiki is updated with the latest info. https://wiki.openstack.org/wiki/Governance/InteropWG 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

1 0

[tripleo] removing myself from tripleo-core
by Emilien Macchi 29 Apr '21

29 Apr '21

Hi people, If you didn't notice, I am not working on TripleO anymore (as a developer, but still a heavy user) and therefore my amount of contribution and awareness in the project makes me think I shouldn't be considered a maintainer anymore. I'll remove myself from tripleo-core in Gerrit. I just want to let you know that I'm not far, I'm still on IRC and sometimes participate in the chat. I can also provide support for the crappy code that I wrote (Alex made me do it most of the time). However don't expect me to be heavily involved like it used to be the case. I just want to say that I already miss a lot working on TripleO and in OpenStack in general. The Community, the maturity of the project and all that we built is something that can't be compared to anything else out there. My focus is now "Kubernetes (OpenShift) on top of OpenStack", heavily consuming what OpenStack has to offer and connecting the two worlds. It's a lot of fun and a lot of new things to learn! But I'm sure OpenStack won't go too far away from my plate, so let's keep in touch. Take care, -- Emilien Macchi

2 1

[glance][ceph] Openstack Wallaby and Ceph Pacific- ERROR cinder.scheduler.flows.create_volume
by Tecnologia Charne.Net 29 Apr '21

29 Apr '21

Hello! I'm working with Openstack Wallaby (1 controller, 2 compute nodes) connected to Ceph Pacific cluster in a devel environment. With Openstack Victoria and Ceph Pacific (before last friday update) everything was running like a charm. Then, I upgraded Openstack to Wallaby and Ceph to version 16.2.1. (Because of auth_allow_insecure_global_id_reclaim I had to upgrade many clients... but that's another story...) After upgrade, when I try to create a volume from image, openstack volume create --image f1df058d-be99-4401-82d9-4af9410744bc debian10_volume1 --size 5 with "show_image_direct_url = True", I get "No valid backend" in /var/log/cinder/cinder-scheduler.log 2021-04-26 20:35:24.957 41348 ERROR cinder.scheduler.flows.create_volume [req-651937e5-148f-409c-8296-33f200892e48 c048e887df994f9cb978554008556546 f02ae99c34cf44fd8ab3b1fd1b3be964 - - -] Failed to run task cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create: No valid backend was found. Exceeded max scheduling attempts 3 for resource 56fbb645-2c34-477d-9a59-beec78f4fd3f: cinder.exception.NoValidBackend: No valid backend was found. Exceeded max scheduling attempts 3 for resource 56fbb645-2c34-477d-9a59-beec78f4fd3f and 2021-04-26 20:35:24.968 41347 ERROR oslo_messaging.rpc.server [req-651937e5-148f-409c-8296-33f200892e48 c048e887df994f9cb978554008556546 f02ae99c34cf44fd8ab3b1fd 1b3be964 - - -] Exception during message handling: rbd.InvalidArgument: [errno 22] RBD invalid argument (error creating clone) in /var/log/cinder/cinder-volume.log If I disable "show_image_direct_url = False", volume creation from image works fine. I have spent the last four days googling and reading lots of docs, old and new ones, unlucly... Does anybody have a clue, (please)? Thanks in advance! Javier.-

2 2

[Cinder] Problem in iSCSI Portal
by Taha Adel 29 Apr '21

29 Apr '21

Hello, The situation is, I have one storage node that has cinder-volume service up and running on top of it and has a dedicated physical NIC for storage traffic. I have set the following configuration in /etc/cinder/cinder.conf file at the storage node: volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver volume_group = cinder-volumes target_protocol = iscsi target_helper = lioadm iscsi_ip_address = 10.0.102.11 (different than the management ip) The service is able to create the volume and attach it as a backstore for iSCSI, but it can't create a Portal for iSCSI service. Should I create the portal entry by myself? or is there a mistake I have made in the config file? Thanks in advance

2 1

Fwd: cinder + Unity
by Rajat Dhasmana 29 Apr '21

29 Apr '21

Hi Albert, On Mon, Apr 19, 2021 at 11:45 PM Albert Shih <Albert.Shih(a)obspm.fr> wrote: > 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 > This might be something to look at with the wrong spelling causing mismatch. > 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) > This log mentions that no host is valid to pass the 3 filters in the scheduler. > 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.... > > The cinder-volume service is responsible for communicating with the backend and this create request fails on scheduler only, hence no sign of it. > Any help ? > > Regards > > Looking at the scheduler logs, there are a few things you can check: 1) execute ``cinder-manage service list`` command and check the status of cinder-volume service if it's active or not. If it shows an X sign then check in cinder-volume logs for any startup failure. 2) Check the volume type properties and see if ``volume_backend_name`` is set to the right value i.e. Unitiy_ISCSI (which looks suspicious because the spelling is wrong and there might be a mismatch somewhere) Also it's good to mention the openstack version you're using since the code changes every cycle and it's hard to track the issues with every release. Thanks and regards Rajat Dhasmana > > -- > Albert SHIH > Observatoire de Paris > Heure local/Local time: > Mon Apr 19 08:01:37 PM CEST 2021 > >

3 2

[release] Release countdown for week R-23, April 26-30
by Herve Beraud 29 Apr '21

29 Apr '21

Welcome back to the release countdown emails! These will be sent at major points in the Xena development cycle, which should conclude with a final release on 06 October, 2021. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the Xena development cycle, assessing Xena community goals and approving Xena specs. General Information ------------------- Xena is a 25 weeks development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/xena/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the Xena release are continued in Xena with a similar release model. Upcoming Deadlines & Dates -------------------------- Xena-1 milestone: 27 May, 2021 Hervé Beraud and the Release Management team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[oslo] Team meetings updates for Xena
by Herve Beraud 29 Apr '21

29 Apr '21

Hi Osloers, Please notice the following updates concerning the team's meetings during Xena. Meetings are now scheduled the first and the third Monday of each month. No longer weekly meetings. Meeting's courtesy ping list will be updated soon for Xena. If you want to continue to be called at the beginning of each meeting please add you nick here: https://wiki.openstack.org/wiki/Meetings/Oslo#Xena_Courtesy_Ping Thanks for your attention. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

An compute service hang issue
by Yingji Sun 29 Apr '21

29 Apr '21

Buddies, Have you ever met such issue that the nova-compute service looks hanging there and not able to boot instance? When creating an instance, we can only see logs like below and there is NOT any information. 2021-04-23 02:39:00.252 1 DEBUG nova.compute.manager [req-a2ed90b6-792f-48e1-ba7f-e1e35d9537c2 373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e 1ee7955a2eaf4c86bcc3e650f2a8e2a7 - fc86abb50a684911a30f7955d386a3ea fc86abb50a684911a30f7955d386a3ea] [instance: e0e77edc-99b4-473e-b318-8e6f04428cda] Starting instance... _do_build_and_run_instance /usr/lib/python3.7/site-packages/nova/compute/manager.py:2202^[[00m 2021-04-23 03:03:04.927 1 DEBUG oslo_concurrency.lockutils [req-50659582-ad9b-4c17-bbb2-254d5e1141f9 373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e 1ee7955a2eaf4c86bcc3e650f2a8e2a7 - fc86abb50a684911a30f7955d386a3ea fc86abb50a684911a30f7955d386a3ea] Lock "a3619b50-3704-4f3e-b908-d525a41756eb" acquired by "nova.compute.manager.ComputeManager.build_and_run_instance.<locals>._locked_do_build_and_run_instance" :: waited 0.001s inner /usr/lib/python3.7/site-packages/oslo_concurrency/lockutils.py:327 There is NO other messages, including the periodically tasks. If I sent a request to create another instance, I can only see another _do_build_and_run_instance log. 2021-04-23 03:03:05.061 1 DEBUG nova.compute.manager [req-50659582-ad9b-4c17-bbb2-254d5e1141f9 373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e 1ee7955a2eaf4c86bcc3e650f2a8e2a7 - fc86abb50a684911a30f7955d386a3ea fc86abb50a684911a30f7955d386a3ea] [instance: a3619b50-3704-4f3e-b908-d525a41756eb] Starting instance... _do_build_and_run_instance /usr/lib/python3.7/site-packages/nova/compute/manager.py:2202^[[00m 2021-04-23 03:32:44.718 1 DEBUG oslo_concurrency.lockutils [req-c7857cb3-02ae-4c7b-92d7-b2ec178c1b13 373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e 1ee7955a2eaf4c86bcc3e650f2a8e2a7 - fc86abb50a684911a30f7955d386a3ea fc86abb50a684911a30f7955d386a3ea] Lock "3b07a6eb-12bb-4d19-9302-25ea3e746944" acquired by "nova.compute.manager.ComputeManager.build_and_run_instance.<locals>._locked_do_build_and_run_instance" :: waited 0.001s inner /usr/lib/python3.7/site-packages/oslo_concurrency/lockutils.py:327 I am sure the compute service is still running as I can see the heart-beat time changes correctly. From the rabbitmq message, It looks the code goes here nova/compute/manager.py def _build_and_run_instance(self, context, instance, image, injected_files, admin_password, requested_networks, security_groups, block_device_mapping, node, limits, filter_properties, request_spec=None): image_name = image.get('name') self._notify_about_instance_usage(context, instance, 'create.start', extra_usage_info={'image_name': image_name}) compute_utils.notify_about_instance_create( context, instance, self.host, phase=fields.NotificationPhase.START, bdms=block_device_mapping) as I can see a message with "event_type": "compute.instance.create.start" INFO:root:Body: {'oslo.version': '2.0', 'oslo.message': '{"message_id": "0ef11509-7a65-46b8-ac7e-ed6482fc527d", "publisher_id": "compute.compute01", "event_type": "compute.instance.create.start", "priority": "INFO", "payload": {"tenant_id": "1ee7955a2eaf4c86bcc3e650f2a8e2a7", "user_id": "373cb863547407cf3b99034b3b66395e76c137b40f905e7a61e25b1f97df4f3e", "instance_id": "3b07a6eb-12bb-4d19-9302-25ea3e746944", "display_name": "yingji-06", "reservation_id": "r-f8iphdcf", "hostname": "yingji-06", "instance_type": "m1.tiny", "instance_type_id": 15, "instance_flavor_id": "4d5644e1-c561-4b6c-952c-f4dd93c87948", "architecture": null, "memory_mb": 512, "disk_gb": 1, "vcpus": 1, "root_gb": 1, "ephemeral_gb": 0, "host": null, "node": null, "availability_zone": "nova", "cell_name": "", "created_at": "2021-04-23 03:32:39+00:00", "terminated_at": "", "deleted_at": "", "launched_at": "", "image_ref_url": "https://192.168.111.160:9292//images/303a325f-048 This issue is not always reproducible and restarting the compute service can work around this. Could you please give any suggestion on how to resolve this issue or how I can investigate ? Yingji.

2 5

[neutron] Drivers meeting agenda - 30.04.2021
by Slawek Kaplonski 29 Apr '21

29 Apr '21

Hi, Agenda for our tomorrow's drivers meeting is available at https://wiki.openstack.org/wiki/ Meetings/NeutronDrivers[1] We have 1 RFE to discuss: - https://bugs.launchpad.net/neutron/+bug/1922716[2] It was already discussed briefly during the PTG last week but let's get it official during the drivers meeting :) Have a great day and see You all tomorrow. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers [2] https://bugs.launchpad.net/neutron/+bug/1922716

1 0