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

[kuryr] vPTG April 2021
by Maysa De Macedo Souza 23 Apr '21

23 Apr '21

Hello, Two sessions were scheduled for Kuryr on the upcoming PTG: - 7-8 UTC on April 20 - 2-3 UTC on April 22 Everyone is more than welcome to join the sessions and check our future plans, give feedback or discuss anything regarding Kuryr. Even though participation is free registration is needed[1]. Regards, Maysa Macedo. [1] https://april2021-ptg.eventbrite.com

2 2

[largescale-sig] PTG meeting: April 21, 15utc
by Thierry Carrez 23 Apr '21

23 Apr '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday at 15utc in the Ocata meeting room from the virtual PTG[1]. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210421T15 Please register[2] to the PTG if you haven't already, it will give you access to communications explaining how to join. We'll do a general presentation of the Large Scale SIG activities, show off our "Large Scale Journey" documentation, and discuss the topics of our next video meeting(s). Feel free to add other topics to our PTG meeting agenda at: https://etherpad.opendev.org/p/apr2021-ptg-large-scale See you there! [1] http://ptg.openstack.org/ptg.html [2] https://www.openstack.org/ptg/ Regards, -- Thierry Carrez

1 1

[ironic] Ironic Whiteboard v2 call for reviews
by Jay Faulkner 23 Apr '21

23 Apr '21

Hi all, Iury and I spent some time this morning updating the Ironic whiteboard etherpad to include more immediately useful information to contributors. We placed this updated whiteboard at https://etherpad.opendev.org/p/IronicWhiteBoardv2 -- our approach was to prune any outdated/broken links or information, and focus on making the first part of the whiteboard an easy one-click place for folks to see easy ways to contribute. All the rest of the information was carried over and reformatted. Once there is consensus from the team about this being a positive change, we should either replace the existing IronicWhiteBoard with the contents of the v2 page, or just update links to point to the new one instead. What do you all think? Thanks, Jay Faulkner

4 6

Placement service error on one of the controller nodes
by Shalabh Goel 22 Apr '21

22 Apr '21

Hi, I am setting up an Openstack environment with 2 controller nodes. I have installed placement service on both by following the steps from https://docs.openstack.org/placement/victoria/install/install-ubuntu.html#c… My first node is 192.168.2.14 and second is 192.168.2.15 with the virtual IP as 192.168.2.100 on which haproxy is used for listening. After restarting apache2 service, placement service is running on one first node ( 192.168.2.14) but is giving the following error on second one ( 192.168.2.15): 2021-04-23 10:39:03.314524 2021-04-23 10:39:03.314 8299 WARNING placement.db_api [-] TransactionFactory already started, not reconfiguring.\x1b[00m 2021-04-23 10:39:03.322774 2021-04-23 10:39:03.322 8299 WARNING keystonemiddleware.auth_token [-] AuthToken middleware is set with keystone_authtoken.service_token_roles_required set to False. This is backwards compatible but deprecated behaviour. Pl ease set this to True.\x1b[00m 2021-04-23 10:39:03.391538 2021-04-23 10:39:03.391 8299 WARNING keystonemiddleware.auth_token [-] Configuring www_authenticat e_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint \x1b[00m 2021-04-23 10:39:03.394729 mod_wsgi (pid=8299): Failed to exec Python script file '/usr/bin/placement-api'. 2021-04-23 10:39:03.394771 mod_wsgi (pid=8299): Exception occurred processing WSGI script '/usr/bin/placement-api'. The second issue is that I am not able to use openstack compute command. It throws authentication error but I am able to use other openstack commands. I found this line on placement-api log in apache directory 2021-04-23 10:46:08.450216 2021-04-23 10:46:08.449 1421 WARNING keystonemiddleware.auth_token [req-f17428d0-183f-4e3d-8343-74b04dad7944 - - - - -] Authorization failed for token: keystonemiddleware.auth_token._exceptions.InvalidToken\x1b[00 How can I solve these issues. Are any other details needed? Thanks -- Shalabh Goel

1 0

Regarding whether sushy will support etag
by hus.fnst＠fujitsu.com 22 Apr '21

22 Apr '21

Dear maintainers: Hello, I am Hu Shuai from FNST. I am sending this email to know if sushy<https://opendev.org/openstack/sushy> will support etag<http://redfish.dmtf.org/schemas/DSP0266_1.11.0.html#etags>. For now sushy does not support etag. However etag is useful for reducing network data and redfish dmtf organization also recommends redfish to support etag. In addition, I raised an issue<https://storyboard.openstack.org/#!/story/2008810> about this question before but I have not received a reply. Thanks for your reading and I am looking forward to your opinions about this question. Best regards! Hu Shuai

1 0

Diversity & Inclusion Social Hour at the PTG sponsored by RDO
by Kendall Waters 22 Apr '21

22 Apr '21

Hey everyone, On behalf of the RDO Community, please join us for an hour of Trivia on Thursday April 22 at 17:00 UTC. We will have trivia related to OpenStack and the other OIF projects as well as the cities we've held events. Time permitting we'll have some Pop Culture trivia as well. Prizes for the first 3 placings and registration is Free! https://eventyay.com/e/5f05de57 <https://eventyay.com/e/5f05de57> Cheers, Kendall Kendall Waters Perez Community Partnerships Manager Open Infrastructure Foundation

1 0

RE: [kolla] VM build fails after Train-Ussuri upgrade
by Braden, Albert 22 Apr '21

22 Apr '21

Can anyone help with this upgrade issue? From: Braden, Albert Sent: Monday, April 19, 2021 8:20 AM To: openstack-discuss(a)lists.openstack.org Subject: [kolla] VM build fails after Train-Ussuri upgrade I upgraded my Train test cluster to Ussuri following these instructions: OpenStack Docs: Operating Kolla<https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html#u…> The upgrade completed successfully with no failures, and the existing VMs are fine, but new VM build fails with rados.Rados.connect\nrados.PermissionDeniedError: Ubuntu Pastebin<https://paste.ubuntu.com/p/MJhzgjYbW8/> I'm running external ceph so I looked at this document: OpenStack Docs: External Ceph<https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-…> It says that I need the following in /etc/kolla/config/glance/ceph.conf: auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx I didn't have that, so I added it and then redeployed, but still can't build VMs. I tried adding the same to all copies of ceph.conf and redeployed again, but that didn't help. Does anything else need to change in my ceph config when upgrading from Train to Ussuri? I see some cryptic talk about ceph in the release notes but it's not obvious what I'm being asked to change: OpenStack Docs: Ussuri Series Release Notes<https://docs.openstack.org/releasenotes/kolla-ansible/ussuri.html#relnotes-…> I read the bug that it refers to: Bug #1904062 "external ceph cinder volume config breaks volumes ..." : Bugs : kolla-ansible (launchpad.net)<https://bugs.launchpad.net/kolla-ansible/+bug/1904062> But I already have "backend_host=rbd:volumes" so I don't think I'm hitting that. Also I read these sections but I don't see anything obvious here that needs to be changed: * For cinder (cinder-volume and cinder-backup), glance-api and manila keyrings behavior has changed and Kolla Ansible deployment will not copy those keys using wildcards (ceph.*), instead will use newly introduced variables. Your environment may render unusable after an upgrade if your keys in /etc/kolla/config do not match default values for introduced variables. * The default behavior for generating the cinder.conf template has changed. An rbd-1 section will be generated when external Ceph functionality is used, i.e. cinder_backend_ceph is set to true. Previously it was only included when Kolla Ansible internal Ceph deployment mechanism was used. * The rbd section of nova.conf for nova-compute is now generated when nova_backend is set to "rbd". Previously it was only generated when both enable_ceph was "yes" and nova_backend was set to "rbd". My ceph keys have the default name and are in the default locations. I have cinder_backend_ceph: "yes". I don't have a nova_backend setting but I have nova_backend_ceph: "yes" I added nova_backend: "rbd" and redeployed and now I get a different error: rados.Rados.connect\nrados.ObjectNotFound Ubuntu Pastebin<https://paste.ubuntu.com/p/2kdKCW7npw/> I apologize for the nonsense below. I have not been able to stop it from being attached to my external emails. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

1 0

[nova][placement] introducing review priority label in gerrit
by Balazs Gibizer 22 Apr '21

22 Apr '21

Hi, As we discussed yesterday in the retro we would like to start using the review priority label in gerrit as a replacement of the runway process. Sean proposed the project config changes for this[1]. I added couple of questions / suggestions to that patch to start a discussion about the process. Let's try to agree in the review. Then I will document the process in tree. Cheers, gibi [1] https://review.opendev.org/c/openstack/project-config/+/787523

1 0

unable to access internet in instance
by cloud learner 22 Apr '21

22 Apr '21

Dear All, I have installed rocky on centos 7, as documented at openstack with 2 node controller and compute nodes, as mentioned in the document used vxlan and verified all the steps as mentioned in the document and all things are working fine but i am unable to access the internet in instances. kindly help me sort out this issue. Thanks

2 1

RE: cinder + Unity
by Huang, Yong 22 Apr '21

22 Apr '21

Hi Albert, Could you execute the `cinder get-pools` command to check if Unity driver report the valid pools correctly? the output should be: -------------------------------------------------- stack@ubuntu-xenial:/opt/stack/cinder$ cinder get-pools +----------+--------------------------------+ | Property | Value | +----------+--------------------------------+ | name | ubuntu-xenial@unity#Flash_Pool | +----------+--------------------------------+ +----------+---------------------------------+ | Property | Value | +----------+---------------------------------+ | name | ubuntu-xenial@unity#Manila_Pool | +----------+---------------------------------+ +----------+---------------------------------+ | Property | Value | +----------+---------------------------------+ | name | ubuntu-xenial@unity#Cinder_Pool | +----------+---------------------------------+ -------------------------------------------------- If no valid pools, one possibility is Unity driver not initialized successfully, if the driver initialized successfully, there should be a log in cinder-volume.log like: -------------------------------------------------- Apr 21 03:20:07 ubuntu-xenial cinder-volume[29607]: INFO cinder.volume.manager [None req-4b345a29-0d78-4cf7-8bae-ae541a48aaf3 None None] Driver post RPC initialization completed successfully. -------------------------------------------------- Did you install the storops library which Unity driver relies on? Please check the version info of storops: -------------------------------------------------- stack@ubuntu-xenial:/opt/stack/cinder$ pip show storops Name: storops Version: 1.2.8 Summary: Python API for VNX and Unity. Home-page: https://github.com/emc-openstack/storops Author: Cedric Zhuang Author-email: cedric.zhuang(a)gmail.com<mailto:cedric.zhuang@gmail.com> License: Apache Software License Location: /usr/local/lib/python2.7/dist-packages Requires: requests, python-dateutil, persist-queue, cachez, bitmath, enum34, six, PyYAML, retryz -------------------------------------------------- Thanks Yong Huang [EXTERNAL EMAIL] Hi Albert, On Mon, Apr 19, 2021 at 11:45 PM Albert Shih <Albert.Shih(a)obspm.fr<mailto:Albert.Shih@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 [keystone.private.fqdn]<https://urldefense.com/v3/__http:/keystone.private.FQDN:5000/v3__;!!LpKI!x3…> auth_url = http://keystone.private.FQDN:5000 [keystone.private.fqdn]<https://urldefense.com/v3/__http:/keystone.private.FQDN:5000__;!!LpKI!x37Ut…> identity_uri = http://keystone.private.FQDN:5000 [keystone.private.fqdn]<https://urldefense.com/v3/__http:/keystone.private.FQDN:5000__;!!LpKI!x37Ut…> 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

1 0