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

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

29 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 29 Jun '21

29 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 29 Jun '21

29 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 28 Jun '21

28 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