- openstack-discuss - lists.openstack.org

[cinder] propose Sofia Enriquez for cinder core
by Brian Rosmaita 30 Jun '21

30 Jun '21

Sofia Enriquez (enriquetaso on IRC) has been active the past few cycles submitting patches, doing reviews, and participating in the Cinder weekly meeting, PTGs, and midcycles. She has also been acting as the Cinder Bug Deputy for Xena and has been running the Bug Squad meeting each week. Something I particularly appreciate is that she has included the cinder-tempest-plugin in her range of patches and reviews. Cinder and its various deliverables make up a large code base. Sofia has demonstrated a willingness and capacity to learn about the code, and I anticipate that she will continue to deepen her cinder knowledge as she continues to work in the project. At the same time, I believe that she is self-aware enough to know the limits of her knowledge and can be trusted not to approve patches that she doesn't understand. Above all, she will bring some much needed review bandwidth to the project. In the absence of objections, I'll add Sofia to the core team just before the next Cinder team meeting (Wednesday, 30 June at 1400 UTC). Please communicate any concerns to me before that time. cheers, brian

10 10

[qa] Cancelling Office Hour on July 6th
by Martin Kopec 29 Jun '21

29 Jun '21

Hi everyone, we are cancelling the next Office Hour - July 6th - due to PTOs and public holidays. QA wiki page: https://wiki.openstack.org/wiki/QA#Projects Thanks, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[nova][osc][api-sig] How strict should our clients be?
by Stephen Finucane 29 Jun '21

29 Jun '21

Hey, We have an interesting problem that I wanted to poll opinions on. In OSC 5.5.0, we closed most of the gaps between novaclient and openstackclient. As part of these changes, we introduced validation of a number of requests such as validating enum-style values. For example, [1][2][3]. This validation already occurs on the server side, but by adding it to the client side we prevent users sending invalid requests to the server in the first place and allow users to discover the correct API behaviour from the client rather than having to read the API docs or use trial and error. Now, an issue has been opened against OSC. Apparently someone has been relying on a bug in Nova to pass a different value to the API that what the schema should have allowed, and they are dismayed that the client no longer allows them to do this. They have asked [4][5] that we relax the client-side validation to allow them to continue relying on this bug. As you can probably tell from my comments, this seems to me to be an open and shut case: you shouldn't fork an OpenStack API and you shouldn't side-step validation. However, I wanted to see if anyone disagreed and thought there was merit in loose or no validation of API requests made via our clients. Let me know what you think, Stephen [1] https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackcli… [2] https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackcli… [3] https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackcli… [4] https://storyboard.openstack.org/#!/story/2008975 [5] https://github.com/openstack/python-openstackclient/commit/ab0b1fe885ee0a21…

9 16

[kolla][wallaby] pull error
by Ignazio Cassano 29 Jun '21

29 Jun '21

Hello, I pulled images two weeks ago and now I am trying to pull again but I got the followings error: TASK [common : include_tasks] ************************************************************************************************************************************************************************************* included: /usr/local/share/kolla-ansible/ansible/roles/common/tasks/pull.yml for localhost TASK [common : Pulling common images] ***************************************************************************************************************************************************************************** failed: [localhost] (item={'key': 'fluentd', 'value': {'container_name': 'fluentd', 'group': 'fluentd', 'enabled': True, 'image': 'kolla/ubuntu-source-fluentd:wallaby', 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS'}, 'volumes': ['/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/', 'fluentd_data:/var/lib/fluentd/data/'], 'dimensions': {}}}) => {"ansible_loop_var": "item", "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "kolla/ubuntu-source-fluentd:wallaby", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "/etc/timezone:/etc/timezone:ro", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_w1uzvf82/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 1195, in main\\n File \"/tmp/ansible_kolla_docker_payload_w1uzvf82/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 288, in __init__\\n File \"/usr/local/lib/python3.8/dist-packages/docker/api/client.py\", line 131, in __init__\\n self._auth_configs = auth.load_config(\\nTypeError: load_config() got an unexpected keyword argument \\'config_dict\\'\\n'"} failed: [localhost] (item={'key': 'kolla-toolbox', 'value': {'container_name': 'kolla_toolbox', 'group': 'kolla-toolbox', 'enabled': True, 'image': 'kolla/ubuntu-source-kolla-toolbox:wallaby', 'environment': {'ANSIBLE_NOCOLOR': '1', 'ANSIBLE_LIBRARY': '/usr/share/ansible'}, 'privileged': True, 'volumes': ['/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', '/dev/:/dev/', '/run/:/run/:shared', 'kolla_logs:/var/log/kolla/', '/run/openvswitch:/run/openvswitch:shared'], 'dimensions': {}}}) => {"ansible_loop_var": "item", "changed": true, "item": {"key": "kolla-toolbox", "value": {"container_name": "kolla_toolbox", "dimensions": {}, "enabled": true, "environment": {"ANSIBLE_LIBRARY": "/usr/share/ansible", "ANSIBLE_NOCOLOR": "1"}, "group": "kolla-toolbox", "image": "kolla/ubuntu-source-kolla-toolbox:wallaby", "privileged": true, "volumes": ["/etc/kolla/kolla-toolbox/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "/etc/timezone:/etc/timezone:ro", "/dev/:/dev/", "/run/:/run/:shared", "kolla_logs:/var/log/kolla/", "/run/openvswitch:/run/openvswitch:shared"]}}, "msg": "'Traceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_u6x9d04r/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 1195, in main\\n File \"/tmp/ansible_kolla_docker_payload_u6x9d04r/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 288, in __init__\\n File \"/usr/local/lib/python3.8/dist-packages/docker/api/client.py\", line 131, in __init__\\n self._auth_configs = auth.load_config(\\nTypeError: load_config() got an unexpected keyword argument \\'config_dict\\'\\n'"} failed: [localhost] (item={'key': 'cron', 'value': {'container_name': 'cron', 'group': 'cron', 'enabled': True, 'image': 'kolla/ubuntu-source-cron:wallaby', 'environment': {'DUMMY_ENVIRONMENT': 'kolla_useless_env'}, 'volumes': ['/etc/kolla/cron/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}}}) => {"ansible_loop_var": "item", "changed": true, "item": {"key": "cron", "value": {"container_name": "cron", "dimensions": {}, "enabled": true, "environment": {"DUMMY_ENVIRONMENT": "kolla_useless_env"}, "group": "cron", "image": "kolla/ubuntu-source-cron:wallaby", "volumes": ["/etc/kolla/cron/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "/etc/timezone:/etc/timezone:ro", "kolla_logs:/var/log/kolla/"]}}, "msg": "'Traceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_z0tqur4o/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 1195, in main\\n File \"/tmp/ansible_kolla_docker_payload_z0tqur4o/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 288, in __init__\\n File \"/usr/local/lib/python3.8/dist-packages/docker/api/client.py\", line 131, in __init__\\n self._auth_configs = auth.load_config(\\nTypeError: load_config() got an unexpected keyword argument \\'config_dict\\'\\n'"} PLAY RECAP ******************************************************************************************************************************************************************************************************** localhost : ok=5 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 Any help, please ? Ignazio

1 1

[masakari] PTL on vacations, next two meetings cancelled
by Radosław Piliszek 29 Jun '21

29 Jun '21

Hello, Propagating this information from today's meeting: The next two Masakari meetings (July 6 and 13) are cancelled because I will be on vacations. Kind regards, -yoctozepto

1 0

[cinder] reminder: this week's meeting in video+IRC
by Brian Rosmaita 29 Jun '21

29 Jun '21

Quick reminder that this week's Cinder team meeting on Wednesday 30 June, being the final meeting of the month, will be held in both videoconference and IRC at the regularly scheduled time of 1400 UTC. These are the video meeting rules we've agreed to: * Everyone will keep IRC open during the meeting. * We'll take notes in IRC to leave a record similar to what we have for our regular IRC meetings. * Some people are more comfortable communicating in written English. So at any point, any attendee may request that the discussion of the current topic be conducted entirely in IRC. * The meeting will be recorded. connection info: https://bluejeans.com/3228528973 meeting agenda: https://etherpad.opendev.org/p/cinder-xena-meetings cheers, brian

1 0

October 2021 PTG Dates & Registration
by Ashlee Ferguson 29 Jun '21

29 Jun '21

Hi everyone, We're happy to announce the next virtual PTG[1] will take place October 18-22, 2021! Registration is now open[2]. The virtual PTG is free to attend, but make sure to register so you recieve important communications like schedules, passwords, and other relevant updates. Next week, keep an eye out for info regarding team sign-ups. Can't wait to see you all there! Ashlee [1] https://www.openstack.org/ptg/ [2] https://openinfra-ptg.eventbrite.com

1 0

[neutron] bug deputy report (Jun 21-27)
by Akihiro Motoki 29 Jun '21

29 Jun '21

Hi team, I was a bug deputy in neutron last week. Sorry for late. Summary ======= The following needs attentions from OVN and DVR folks. - 1 bug on OVN driver related to security group rule deletion needs investigation - 2 DVR-specific bugs need to be triaged by L3 DVR folks I also marked a bug on explicit deletion of a port used by nova as RFE. Needs attentions ================ * [OVN] neutron with ovn returns Conflict on security group rules delete https://bugs.launchpad.net/bugs/1933638 Medium, unassigned, specific to OVN mechanism driver * Untriaged specific to DVR * snat arp entry missing in qrouter namespace https://bugs.launchpad.net/neutron/+bug/1933092 * Unable to update mtu on DVR snat https://bugs.launchpad.net/bugs/1933273 * OSError: Premature eof waiting for privileged process error in Ussuri release of Neutron https://bugs.launchpad.net/neutron/+bug/1933813 Collecting more information from the bug author * Unassigned Gate failure * [Fullstack] TestLegacyL3Agent.test_mtu_update fails sometimes https://bugs.launchpad.net/neutron/+bug/1933234 Bugs with assignees =================== * New with assignees * [OVN] Live migration of network sensitive VMs breaks communication https://bugs.launchpad.net/neutron/+bug/1933517 New, Medium, assigned to ralonsoh * Explicitly provide a DB context when executing a DB transaction https://bugs.launchpad.net/neutron/+bug/1933321 New, Wishlist, this is a tracker for all patches to decorate db transactions * Confirmed/Triaged * Unable to show security groups for non-admin users if custom policies using. https://bugs.launchpad.net/bugs/1933242 Confirmed, High, Assigned to amotoki * missing global_request_id in neutron_lib context from_dict method https://bugs.launchpad.net/bugs/1933802 Low, Confirmed, potential improvement in neutron-lib Context.from_dict() Unassigned but amotoki can take care of it. * In Progress * [OVN] The type of ovn controller is not recognized as a gateway agent https://bugs.launchpad.net/bugs/1933401 * L3 DB FloatingIP callbacks improvements https://bugs.launchpad.net/bugs/1933502 * Stable branches * [stable/train] Backported patch introduced incompatible method calls for py2.7 https://bugs.launchpad.net/bugs/1933366 High, New, assigned to ralonsoh RFEs ==== * locked instance can be rendered broken by deleting port https://bugs.launchpad.net/bugs/1930866 It was filed as a normal bug, but it requires an API change, so I triaged it as RFE. * [RFE] Add distributed datapath for metadata https://bugs.launchpad.net/neutron/+bug/1933222

1 0

Error creating VMs
by open infra 28 Jun '21

28 Jun '21

Hi After setting up OpenStack environment using STX R5 (two controllers, two storage nodes and one worker), I have deployed a VM. VM ended up with ERROR status. I highly appreciate if someone can guide to dig further (what logs to check ) or to fix this issue. http://paste.openstack.org/show/806626/ Regards Danishka

2 14

[openstack-helm] No Meeting Tomorrow
by Gage Hugo 28 Jun '21

28 Jun '21

Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow, the meeting is cancelled. Our next meeting will be July 06th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

How to get information about the available space in all cinder-volume
by Salman Sheikh 28 Jun '21

28 Jun '21

Dear experts, I have made cinder-volume /dev/sdb on controller as well as compute node, how do i get the information of space available in cinder.

2 2

[cinder] OpenStack lvm and Shared Storage
by pradyumna borge 28 Jun '21

28 Jun '21

Hi, In a mulit-node setup do we need to provide shared storage via Cinder when setting up the second compute node? In a typical mulit-node setup we will have: 1. First node as Controller node acting as a Compute node too. This will have Cinder *lvm*. 2. Second node as Compute node. 1. Will this node have any storage via lvm? If yes then how will the first compute node access storage on the second node? 2. Likewise, how can the VMs on this second node access storage on the first compute node? My other questions are: 1. So if I spawn a VM on the second Compute node, where will the disks of the VM reside? 2. Can I attach attach a disk on the first node to a VM on the second node? 3. Do I have to configure NFS storge as shared storage for Cinder? 4. Does Cinder take care of sharing the disks (I dont think so) 5. What are the steps to setup devstack for multi-node and multi storage (nfs and lvm) ~ shree

3 2

[Ironic] No usptream meeting on July 5th
by Iury Gregory 28 Jun '21

28 Jun '21

Hello Ironicers! During our weekly meeting today we agreed that we will skip the next meeting due to holidays in the US and other countries! -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[dev][infra][tact-sig] Zuul 4.6.0 and associated job changes
by Jeremy Stanley 28 Jun '21

28 Jun '21

Today at 14:00 UTC the OpenDev Collaboratory upgraded its deployment of Zuul, coinciding with the 4.6.0 security release. This release disabled or changed a number of features which could previously be leveraged to take over executors or obtain decrypted copies of secret data, necessitating adjustments to some jobs. I think we've now addressed the majority of the central job resources which were impacted, but there are almost certainly less-frequently-exercised jobs which are still configured to do things which will no longer work. There were likely some strange-looking failures, particularly in promote and post pipeline builds, between 15:00 and 19:00 UTC today, so if you need something rerun for any reason please do reach out. The two main categories of new bugs which will need fixing are: * Use of Jinja2 templating in secret definitions * Setting ansible_connection, ansible_host, ansible_python_interpreter, ansible_shell_executable, or ansible_user The full release notes can be found in the release announcement here: http://lists.zuul-ci.org/pipermail/zuul-announce/2021-June/000096.html If you run into a new problem in one of your jobs and you believe it may be related to the above or similar fallout from the changes in Zuul 4.6.0 and need assistance, please don't hesitate to contact the TaCT SIG in the #openstack-infra channel on the OFTC IRC network or by replying to this mailing list thread. Apologies for any disruption this update may have caused, and thanks for your understanding. -- Jeremy Stanley

6 9

[kolla][monasca] thresh keeps dying
by Tomasz Rutkowski 28 Jun '21

28 Jun '21

can someone direct me where to search for the cause? as I understand failing to submit the topology to storm cluster shouldn't be final, and the process just dissapers there... + exec /opt/storm/bin/storm jar /monasca-thresh-source/monasca-thresh-stable-victoria/thresh/target/monasca-thresh-2.4.0-SNAPSHOT-shaded.jar -Djava.io.tmpdir=/var/lib/monasca-thresh/data monasca.thresh.ThresholdingEngine /etc/monasca/thresh-config.yml monasca-thresh Running: /usr/lib/jvm/java-8-openjdk-amd64/bin/java -client -Ddaemon.name= -Dstorm.options= -Dstorm.home=/opt/storm -Dstorm.log.dir=/var/log/kolla/storm -Djava.library.path=/usr/local/lib:/opt/local/lib:/usr/lib -Dstorm.conf.file= -cp /opt/storm/*:/opt/storm/lib/*:/opt/storm/extlib/*:/monasca-thresh-source/monasca-thresh-stable-victoria/thresh/target/monasca-thresh-2.4.0-SNAPSHOT-shaded.jar:/opt/storm/conf:/opt/storm/bin -Dstorm.jar=/monasca-thresh-source/monasca-thresh-stable-victoria/thresh/target/monasca-thresh-2.4.0-SNAPSHOT-shaded.jar -Dstorm.dependency.jars= -Dstorm.dependency.artifacts={} -Djava.io.tmpdir=/var/lib/monasca-thresh/data monasca.thresh.ThresholdingEngine /etc/monasca/thresh-config.yml monasca-thresh 687 [main] INFO m.t.ThresholdingEngine - -------- Version Information -------- 692 [main] INFO m.t.ThresholdingEngine - monasca-thresh-2.4.0-SNAPSHOT-2021-06-06T08:32:08-${buildNumber} 693 [main] INFO m.t.ThresholdingEngine - Instantiating ThresholdingEngine with config file: /etc/monasca/thresh-config.yml, topology: monasca-thresh 1000 [main] INFO o.h.v.i.u.Version - HV000001: Hibernate Validator 5.2.1.Final 1197 [main] INFO m.t.ThresholdingEngine - local set to false 1312 [main] INFO m.t.i.t.MetricSpout - Created 1340 [main] INFO m.t.i.t.EventSpout - EventSpout created 1516 [main] WARN o.a.s.u.Utils - STORM-VERSION new 1.2.2 old null 1516 [main] INFO m.t.ThresholdingEngine - submitting topology monasca-thresh to non-local storm cluster 1549 [main] INFO o.a.s.StormSubmitter - Generated ZooKeeper secret payload for MD5-digest: -7012431400424907995:-9108807134284416946 1728 [main] INFO o.a.s.u.NimbusClient - Found leader nimbus : storm1:6627 1751 [main] INFO o.a.s.s.a.AuthUtils - Got AutoCreds [] 1756 [main] INFO o.a.s.u.NimbusClient - Found leader nimbus : storm1:6627 Exception in thread "main" java.lang.RuntimeException: Topology with name `monasca-thresh` already exists on cluster at org.apache.storm.StormSubmitter.submitTopologyAs(StormSubmitter.java:237) at org.apache.storm.StormSubmitter.submitTopology(StormSubmitter.java:387) at org.apache.storm.StormSubmitter.submitTopology(StormSubmitter.java:159) at monasca.thresh.ThresholdingEngine.run(ThresholdingEngine.java:111) at monasca.thresh.ThresholdingEngine.main(ThresholdingEngine.java:82) regards -- Tomasz Rutkowski

2 2

[kolla-ansible] [swift] access denied to various APIs
by Bernd Bausch 28 Jun '21

28 Jun '21

I set up a cloud with the Victoria version of Kolla-Ansible. I enabled Swift and configured Swift as backend for Glance and Cinder-Backup. The Glance backend works, the Cinder-Backup backend doesn't. Furthermore, as a non-admin user I can't do anything with Swift. These two headscratchers that may or may not be related. I seek for help how to troubleshoot this. *Headscratcher 1*: Swift doesn't accept unauthenticated /info API, although expose_info is explicitly set to "true". This is why Cinder-Backup fails; it performs this API when starting up: curl http://192.168.122.253:8080/info {"error": {"code": 401, "title": "Unauthorized", "message": "The request you have made requires authentication."}} When I add a valid token, this works. *Headscratcher 2*: Swift refuses access except for the admin role. I get this when I don't have the admin role: $ source demorc.sh $ swift stat Account HEAD failed: http://192.168.122.253:8080/v1/AUTH_06d5618863294187bf46c611c0ebb4a7 403 Forbidden Failed Transaction ID: tx7e8d958e3c7b410880000-0060d81a25 To add insult to injury, I don't see relevant messages in the centralized Elasticsearch log, and logging does not go to any log files. Any thoughts? Thanks, Bernd

2 1

[wallaby][magnum] magnum-conductor service crash
by Ammad Syed 28 Jun '21

28 Jun '21

Hi, I am using openstack wallaby on ubuntu20.04. My service of magnum-conductor is getting crashed with below error in syslog of ubuntu. Jun 26 22:52:17 orchestration magnum-conductor[173714]: /usr/lib/python3/dist-packages/magnum/drivers/common/driver.py:38: PkgResourcesDeprecationWarning: Parameters to load are deprecated. Call .resolve and .require separately. Jun 26 22:52:17 orchestration magnum-conductor[173714]: yield entry_point, entry_point.load(require=False) Jun 26 22:52:17 orchestration magnum-conductor[173714]: /usr/lib/python3/dist-packages/kubernetes/client/apis/init.py:10: DeprecationWarning: The package kubernetes.client.apis is renamed and deprecated, use kubernetes.client.api instead (please note that the trailing s was removed). Jun 26 22:52:17 orchestration magnum-conductor[173714]: warnings.warn( Jun 26 22:52:17 orchestration magnum-conductor[173714]: /usr/lib/python3/dist-packages/magnum/drivers/common/driver.py:38: PkgResourcesDeprecationWarning: Parameters to load are deprecated. Call .resolve and .require separately. Jun 26 22:52:17 orchestration magnum-conductor[173714]: yield entry_point, entry_point.load(require=False) Jun 26 22:52:17 orchestration magnum-conductor[173714]: Traceback (most recent call last): Jun 26 22:52:17 orchestration magnum-conductor[173714]: File "/usr/lib/python3/dist-packages/eventlet/hubs/hub.py", line 476, in fire_timers Jun 26 22:52:17 orchestration magnum-conductor[173714]: timer() Jun 26 22:52:17 orchestration magnum-conductor[173714]: File "/usr/lib/python3/dist-packages/eventlet/hubs/timer.py", line 59, in call Jun 26 22:52:17 orchestration magnum-conductor[173714]: cb(*args, **kw) Jun 26 22:52:17 orchestration magnum-conductor[173714]: File "/usr/lib/python3/dist-packages/eventlet/semaphore.py", line 152, in _do_acquire Jun 26 22:52:17 orchestration magnum-conductor[173714]: waiter.switch() Jun 26 22:52:17 orchestration magnum-conductor[173714]: greenlet.error: cannot switch to a different thread Any advice how to fix it ? -- Regards, Ammad

1 0

[neutron-vpnaas][kolla-ansible][victoria] Growing memory consumption with only one VPN connection
by Adam Tomas 28 Jun '21

28 Jun '21

Hi, I have problem with neutron vpnaas - after enabling vpnaas plugin everything was ok at first. I was able to create VPN connection and communication is correct. But after a week of running vpnaas (only one VPN connection created/working!) I’ve noticed, that neutron-vpnaas takes more and more memory. I have 5 processes on each controller (there should be always five? Or it is changing dynamically?): 42435 1545384 0.6 8.6 5802516 5712412 ? S Jun15 110:50 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf 42435 1545389 0.6 8.5 5735832 5645856 ? S Jun15 112:16 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf 42435 1545378 0.5 8.5 5734192 5643620 ? S Jun15 108:09 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf 42435 1545372 0.5 8.5 5731128 5641436 ? S Jun15 109:07 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf 42435 1545369 0.6 8.4 5637084 5547392 ? S Jun15 114:21 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf now neutron_server takes over 27G of RAM on each controller: neutron_server running 10.2 27.2G After stopping all neutron containers and starting it again neutron takes a lot less memory: neutron_server running 0.5 583M but memory usage keeps growing (about 5-6 M every minute). What’s wrong? When I disable vpnaas globally there’s no problem with excessive memory usage, so it’s vpnaas for sure… Best regards Adam Tomas

1 0

[kolla] URGENT to cores - DO NOT MERGE patches
by Radosław Piliszek 27 Jun '21

27 Jun '21

Please DO NOT MERGE any changes until issues mentioned in thread [1] are resolved. The reason is that these cause the crucial jobs to never run. I see we have merged one job without proper testing already. [2] You can see only tox testing ran there. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023291.html [2] https://review.opendev.org/c/openstack/kolla-ansible/+/779204 -yoctozepto

1 1

[cinder] [replication] Error in cinder replication | Openstack Victoria
by Swogat Pradhan 25 Jun '21

25 Jun '21

Hi, I am trying to configure cinder replication with ceph as backend and i followed this URL to configure the cinder replication: https://netapp.io/2016/10/14/cinder-replication-netapp-perfect-cheesecake-r… and http://www.sebastien-han.fr/blog/2017/06/19/OpenStack-Cinder-configure-repl… i created a Volume type - REPL, with replication enabled <is> True and colume backend name parameter. But when i am trying to create a volume using the created volume type the volume is getting created in ceph but in cinder the status is showing error. and when checked log getting the following error: 2021-06-24 17:59:39.556 28472 ERROR cinder.volume.drivers.rbd [req-6e6b901e-f2dd-43a4-a089-6c734b279e17 d576181b6a444541b8ec7f37d750a4c1 a9ac2eba50d84d64ac44b179bbcc9183 - default default] Error creating rbd image volume-361f35c4-a589-4653-b404-fb93d2f598cf.: cinder.exception.ReplicationError: Volume 361f35c4-a589-4653-b404-fb93d2f598cf replication error: Failed to enable image replication I tried to create a volume using volume type- default and then later changed the volume type using command 'cinder retype' to the created volume type and it changed without any issue. I am using openstack victoria . With regards, Swogat Pradhan

4 5

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

25 Jun '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Deprecated panko and puppet-panko project[1] 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-24-15.00.log.html * We will have next week's meeting on July 1st, Thursday 15:00 UTC[2]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[3] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Five open review for ongoing activities[4]. Migration from Freenode to OFTC ----------------------------------------- * Not much progress on project side wiki/doc page which is only thing left for this migration. * All the required work for this migration is tracked in this etherpad[5] 'Y' release naming process ------------------------------- * Y release naming election is closed now. As a last step, the foundation is doing trademark checks on elected ranking. Deprecate OpenStack-Ansible nspawn repositories ------------------------------------------------------------ * OpenStack-Ansible nspawn repositories is in process of retirement[6] Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[7], 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[8]. Adding Ceph Dashboard charm to OpenStack charms --------------------------------------------------------------- * Proposal to add Ceph Dashboard charm to OpenStack charms[9] Other Changes ------------------ * Charter change to handle the vacant seat situation[10] * Add DPL model also in 'Appointing leaders' section[11] 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[12]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [13] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [14] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/796408 [2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [3] https://etherpad.opendev.org/p/tc-xena-tracker [4] https://review.opendev.org/q/project:openstack/governance+status:open [5] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc [7] https://review.opendev.org/c/openstack/governance/+/797731 [7] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [8] https://etherpad.opendev.org/p/governance-repos-cleanup [9] https://review.opendev.org/c/openstack/governance/+/797913 [10] https://review.opendev.org/c/openstack/governance/+/797912 [11] https://review.opendev.org/c/openstack/governance/+/797985 [12] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [13] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [14] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[tc][all][goal] Migrate RBAC Policy Format from JSON to YAML: COMPLETED
by Ghanshyam Mann 25 Jun '21

25 Jun '21

Hello Everyone, I am happy to update that we have completed the community wide goal for "Migrate RBAC Policy Format from JSON to YAML". - https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-f… Thanks to all the projects/contributors involved in this work. Completion Report: =============== * Projects completed: 33 * Projects do not need any changes: 16 * project left: 0 * This is the complete work we did for this goal: ** Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… ** Tracking Etherpad: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml -gmann

1 0

[nova][os-vif][stable] Adding os-vif-core to os-vif stable branches
by Stephen Finucane 25 Jun '21

25 Jun '21

Happy Friday, Per $subject, I'd like to propose that we add os-vif-core to the list of teams with +2 rights on os-vif stable branches. Currently this list is restricted to "Project Bootstrappers", nova-stable-maint and stable-maint-core. os-vif doesn't see many backports, but it is a rather specialist library that requires some domain-specific knowledge to grok and the existing stable reviewers typically insist on reviews from core reviewers before approving changes. By making this change, we can avoid this little dance. We have discussed this already on #openstack-nova, but if there are any concerns, please raise them now. If not, I'll seek to have the relevant changes merged to openstack/project-config by the end of next week. I'll post these changes shortly. Cheers, Stephen [1] https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.20…

3 3

[cinder] upcoming driver deadlines
by Brian Rosmaita 25 Jun '21

25 Jun '21

This is a reminder that the cinder New Driver Merge Deadline is Thursday 15 July 2021 [0]. Please make sure *right now* that you've filed a Launchpad blueprint for your driver and that your blueprint shows up in this list: https://blueprints.launchpad.net/cinder/xena (if it doesn't, contact me off list) If you're adding a new feature to a driver, you should also file a Lanuchpad blueprint (it helps us prioritize reviews). See the Xena release schedule for more info about the Cinder Driver Features Declaration [1]. New features for current drivers follow the regular Feature Freeze policy (that is, must be merged by Milestone 3). cheers, brian [0] https://releases.openstack.org/xena/schedule.html#x-cinder-driver-deadline [1] https://releases.openstack.org/xena/schedule.html#x-cinder-driver-features-…

1 0

[dev][nova] PCI IRQ Affinity for VMS with dedicated CPUs
by Soares Sarto, Ricardo 24 Jun '21

24 Jun '21

Hello Everyone, Does NOVA provide any intelligent affining of IRQs of PCI Devices to CPUs pinned to VMs? i.e. for VMs that have pci-passthrough interfaces to PCI devices and are using ‘dedicated’ CPU policy, does NOVA automatically affine the IRQs for those PCI devices the CPUs that are allocated to the VM? Furthermore, is there any flavor extraspec that can further scope the IRQ affinity of the PCI Devices to a subset of the VM’s dedicated cpus? If not, is this a new capability that the NOVA team would be open to? -rsoaress

2 1

[neutron] can floating IP port forwarding work when agent_mode is dvr or dvr_snat but on compute node?
by Yi Yang (杨燚)-云服务集团 24 Jun '21

24 Jun '21

Hi, folks I’m working on https://bugs.launchpad.net/neutron/+bug/1931953, per my check for neutron-specs/specs/rocky/port-forwarding.rst, it seems port forwarding function only can be done on network node, so I don’t think we need to do it on compute node, can anybody help confirm this? Per my understanding, if a FIP is set port forwarding to two VMS across two compute node, physical switch has no way to know which compute node it should send to if destination IP is this FIP, right? But on centralized mode, this isn’t an issue.

2 2

[ironic] Ansible deploy_interface error output
by Ivan Iotchenko 24 Jun '21

24 Jun '21

Hello We are using Ironic (Train) and Ansible deploy interface. Everything works just awesome and we were able to include all the things we need into deployment/undeployment process (with respect to flexibility provided by Ansible). However, there is an issue. If you have failures during the process - you will be presented with full Ansible output which can be large enough (and thus cut). Almost every failure requires you to review log files (Ironic/Ansible). This is fine if deployment is being done by Ironic admin or person who have required experience. For other users it can be a blocker. Usually you just cannot determine root cause from the error message in last_failure field, which you can get both from console or UI. Error output was pretty straightforward with direct deploy interface. Is there a way to made Ansible error output better? E.g. to make it short and descriptive (“DNS registration failed bla-bla-bla”) Thanks, Ivan

1 0

Regarding Bind server in ubuntu
by Adivya Singh 24 Jun '21

24 Jun '21

hi Team, I am facing one issue in Bind Server installation in ubuntu, I am not able to resolve the reserve DNS names , I am suspecting there is a issue in SOA , when i am doing dig from the public IP to the private subnet IP, it does not return anything like dig -x <Floating IP><private IP> regards Adivya Singh

2 1

[kolla] Wallaby releases available
by Mark Goddard 24 Jun '21

24 Jun '21

Hi, I'm pleased to announce the availability of the first Wallaby releases for all Kolla deliverables: * kolla 12.0.0 (https://docs.openstack.org/releasenotes/kolla/wallaby.html#relnotes-12-0-0-…) * kolla-ansible 12.0.0 (https://docs.openstack.org/releasenotes/kolla-ansible/wallaby.html#relnotes…) * kayobe 10.0.0 (https://docs.openstack.org/releasenotes/kayobe/wallaby.html#relnotes-10-0-0…) A lot of hard work was involved in these releases which add support for two new OS versions: CentOS Stream and Debian Bullseye. Many thanks to everyone who contributed to these releases. And now onto Xena! Thanks, Mark

1 0

[nova] SCS standardized flavor naming
by Dmitriy Rabotyagov 24 Jun '21

24 Jun '21

Hi! > The point is, a new customer will *not* spend time reading the spec. > Typically, they will want to just fire-up a VM quickly without reading > too much docs... While I find Thomases flavor naming also not really intuitive for customers - out of nvt4-a8-ram24-disk50-perf2 I could guess only disk size and amout of ram (is it in gygabytes?) but "SCS-16T:64:200s-GNa:64-ib" doesn't make any sense to me at all (if I haven't read [1] ofc). I totally agree that no user in Public cloud would read any spec before launching their VM and it would be super hard to force them to do so. So flavor naming should be as explicit and readable as possible and assuming that person who will use cloud has no idea about specs we're making. These specs should be designed for cloud providers to comply and have same standards so users feel comfortable and secure, but don't assume regular users to have special skills in reading what engineers come up to. If regular users would find this hard to use, companies might choose hapiness of customers over some compliance. As nova doesn't have any text description for flavors, so flavor name is everything we have to expose to the customers and it should be clean and readable from the first sight. > nvt4-a8-ram24-disk50-perf2 > > This means: > - nvt4: nvidia T4 GPU > - a8: AMD VCPU 8 (we also have i4 for example, for Intel) > - ram24: 24 GB of RAM > - disk50: 50 GB of local system disk > - perf2: level 2 of IOps / IO bandwidth So what I'd suggest to cover that usecase would be smth like: 8vCPU-24576RAM-50SSD-pGPU:T4-10kIOPS-EPYC4 > SCS-8C:32:2x200S-bms-i2-GNa:64-ib > [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. Would be probably smth like: 8pCPU-32768RAM-2x200SSD-2vGPU:A100-IB-Cascade [1] https://github.com/SovereignCloudStack/Operational-Docs/blob/main/flavor-na… -- Kind Regards, Dmitriy Rabotyagov

3 3

[all][tc] Technical Committee next weekly meeting on June 24th at 1500 UTC
by Ghanshyam Mann 24 Jun '21

24 Jun '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for June 24th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, June 23rd, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[nova][libvirt][cinder] Volume-based live migration and multi-attach
by Mariusz Karpiarz 24 Jun '21

24 Jun '21

Hi all, For live migration of volume-based instances (a Cinder volume used for the main OS disk) to work does the Cinder backend need to support multi-attach or at any point of the migration process are there multiple processes accessing the same volume?

2 1

[neutron] OVS tunnels and VLAN provider networks on the same interface
by Krzysztof Klimonda 24 Jun '21

24 Jun '21

Hi All, What is the best practice for sharing same interface between OVS tunnels and VLAN-based provider networks? For provider networks to work, I must "bind" entire interface to vswitchd, so that it can handle vlan bits, but this leaves me with a question of how to plug ovs tunnel interface (and os internal used for control<->compute communication, if shared). I have two ideas: 1) I can bind entire interface to ovs-vswitchd (in ip link output it's marked with "master ovs-system") and create vlan interfaces on top of that interface *in the system*. This seems to be working correctly in my lab tests. 2) I can create internal ports in vswitchd and plug them into ovs bridge - this will make the interface show up in the system, and I can configure it afterwards. In this setup I'm concerned with how packets from VMs to other computes will flow through the system - will they leave openvswitch to host system just to go back again to be sent through a tunnel? I've tried looking for some documentation regarding that, but came up empty - are there some links I could look at to get a better understanding of packet flow and best practices? Best Regards, -- Krzysztof Klimonda kklimonda(a)syntaxhighlighted.com

5 9

[keystone] "identity_provider failed validation" getting scoped token, on Rocky/Python3
by Marek Szuba 24 Jun '21

24 Jun '21

Dear everyone, I run a small OpenStack cloud on Debian Buster, using standard distro packages - i.e. Rocky. My Keystone is configured as a federated-identity Service Provider, with the IdP accessed using OpenID. Having got things working successfully using local users I went on to testing federation - and found out that using the OpenStack CLI to get a scoped token from an unscoped one reports a server error 500, and logging in to Horizon shows usage and event data couldn't be retrieved. On the server side, in both cases Keystone log shows the following: INFO keystone.common.wsgi [req-foo bar baz - Federated default] POST https://osc.example.com:5000/v3/auth/tokens ERROR keystone.common.wsgi [req-foo bar baz - Federated default] identity_provider failed validation: <function FederatedCredential.<lambda> at 0xdeadbeef>: ValueError: identity_provider failed validation: <function FederatedCredential.<lambda> at 0xdeadbeef> ERROR keystone.common.wsgi Traceback (most recent call last): ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/common/wsgi.py", line 148, in __call__ ERROR keystone.common.wsgi result = method(req, **params) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/auth/controllers.py", line 67, in authenticate_for_token ERROR keystone.common.wsgi self.authenticate(request, auth_info, auth_context) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/auth/controllers.py", line 236, in authenticate ERROR keystone.common.wsgi auth_info.get_method_data(method_name)) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/auth/plugins/token.py", line 46, in authenticate ERROR keystone.common.wsgi PROVIDERS.identity_api ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/auth/plugins/mapped.py", line 101, in handle_scoped_token ERROR keystone.common.wsgi send_notification(taxonomy.OUTCOME_SUCCESS) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/keystone/notifications.py", line 685, in send_saml_audit_notification ERROR keystone.common.wsgi user=user_id, groups=group_ids) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/pycadf/credential.py", line 84, in __init__ ERROR keystone.common.wsgi setattr(self, FED_CRED_KEYNAME_IDENTITY_PROVIDER, identity_provider) ERROR keystone.common.wsgi File "/usr/lib/python3/dist-packages/pycadf/cadftype.py", line 66, in __set__ ERROR keystone.common.wsgi (self.name, self.func)) ERROR keystone.common.wsgi ValueError: identity_provider failed validation: <function FederatedCredential.<lambda> at 0xdeadbeef> i.e. the request has succeeded but then things fall over when an audit notification is to be sent. Having poked around the sources of keystone.notifications.send_saml_audit_notifications() and the code it references, I found out the following: - the lambda function which triggers the error checks if 'identity_provider' is a six string type; - when this error occurs the value of 'identity_provider' is indeed the name of my IdP - but as *bytes* rather than str! - this doesn't happen every time this IdP name is used - if I add a simple identity_provider = identity_provider.decode('utf-8') to the relevant function I start getting errors suggesting that under some circumstances, 'identity_provider' is str as it should be. All in all, it seems like this particular bit of Keystone code in Rocky does not properly support Python3. Unfortunately an upgrade to a newer OpenStack version is non-trivial for me for several reasons, only some of which are under my control - and the stop-gap measure of having patched the relevant function with "if identity_provider is bytes, decode it to str" means I've had to put the relevant Debian package on hold, thus blocking potential updates. Therefore, I look forward to hearing from you any and all ideas which might help address this problem in less radical fashion. Thank you in advance! -- MS

1 0

Regarding dhcp not forwarding the IP in openstack
by Adivya Singh 24 Jun '21

24 Jun '21

Hi Team, I have a issue where, the dhcp are not forwarding the IP for some reason, and the dhcp are not responding properly in a hypervisor I can see that, all the interfaces are up tap devices are ip, can u please suggest what should we do to resolve the issue Regards Adivya Singh

2 1

[all][tripleo][validations] Communication from the Validations Framework team! o/
by Gaël Chamoulaud 24 Jun '21

24 Jun '21

Greetings everyone! For those who do not know about the Validations Framework yet: The Validations Framework is at the same time, A collection of Ansible roles and playbooks to detect and report potential issues during a TripleO deployment and A Python library to manipulate them through a Command Line Interface. * Validations are used to efficiently and reliably verify various facts about the cloud (or any other products) on the level of individual nodes and hosts. * Validations are non-intrusive by design, and recommended when performing large scale changes to the cloud, for example upgrades, or to aid in the diagnosis of various issues. Historically, this project was created during the Newton cycle for a direct use with OpenStack/TripleO and became the Validations Framework since Stein. We strongly feel and think that this project can be beneficial to other environments, projects or products... If you read this line it's probably because you are still interested, so if you want to talk with us about the Validations Framework, how to create a new validation for your product and/or integrate our CLI in your workflow, please feel free to reach us on this mailing list or come join us on IRC: * IRC channel #validation-framework at Libera (For all subject-matters) * IRC channel #tripleo at OFTC (OpenStack and TripleO discussions) We are looking forward seeing you around! [1] - https://opendev.org/openstack/tripleo-validations [2] - https://docs.openstack.org/tripleo-validations/latest/ [3] - https://opendev.org/openstack/validations-libs [4] - https://docs.openstack.org/validations-libs/latest/ [5] - https://opendev.org/openstack/validations-common [6] - https://docs.openstack.org/validations-common/latest/ Best Regards, Cédric Jeanneret, David J. Peacock, Jan Buchta, Jiri Podivin, Mathieu Bultel, and I! -- Gaël Chamoulaud - (He/Him/His)

1 0

[neutron] Drivers meeting 25.06.2021 cancelled
by Slawek Kaplonski 23 Jun '21

23 Jun '21

Hi, I will be on PTO tomorrow thus I will not be able to chair the meeting. Let's cancel it this week and see You again next Friday. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[cinder] status of some unapproved Xena specs
by Brian Rosmaita 23 Jun '21

23 Jun '21

As attentive members of the OpenStack community know, Friday 25 June is the Xena spec freeze for cinder [0]. There are four specs that have been discussed on and off at PTGs and midcycle meetings that don't appear ready for approval in Xena. The discussion of these specs at today's cinder meeting is here: https://meetings.opendev.org/meetings/cinder/2021/cinder.2021-06-23-14.00.l… The specs I'm talking about are these: 1. Support revert any snapshot https://review.opendev.org/c/openstack/cinder-specs/+/736111 discussion: https://wiki.openstack.org/wiki/CinderXenaMidCycleSummary#Support_revert_an… 2. Migration support for a volume with replication status enabled https://review.opendev.org/c/openstack/cinder-specs/+/766130 discussion: https://wiki.openstack.org/wiki/CinderXenaMidCycleSummary#Migration_support… 3. Update original volume az https://review.opendev.org/c/openstack/cinder-specs/+/778437 discussion: https://wiki.openstack.org/wiki/CinderXenaMidCycleSummary#Migration_support… 4. Allow volumes to be part of multiple volume groups https://review.opendev.org/c/openstack/cinder-specs/+/792722 I think this spec isn't getting much attention because it has a -1 from Zuul, and the last few sections still contain the boilerplate language from the spec template, which makes it look like the spec is still in progress. When these have come up for discussion at previous meetings, there is general support among the cinder team, though there are details that we feel need to be worked out on the specs. These details have been noted on the Gerrit reviews and in the previous PTG and midcycle discussion summaries. While some points have been addressed, other important points have not. This makes me think that there is a communication problem between the team and the spec proposers. I encourage people proposing specs that are having problems in review to put their spec on the weekly cinder meeting agenda [1] so that we can discuss them interactively and hopefully explain more clearly what issues the cinder team has with the specs as currently proposed. If attending the weekly cinder meeting (1400 UTC on Wednesdays) is difficult because of time zone issues, please let me know and we can figure something out (maybe an occasional spec review meeting held at some time other than 1400 UTC). Or maybe there's an alternative communication medium we haven't explored yet. The cinder team encourages community participation in cinder development, and it distresses us to see these specs languishing. cheers, brian [0] https://releases.openstack.org/xena/schedule.html#x-cinder-spec-freeze [1] https://etherpad.opendev.org/p/cinder-xena-meetings

1 0

[largescale-sig] Next meeting: June 23, 15utc on #openstack-operators
by Thierry Carrez 23 Jun '21

23 Jun '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. Please note the new channel to be used! You can doublecheck how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210623T15 A number of topics have already been added to the agenda, including discussing our next OpenInfra.Live show. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[TC] Open Infra Live- Open Source Governance
by Kendall Nelson 23 Jun '21

23 Jun '21

Hello TC Folks :) So I have been tasked with helping to collect a couple volunteers for our July 29th episode of Open Infra Live (at 14:00 UTC) on open source governance. I am also working on getting a couple members from the k8s steering committee to join us that day. If you are interested in participating, please let me know! I only need like two volunteers, but if we have more people than that dying to join in, I am sure we can work it out. Thanks! -Kendall Nelson (diablo_rojo)

4 5

[cinder] CI coverage for SPDK
by Balazs Gibizer 23 Jun '21

23 Jun '21

Hi Cinder Team, I'm wondering what CI coverage cinder has for SPDK driver. The code mentions that Mellanox CI[1] but I'm not able to find a run from that CI in the recent cinder patches. Is this driver still covered somewhere? Cheers, gibi [1] https://github.com/openstack/cinder/blob/393c2e4ad90c05ebf28cc3a2c65811d7e1…

3 3

[cinder] Bug deputy report for week of 2021-23-06
by Sofia Enriquez 23 Jun '21

23 Jun '21

Hello, This is a bug report from 2021-16-06 to 2021-23-06. You're welcome to join the Cinder Bug Meeting today. Weekly on Wednesday at 1500 UTC on #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High: - CI features discussed last week: - https://bugs.launchpad.net/cinder/+bug/1932188 "lvm commands crash, causing failure" Assigned to Sofia Enriquez and Eric Harney - https://bugs.launchpad.net/os-brick/+bug/1929223 "scaleio connector disables HTTPS certificate validation". Unassigned Medium: - https://bugs.launchpad.net/cinder/+bug/1932964 "SolidFire duplicate volume name exception on migration and replication". Assigned to Fábio Oliveira Low: - https://bugs.launchpad.net/cinder/+bug/1933265 "cinder-backup ceph snapshot delete". Unassigned Wishlist: - https://bugs.launchpad.net/cinder/+bug/1933052 "cinder_internal_tenant_* is not predictable". Unassigned Cheers, Sofia -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[Kolla][nova] /var/lib/nova/instances on nfs
by Ignazio Cassano 23 Jun '21

23 Jun '21

Hello Stackers, is there any configuration parameter in kolla for sharing nova on nfs between compute nodes ? Or I must insert an entry in fstab ? Thanks Ignazio

3 5

[cinder] topics for wednesday's cinder meeting
by Brian Rosmaita 22 Jun '21

22 Jun '21

Hello Cinder Team, There are two topics on the agenda for tomorrow that you may want to look at in advance. First, the specs deadline is Friday, so everyone should be looking at specs: https://review.opendev.org/q/project:openstack%252Fcinder-specs+status:open Second, Simon put a discussion of allowing `black` to be used as an auto-linter on the agenda. The question is whether this should be allowed as an optional tool for developers. There is an example patch posted: https://review.opendev.org/c/openstack/cinder/+/792462 and here is some general info about black: https://black.readthedocs.io/en/stable/the_black_code_style/current_style.h… The choice of a linter can be quite contentious, so the discussion will be timeboxed so that we'll have sufficient time to talk about specs. So I thought I'd sent out notice in advance so that we'll be able to make good use of meeting time. cheers, brian

1 0

[glance] nominating Cyril Roelandt for glance core
by Abhishek Kekane 22 Jun '21

22 Jun '21

Hi All, I am nominating Cyril Roelandt (cyril-roelandt LP and Steap on IRC) to be a Glance core. Cyril has been around the Glance community for a long time and is familiar with the architecture and design patterns used in Glance and its related projects. He's contributed code, triaged bugs, provided bug fixes, and did quality reviews for Glance. He is also helping me in reducing our bug backlogs. Considering the current situation with the project, however, it would be an enormous help to have someone as knowledgeable about Glance as Cyril to have +2 abilities. I discussed this with cyril, he's agreed to be a core reviewer. In any case, I'd like to put Cyril to work as soon as possible! So please reply to this message with comments or concerns before 23:59 UTC on Monday 21 June. I'd like to confirm Cyril as a core on Tuesday 22 June. Thanks and Regards, Abhishek

6 6

[Wallaby][kolla][masakari] hacluser issues
by Ignazio Cassano 22 Jun '21

22 Jun '21

Hello everyone, I wonder if this is a good place for discussing about some issues I am facing with instance HA with masakari hacluster kolla wallaby. Thanks Ignazio

2 8

[ops][victoria][nova] Add hardware to guest (was: [ops][nova][spice][victoria] Switch from VNC to SPICE)
by DHilsbos＠performair.com 22 Jun '21

22 Jun '21

Just realized that I sent this to Sean, but not the list... Sean; Thank you for that pointer to hw_video_model=virtio, that addressed the resolution issue! Any chance you could point me at a metadata option that would tell libvirt to provide 2 monitor devices? It looks like I need to send the max_outputs=2 to qemu, or libvirt or directly to virtio-vga (I'm not sure which) [1], though I don't see a way to pass that through in nova.virt.libvirt.driver [2]. As to how GoToMyPC works... I don't know, but I believe it captures the framebuffer. [1] https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/ [2] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py Thank you, Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com -----Original Message----- From: Sean Mooney [mailto:smooney@redhat.com] Sent: Monday, June 21, 2021 4:57 AM To: Dominic Hilsbos; laurentfdumont(a)gmail.com; openstack-discuss(a)lists.openstack.org Subject: Re: [ops][nova][spice][victoria] Switch from VNC to SPICE On Fri, 2021-06-18 at 20:44 +0000, DHilsbos(a)performair.com wrote: > We're trying to virtualize desktops for remote workers. Guests will > be Windows. Remote connection method will be GoToMyPC. As such, I > need the OS to believe either 1) it has 2 1920 x 1080 monitors, or 2) > it has a single 3840 x 1080 monitor. Neither of which have I found a > way to do in VNC. i am not sure the resoltution that rdp or whatever GoToMyPC uses will be affected by the use of vnc or spcice on the host. I think this is related to the video model used in the guets unless GoToMyPC is running on the host and connecting the the qemu process. thats not normally something we would recommend but if its directly conecting to the qemu process then the use of vnc or spice might be a factor have you tried changing the video model to virtio for example, that should enabel more resolutions in the guest. i know that usign RDP in a windows guest with hw_video_model=virtio in the image does allow higher resolutions and i think it enables multi monitor support too. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President – Information Technology > Perform Air International Inc. > DHilsbos(a)PerformAir.com > www.PerformAir.com > > From: Laurent Dumont [mailto:laurentfdumont@gmail.com] > Sent: Friday, June 18, 2021 12:39 PM > To: Dominic Hilsbos > Cc: stephenfin(a)redhat.com; openstack-discuss > Subject: Re: [ops][nova][spice][victoria] Switch from VNC to SPICE > > Are you using the Openstack console itself? You might have more > flexibility with a dedicated VNC server inside the VM and connect > directly to it. So you would not be tied to the Openstack VNC support > which I dont think was ever designed for graphical usage. More of a > "it's 2AM, server is crashed and I need a way in!". > > On Fri, Jun 18, 2021 at 1:58 PM <DHilsbos(a)performair.com> wrote: > Stephen; > > Thank you for the information. > > What's the replacement? Is VNC getting improvements to allow higher > resolutions, and multi-monitor, in the guest? > > We've already decided to transition our OpenStack cluster away from > CentOS, as RDO doesn't package some of the OpenStack projects we'd > like to use, and RedHat has lost our trust. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President – Information Technology > Perform Air International Inc. > DHilsbos(a)PerformAir.com > www.PerformAir.com > > > -----Original Message----- > From: Stephen Finucane [mailto:stephenfin@redhat.com] > Sent: Friday, June 18, 2021 10:33 AM > To: Dominic Hilsbos; openstack-discuss(a)lists.openstack.org > Subject: Re: [ops][nova][spice][victoria] Switch from VNC to SPICE > > On Fri, 2021-06-18 at 16:53 +0000, DHilsbos(a)performair.com wrote: > > All; > > > > We have a Victoria cluster, and I'd like to switch from VNC to > > SPICE. Cluster is installed with packages (RDO), and configured > > manually. > > > > I have located > > https://docs.openstack.org/nova/victoria/admin/remote-console-access.html > > , but this doesn't tell me which services need to be installed on > > which servers. > > > > Looking at packages, I'm fairly certain nova-spicehtml5proxy > > (openstack-nova-spicehtml5proxy on CentOS 8) needs to be installed > > where the nova-novncproxy is currently. > > > > I also suspect that qemu-kvm-ui-spice needs to be installed on the > > nova-compute nodes. Is spice-server needed on the nova-compute > > nodes? > > Not an answer, but I'd be very careful about building solutions based > on SPICE. > It has been deprecated in RHEL 8.3 and recent versions of Fedora and > is slated > for removal in RHEL 9, as this bug [1] points out. It is also > receives very > little attention in nova as some deployments tooling (such as Red Hat > OSP) has > not supported it for some time. There's a non-zero chance support for > this > console type will be dropped entirely in some future release. > > Stephen > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1946938 > > > Thank you, > > > > Dominic L. Hilsbos, MBA > > Vice President - Information Technology > > Perform Air International Inc. > > DHilsbos(a)PerformAir.com > > www.PerformAir.com > > > > > > > >

2 2

Reply to: [lists.openstack.org代发][Wallaby][kolla][masakari] hacluser issues
by Sam Su (苏正伟) 21 Jun '21

21 Jun '21

Hi, Ignazio You can discuss about instance HA issue with others on the channel ‘openstack-masakari’in OFTC. They will have a weekly meeting this Tuesday, 4:00-5:00 UTC on the IRC channel. Welcomed. 发件人: Ignazio Cassano [mailto:ignaziocassano@gmail.com] 发送时间: 2021年6月22日 3:06 收件人: openstack-discuss <openstack-discuss(a)lists.openstack.org> 主题: [lists.openstack.org代发][Wallaby][kolla][masakari] hacluser issues Hello everyone, I wonder if this is a good place for discussing about some issues I am facing with instance HA with masakari hacluster kolla wallaby. Thanks Ignazio

3 2

[openstack-helm] No meeting tomorrow
by Gage Hugo 21 Jun '21

21 Jun '21

Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow, the meeting is cancelled. Our next meeting will be June 29th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

cyborg-tempest-plugin test failed due to the zuul server has no accelerators
by Alex Song (宋文平) 21 Jun '21

21 Jun '21

Hello Everyone, Is the Zuul server env changed recently? There are no accelerators and our cyborg-tempest-plugin test failed. Please help. Thanks. Best Regards.

4 5