November 2021 - openstack-discuss

[TripleO] Branching our documentation
by James Slagle 03 Nov '21

03 Nov '21

Hello TripleO Owls, Our documentation, particularly the deploy guide, has become overly complex with all the branches that TripleO has supported over the years. I see notes that document functionality specific to releases all the way back to Mitaka! In ancient history, we made the decision to not branch our documentation because the work to maintain multiple branches outweighed the effort to just document all releases at once in the same branch. I think the scale has now tipped in the other direction. I propose that we create a stable/wallaby in tripleo-docs, and begin making the master branch specific to Yoga. This would also mean we could clean up all the old notes and admonitions about previous releases on the master branch. Going forward, if you make a change to the docs that applies to Yoga and Wallaby, you would need to backport that change to stable/wallaby. If you needed to make a change that applied only to Wallaby (or a prior release), you would make that change only on stable/wallaby. I'm not sure of all the plumbing required to make it so that the OpenStack Wallaby deploy guide builds from stable/wallaby, etc, but I wanted to get the idea out there first for feedback. Please let me know your thoughts. Thank you! -- -- James Slagle --

4 4

[ptl][release][stable][EM] Extended Maintenance - Ussuri
by Előd Illés 03 Nov '21

03 Nov '21

Hi, As Xena was released last week and we are in a less busy period, now it is a good time to call your attention to the following: In a month Ussuri is planned to transition to Extended Maintenance phase [1] (planned date: 2021-11-12). I have generated the list of the current *open* and *unreleased* changes in stable/ussuri for the follows-policy tagged repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Ussuri before moving stable/ussuri branches to Extended Maintenance. Feel free to edit and extend these lists to track your progress! * At the transition date the Release Team will tag the *latest* Ussuri releases of repositories with *ussuri-em* tag. * After the transition stable/ussuri will be still open for bug fixes, but there won't be official releases anymore. *NOTE*: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken (final!) releases! Thanks, Előd [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/ussuri-final-release-before-em

1 1

Attach Nvidia Jetson as compute node to openstack (aarch64)
by Pavlos Basaras 03 Nov '21

03 Nov '21

Hello everyone, I am relatively new to the community, thanks in advance for your time and help. I have an openstack cluster ready, working with several compute nodes based on x86 architecture. My current installation is based on Ussuri. I have recently acquired a couple of nvidia Jetson devices ( https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-ag…) which I want to connect to the cluster. The arm cpu model name is ARMv8 Processor rev 0 (v8l). CPU flags on the arm architecture are different and hence egrep -c '(vmx|svm)' /proc/cpuinfo is empty to the best of my knowledge. However, i re-build the custom linux kernel (i.e, Tegra) of the Jetson device, enabling the KVM module. So once i used: *sudo kvm-ok* INFO: /dev/kvm exists KVM acceleration can be used *dmesg | grep -i kvm* [ 1.372478] kvm [1]: 16-bit VMID [ 1.372489] kvm [1]: IDMAP page: 80fa1000 [ 1.372498] kvm [1]: HYP VA range: 4000000000:7fffffffff [ 1.374185] kvm [1]: Hyp mode initialized successfully [ 1.374299] kvm [1]: vgic-v2@3884000 [ 1.374763] kvm [1]: vgic interrupt IRQ1 [ 1.374790] kvm [1]: virtual timer IRQ4 *dmesg | grep -i 'CPU features'* [ 0.687366] CPU features: detected feature: Privileged Access Never [ 0.687372] CPU features: detected feature: LSE atomic instructions [ 0.687378] CPU features: detected feature: User Access Override [ 0.687385] CPU features: detected feature: 32-bit EL0 Support Does this suffice to say that I can use KVM with libvirt for the nova openstack? The version of libvirt is 6.0.0. >From the nova logs i see the following with *virt_type = qemu* WARNING nova.virt.libvirt.driver [-] The libvirt driver is not tested on qemu/aarch64 by the OpenStack project and thus its quality can not be ensured. For more information, see: https://docs.openstack.org/nova/latest/user/support-matrix.html And as it detects the aarch64 device: CPU mode "host-passthrough" was chosen If i try to launch an instance i get the following error with qemu libvirt.libvirtError: unsupported configuration: CPU mode 'host-passthrough' for aarch64 qemu domain on aarch64 host is not supported by hypervisor where as i i use *virt_type= kvm* the error after trying to launch an instance is libvirt.libvirtError: unsupported configuration: Emulator '/usr/bin/qemu-system-aarch64' does not support virt type 'kvm' Any advice on how to proceed? all the best Pavlos.

1 0

[cinder] Bug deputy report for week of 11-03-2021
by Sofia Enriquez 03 Nov '21

03 Nov '21

This is a bug report from 10-27-2021-15-09 to 11-03-2021. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1949313 'Cinder backup tries to restore to the wrong host'. Assigned to Sam Morrison. - https://bugs.launchpad.net/cinder/+bug/1949189 'NfsDriver' object has no attribute 'manage_existing_get_size'. Unassigned. - https://bugs.launchpad.net/cinder/+bug/1946483 'Error when deleting encrypted volume backup from another project'. Assigned to Pavlo Shchelokovskyy. - https://bugs.launchpad.net/cinder/+bug/1948962 'Quotas: Some operations fail with a 255 volume type name'. Assigned to Gorka. - https://bugs.launchpad.net/cinder/+bug/1949061 '[Storwize] Retype of a non-rep mirror volume to mirror- volume-type with different mirror_pool is failing'. Assigned to Mounika Sreeram. Low - https://bugs.launchpad.net/cinder/+bug/1798589 'No available space check for image_conversion_dir in cinder-volume on upload-to-image'. Unassigned. Cheers -- 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

[monasca][kolla-ansible] HTTPUnprocessableEntity: Dimension value must be 255 characters or less
by Adam Tomas 03 Nov '21

03 Nov '21

Hi, in my test deployment I get following error messages for each metric at each metric collection (every 60s in my case). Of course whole URL (i.e. /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id) is longer than 255 characters, but shouldn’t this URL be processed in smaller chunks? As I see the validation is done by monasca_api, so in case it fails no data is processed by monasca_log_transformer, right? Limiting metric name lenght won’t change this situation (in this example metric name is 22 characters long, while the whole URL is 285 characters long, so 285-22 is still > 255). How can I avoid this error? Best regards Adam Tomas 2021-11-02 14:19:44.935 693 ERROR monasca_api.v2.common.bulk_processor [req-a251xxxx 60bexxxx 27bexxxxx - default default] Log transformation failed, rejecting log: monasca_api.api.core.log.exceptions.HTTPUnprocessableEntity: Dimension value /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id must be 255 characters or less 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor [req-a251xxxx 60bexxxx 27bexxxx - default default] Dimension value /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id must be 255 characters or less: monasca_api.api.core.log.exceptions.HTTPUnprocessableEntity: Dimension value /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id must be 255 characters or less 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor Traceback (most recent call last): 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_api/v2/common/bulk_processor.py", line 81, in _transform_message 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor dimensions=self._get_dimensions(log_element, 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_api/v2/common/bulk_processor.py", line 129, in _get_dimensions 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor validation.validate_dimensions(local_dims) 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_api/api/core/log/validation.py", line 138, in validate_dimensions 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor _validate_dimension_value(dim_value) 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_api/api/core/log/validation.py", line 114, in _validate_dimension_value 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor raise exceptions.HTTPUnprocessableEntity( 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor monasca_api.api.core.log.exceptions.HTTPUnprocessableEntity: Dimension value /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id must be 255 characters or less 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor

1 1

[neutron][ovs] Different Cookie with Remote Security group
by Mohan Kumar 03 Nov '21

03 Nov '21

Team, I've created a security group with a remote security group attached to it. openstack security group rule create --ethertype=IPv4 --protocol tcp > --remote-group server-grp --ingress --dst-port=22 application-grp when I create VM with server-grp , I can see two cookies in br-int ovs bridge, one with default cookie and another new cookie with conjunction flows, is it expected behavior? ubuntu@req-generic-65-d012-mn:~$ sudo ovs-ofctl dump-flows br-int | awk '{print $1}' | sort -n | uniq cookie=0x12b7adbe73614620, cookie=0x207d02d6bbcf499e, NXST_FLOW ubuntu@req-generic-65-d012-mn:~$ sudo ovs-ofctl dump-flows br-int | grep "0x207d02d6bbcf499e" cookie=0x207d02d6bbcf499e, duration=335.421s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+est-rel-rpl,ipv6,reg6=0x1,ipv6_src=fdd8:a3ce:31ae:0:f816:3eff:fe8a:f751 actions=conjunction(8,1/2) cookie=0x207d02d6bbcf499e, duration=335.420s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+new-est,ipv6,reg6=0x1,ipv6_src=fdd8:a3ce:31ae:0:f816:3eff:fe8a:f751 actions=conjunction(9,1/2) cookie=0x207d02d6bbcf499e, duration=335.420s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+est-rel-rpl,ip,reg6=0x1,nw_src=10.0.0.38 actions=conjunction(16,1/2) cookie=0x207d02d6bbcf499e, duration=335.420s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+new-est,ip,reg6=0x1,nw_src=10.0.0.38 actions=conjunction(17,1/2)

2 2

[Openstack-victoria] [Openstack-queens] migration of VM from openstack queens to victoria
by Swogat Pradhan 02 Nov '21

02 Nov '21

Hi, I have 2 openstack setups Setup1. Openstack queens + ceph nautilaus Setup2. Openstack victoria + ceph octopus So, I am trying to migrate some VM's (windows and linux) from Setup1 to Setup2. For migrating the VM's i am using rbd export on setup1 and then rbd import on setup2. I have successfully migrated 21 VM's. i am now facing an issue in the 22nd vm which, after migrating the VM the vm is stuck in the windows logo screen and not moving forward, and i can't seem to understand how to approach it. Attached the instance.xml files of both queens and victoria setup's of the same VM. With regards, Swogat pradhan

2 3

Accessing Openstack using v3 API
by open infra 02 Nov '21

02 Nov '21

Hi, I was trying to use the openstack environment using the v3 client API as mentioned in [2] documentation but ended up with an error as mentioned in [1]. I can access the same environment v3 API using curl. Am I missing something? [1] https://paste.opendev.org/show/810336/ [2] https://docs.openstack.org/python-keystoneclient/latest/using-api-v3.html Regards, Danishka

2 2

[neutron][ovn] Stateless Security Group
by Ammad Syed 02 Nov '21

02 Nov '21

Hi, I have upgraded my lab to latest xena release and ovn 21.09 and ovs 2.16. I am trying to create stateless security group. But its getting failed with below error message. # openstack security group create --stateless sec02-stateless Error while executing command: BadRequestException: 400, Unrecognized attribute(s) 'stateful' I see below logs in neutron server logs. 2021-11-02 12:47:41.921 1346 DEBUG neutron.wsgi [-] (1346) accepted ('172.16.40.45', 41272) server /usr/lib/python3/dist-packages/eventlet/wsgi.py:992 2021-11-02 12:47:42.166 1346 DEBUG neutron.api.v2.base [req-b6a37fff-090f-4754-9df7-6e4314ed9481 19844bf62a7b498eb443508ef150e9b8 98687873a146418eaeeb54a01693669f - default default] Request body: {'security_group': {'name': 'sec02-stateless', 'stateful': False, 'description': 'sec02-stateless'}} prepare_request_body /usr/lib/python3/dist-packages/neutron/api/v2/base.py:729 2021-11-02 12:47:42.167 1346 WARNING neutron.api.v2.base [req-b6a37fff-090f-4754-9df7-6e4314ed9481 19844bf62a7b498eb443508ef150e9b8 98687873a146418eaeeb54a01693669f - default default] An exception happened while processing the request body. The exception message is [Unrecognized attribute(s) 'stateful'].: webob.exc.HTTPBadRequest: Unrecognized attribute(s) 'stateful' 2021-11-02 12:47:42.167 1346 INFO neutron.api.v2.resource [req-b6a37fff-090f-4754-9df7-6e4314ed9481 19844bf62a7b498eb443508ef150e9b8 98687873a146418eaeeb54a01693669f - default default] create failed (client error): Unrecognized attribute(s) 'stateful' 2021-11-02 12:47:42.168 1346 INFO neutron.wsgi [req-b6a37fff-090f-4754-9df7-6e4314ed9481 19844bf62a7b498eb443508ef150e9b8 98687873a146418eaeeb54a01693669f - default default] 172.16.40.45 "POST /v2.0/security-groups HTTP/1.1" status: 400 len: 317 time: 0.2455938 Any advice on how to fix it ? Ammad

3 10

[neutron] CI meeting - Tuesday 02.11.2021
by Slawek Kaplonski 02 Nov '21

02 Nov '21

Hi, As we discussed during the PTG and in the last week's CI meeting, this week's meeting will be a video call. Please join https://meetpad.opendev.org/neutron-ci-meetings at 300pm UTC if You are interested in the Neutron CI. We will also keep meeting opened in the #openstack-neutron irc channel in case if anyone would like to participate that way. Agenda for the meeting is at https://etherpad.opendev.org/p/neutron-ci-meetings -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0