June 2021 - openstack-discuss - lists.openstack.org

[kayobe][train] kolla_copy_ca_into_containers variable
by Tony Pearce 21 Jun '21

21 Jun '21

I have deployed Train with Kayobe. I'd like to enable SSL using a cert which is signed but NOT by a public CA. This means I need to add the CA cert to the containers. I came across this doc [1] and I wanted to ask / discover when this variable comes into play "kolla_copy_ca_into_containers"? Does this variable work only from Victoria onwards or will it work in Train? Do I require to have a "seed" to build containers, to enable this cert copy into containers? (kayobe overcloud container image build). OR if I do "kayobe overcloud container image pull" will the cert be copied at that point? [1] OpenStack Docs: TLS <https://docs.openstack.org/kolla-ansible/victoria/admin/tls.html> Thanks and regards, Tony Pearce

2 2

Nova shows incorrect VM status when compute is down.
by Ramesh Ramanathan B 20 Jun '21

20 Jun '21

Dear All, One observation we have while using Open Stack Rocky is, when a compute node goes down, the VM status still shows active (the servers running in the compute node that went down). Is this the expected behavior? Any configurations required to get the right status. In the attached image the compute is down, but the VM status still shows active. We are running a data center so it is not practical to run nova reset-state for all the servers. Is there an API to force update Nova to show the correct status? Or any configurations missing that is causing this? Thanks Regards, Ramesh ________________________________ Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. 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 email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version. ________________________________

3 3

[nova] SCS standardized flavor naming
by Kurt Garloff 19 Jun '21

19 Jun '21

Hi, we (SCS) are working on defining a fully open source cloud and container stack as part of the Gaia-X[1] project. The intention is to provide a common well-standardized way to deploy, manage, configure, and operate the needed software. The vision is to have a network of federated clouds that can be used as one, which requires IAM federation and a high level of compatibility and uniformity. Our project is called Sovereign Cloud Stack (SCS)[2]. Obviously, we are using existing open source projects from the OIF, the CNCF and others and are seeking alignment with these communities. Some experts well-known in the OpenStack universe are participating in our effort. On the OpenStack side, we are using OSISM[3] which leverages kolla-ansible. We would like to seek your input and feedback into our attempt of defining a standardized naming scheme for flavors and a list of standard flavors available in all clouds that deliver SCS-compliant IaaS. Find the draft proposal at https://github.com/SovereignCloudStack/Operational-Docs/blob/main/flavor-na… We prefer feedback as github issues and/or PRs. Knowing that the OpenStack community prefers gerrit, we'll of course also incorporate any comment we get via this mailing list into our thinking. We hope you can accept us pasting content from mails into github issues, so we create a track record of the taken decisions. (Please indicate if this is not OK for you and we'll refrain from doing so.) Before you ask why we believe the proposal is useful: We are perfectly aware that it is possible to discover flavor properties; however, in many automation recipes (playbooks, terraform vars etc) we find flavor names encoded and it is one pain point having to adapt them on every cloud that you use. So we want to have some uniformity on this across SCS clouds. (With similar reasoning, expect a image naming and image metadata proposal next.) We are looking for feedback in two directions: (1) If you are aware of similar efforts to standardize flavor naming, please point us to it, so we can seek contact and align. (2) Please look at the proposal itself. When looking into the details how we specify how to optionally(!) encode a number of details into flavor names, please keep in mind that this is indeed optional. We expect most flavor names to be as simple as SCS-4V:8:20 or even SCS-4V:8, even though complicated SCS-8C:32:2x200S-bms-i2-GNa:64-ib [4] is possible for clouds that provide that level of differentiation and want/need to expose this via the flavor name. Of course, input from existing providers of OpenStack infrastructure is particularly valuable. Feedback welcome! [1] https://gaia-x.eu/ [2] https://scs.community/ [3] https://osism.de/ [4] In case you wonder: 8 dedicated cores, 32GiB RAM, 2x200GB SSD disks on bare metal sys, intel Cascade Lake, nVidia GPU with 64 Ampere SMs and InfiniBand. PS: Cc'ing some folks who have contributed to this. -- Kurt Garloff CTO Sovereign Cloud Stack OSB Alliance e.V.

2 3

[all][tc] What's happening in Technical Committee: summary 18th June, 21: Reading: 5 min
by Ghanshyam Mann 18 Jun '21

18 Jun '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Deprecated devstack-gate project[1] * Updated project-team-guide for the meeting channel preference[2] * TC voted the Y release proposed names and forwarded it for the next step of trademark checks. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-06-17-15.00.log.html * We will have next week's meeting on June 24th, Thursday 15:00 UTC[3]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[4] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * One open review for ongoing activities[5]. Migration from Freenode to OFTC ----------------------------------------- * We are in 'Communicate with community' work where all projects need to update all contributor doc etc. Please finish this in your project and mark the progress in etherpad[6]. * I wrote a small blog in OpenStack blog[7]. * All the required work for this migration is tracked in this etherpad[6] 'Y' release naming process ------------------------------- * Y release naming election is closed now. As a last step, the foundation is doing trademark checks on elected ranking. Retiring panko ----------------- * panko project is in process of retirement[8] Test support for TLS default: ---------------------------------- Rico has started a separate email thread over testing with tls-proxy enabled[9], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. Retiring governance's in-active repos ------------------------------------------- The Technical Committee retiring the governance's in-active repos which are not required in current structure[10]. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[11]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [12] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [13] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/795385 [2] https://docs.openstack.org/project-team-guide/open-community.html#public-me… [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4] https://etherpad.opendev.org/p/tc-xena-tracker [5] https://review.opendev.org/q/project:openstack/governance+status:open [6] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc [7] https://www.openstack.org/blog/the-openstack-community-irc-network-moved-to… [8] https://review.opendev.org/c/openstack/governance/+/796408 [9] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [10] https://etherpad.opendev.org/p/governance-repos-cleanup [11] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [12] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [13] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

Allowing custom role to add users
by Derek O keeffe 18 Jun '21

18 Jun '21

Hi all, I have created a role (project_admin) and have given access to anyone with that role to be allowed delete VM's in their group/project. I am trying to allow that user to now add or remove users in the domain but I can't seem to figure it out. I have edited the /etc/keystone/policy.yaml and added role:project_admin to the create user rule. Is this the way I should be doing it? Or does anyone have any advice? Thanks in advance and happy Friday :) Regards,Derek

1 1

packstack stuck at Testing if puppet apply is finished: x.x.x.x_compute.pp
by cloud learner 18 Jun '21

18 Jun '21

Dear Experts, I have installed the single node all in one using victoria, i have to add the new node in current setup, as documented at RDO site, we have to made changes in EXCLUDE_SERVER=controllerip CONFIG_COMPUTE_HOST=newcompute ip, i edited the answer file and run on the controller node but it stuck at Testing if puppet apply is finished: X.X.X.X_compute.pp And it does not show any error, kindly suggest. Thanks

1 0

ImportError: cannot import name greenpool
by Pete Zhang 18 Jun '21

18 Jun '21

Not sure if my previous email went through or not. Just resend it. We hit this error during "glance-manage db_sync": *ImportError: cannot import name greenpool.* Any idea what the root cause is and how to fix it? We have the following rpms installed (thought related). python2-greenlet-0.4.9-1.el7.x86_64.rpm python2-eventlet-0.18.4-2.el7.noarch.rpm python2-gevent-1.1.2-2.el7.x86_64.rpm Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Sleeping for 5 seconds between tries Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Exec try 10/10 Debug: Exec[neutron-db-sync](provider=posix): Executing 'neutron-db-manage upgrade heads' Debug: Executing: 'neutron-db-manage upgrade heads' Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Sleeping for 5 seconds between tries Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Traceback (most recent call last): Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/bin/neutron-db-manage", line 10, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: sys.exit(main()) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 657, in main Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: return_val |= bool(CONF.command.func(config, CONF.command.name <http://conf.command.name/>)) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 179, in do_upgrade Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: run_sanity_checks(config, revision) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 641, in run_sanity_checks Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: script_dir.run_env() Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/script/base.py", line 425, in run_env Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: util.load_python_file(self.dir, 'env.py') Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/util/pyfiles.py", line 81, in load_python_file Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: module = load_module_py(module_id, path) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/util/compat.py", line 141, in load_module_py Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: mod = imp.load_source(module_id, path, fp) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/env.py", line 24, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from neutron.db.migration.models import head # noqa Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/models/head.py", line 28, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from neutron.common import utils Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 35, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: import eventlet Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/eventlet/__init__.py", line 10, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from eventlet import convenience Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/eventlet/convenience.py", line 4, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from eventlet import greenpool Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: ImportError: cannot import name greenpool Error: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: Failed to call refresh: 'neutron-db-manage upgrade heads' returned 1 instead of one of [0] Error: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: 'neutron-db-manage upgrade heads' returned 1 instead of one of [0] Notice: /Stage[main]/Neutron::Deps/Anchor[neutron::dbsync::end]: Dependency Exec[neutron-db-sync] has failures: true -- <https://smart.salesforce.com/sig/peiyong.zhang//us_mb/default/link.html>

3 5

[neutron] Drivers meeting agenda for 18.06.2021
by Slawek Kaplonski 17 Jun '21

17 Jun '21

Hi, Agenda for tomorrow's drivers meeting is at [1]. We have one new RFE to discuss [2] - It's another approach to do OpenFlow based DVR :) We have also one new RFE [3] which I would like You to check and help triaging before we will discuss it in the drivers meeting. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda [2] https://bugs.launchpad.net/neutron/+bug/1931953 [3] https://bugs.launchpad.net/neutron/+bug/1932154 -- Slawek Kaplonski Principal Software Engineer Red Hat

4 7

[victoria][cinder ?] Dell Unity + Iscsi
by Albert Shih 17 Jun '21

17 Jun '21

Hi everyone I've a small openstack configuration with 4 computes nodes, a Dell Unity 480F for the storage. I'm using cinder with iscsi. Everything work when I create a instance. But some instance after few time are not reponsive. When I check on the hypervisor I can see [888240.310461] sd 14:0:0:2: [sdb] tag#120 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [888240.310493] sd 14:0:0:2: [sdb] tag#120 Sense Key : Illegal Request [current] [888240.310502] sd 14:0:0:2: [sdb] tag#120 Add. Sense: Logical unit not supported [888240.310510] sd 14:0:0:2: [sdb] tag#120 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [888240.310519] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0 [888240.311045] sd 14:0:0:2: [sdb] tag#121 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [888240.311050] sd 14:0:0:2: [sdb] tag#121 Sense Key : Illegal Request [current] [888240.311065] sd 14:0:0:2: [sdb] tag#121 Add. Sense: Logical unit not supported [888240.311070] sd 14:0:0:2: [sdb] tag#121 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [888240.311074] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0 [888240.342482] sd 14:0:0:2: [sdb] tag#70 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [888240.342490] sd 14:0:0:2: [sdb] tag#70 Sense Key : Illegal Request [current] [888240.342496] sd 14:0:0:2: [sdb] tag#70 Add. Sense: Logical unit not supported I check on the hypervisor, no error at all on the ethernet interface. I check on the switch, no error at all on the interface on the switch. No sure but it's seem the problem appear more often when the instance are doing nothing during some time. Every firmware, software on the Unity are uptodate. The 4 computes are exactly same, they run the same version of the nova-compute & OS & firmware on the hardware. Any clue ? Or place to search the problem ? Regards -- Albert SHIH Observatoire de Paris xmpp: jas(a)obspm.fr Heure local/Local time: Tue Jun 1 08:27:42 PM CEST 2021

3 3

[dev] Mass patch filing for skipdist->skipsdist in tox.ini
by Jeremy Stanley 17 Jun '21

17 Jun '21

I just pushed changes for the master branches of 26 projects under topic:tox-skipsdist to correct a frequent typographical error found in many projects' tox.ini files, which seems to get copied around a lot. I'm hoping by getting rid of the mistake everywhere we can stamp out future cargo-cult copies. The skipsdist option is set by many projects to avoid unilaterally building an sdist of the local tree every time tox is invoked, which can sometimes be quite time-consuming. Unfortunately it's all too easy to miss that 's' in the middle of the option name, and since tox ignores options it doesn't recognize, this ends up not having the intended effect. If you would rather keep the current behavior in your project, feel free to amend the change to one which removes the invalid "skipdist" line from your tox.ini instead. If you want to backport this to your stable branches, you can do that as well (it may even save some seconds on average tox-based job runtime); my main concern was more for people copying the mistake around, and it's far more likely they'll be copying from master branches so I didn't bother proposing any backports. -- Jeremy Stanley

1 0