December 2022 - openstack-discuss

Re: openstack-discuss Digest, Vol 50, Issue 63
by Kerem Çeliker 28 Dec '22

28 Dec '22

Hello Can, To fix an RBD (Rados Block Device) IOPS bottleneck on the client side in OpenStack, you can try the following: Monitor the CPU and memory usage on the client machine to ensure that it has sufficient resources. You can use tools like top or htop to view real-time resource usage. Check the network bandwidth between the client and the storage system to ensure that it is not a bottleneck. You can use tools like iperf or tcpdump to measure network performance. Review the configuration of the storage system to ensure that it is optimized for the workload. This may include adjusting the number and type of disks used, as well as the RAID level and chunk size. Consider using a storage system with a higher IOPS rating to see if it can improve performance. This may involve upgrading to faster disks or using a storage solution with more disks or SSDs. Try using a different client machine with more resources (e.g., a machine with a faster CPU and more memory) to see if it can issue more I/O requests. Consider using a different network connection between the client and the storage system, such as a faster network card or a direct connection rather than a network switch. If you are using Ceph as the underlying storage system, you can try adjusting the Ceph configuration to improve performance. This may include adjusting the number of placement groups, the object size, or the number of OSDs (object storage devices). It's also worth noting that an IOPS bottleneck can also occur on the server side (i.e., within the storage system itself). In this case, you may need to adjust the configuration of the storage system or add more resources (e.g., disks or SSDs) to improve performance. BR, Kerem Çeliker keremceliker.medium.com IBM | Red Hat Champion Sent from my iPhone > On 28 Dec 2022, at 08:13, openstack-discuss-request(a)lists.openstack.org wrote: > > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > or, via email, send a message with subject or body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. [ops][nova] RBD IOPS bottleneck on client-side (Can ?zyurt) > 2. [keystone][Meeting] Reminder Keystone meeting is cancelled > today (Dave Wilde) > 3. Nova libvirt/kvm sound device (Zakhar Kirpichenko) > 4. Re: [Tacker][SRBAC] Update regarding implementation of > project personas in Tacker (Yasufumi Ogawa) > 5. Re: [Tacker][SRBAC] Update regarding implementation of > project personas in Tacker (manpreet kaur) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Dec 2022 15:33:56 +0300 > From: Can ?zyurt <acozyurt(a)gmail.com> > To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > Subject: [ops][nova] RBD IOPS bottleneck on client-side > Message-ID: > <CAMf4N71awOfNyBk4FfpM6UCjH4AZWz+QuJwUnOv+itvqvPbTjw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi everyone, > > I hope you are all doing well. We are trying to pinpoint an IOPS > problem with RBD and decided to ask you for your take on it. > > 1 control plane > 1 compute node > 5 storage with 8 SSD disks each > Openstack Stein/Ceph Mimic deployed with kolla-ansible on ubuntu-1804 > (kernel 5.4) > isolcpus 4-127 on compute > vcpu_pin_set 4-127 in nova.conf > > image_metadatas: > hw_scsi_model: virtio-scsi > hw_disk_bus: scsi > flavor_metadatas: > hw:cpu_policy: dedicated > > What we have tested: > fio --directory=. --ioengine=libaio --direct=1 > --name=benchmark_random_read_write --filename=test_rand --bs=4k > --iodepth=32 --size=1G --readwrite=randrw --rwmixread=50 --time_based > --runtime=300s --numjobs=16 > > 1. First we run the fio test above on a guest VM, we see average 5K/5K > read/write IOPS consistently. What we realize is that during the test, > one single core on compute host is used at max, which is the first of > the pinned cpus of the guest. 'top -Hp $qemupid' shows that some > threads (notably tp_librbd) share the very same core throughout the > test. (also emulatorpin set = vcpupin set as expected) > 2. We remove isolcpus and every other configuration stays the same. > Now fio tests now show 11K/11K read/write IOPS. No bottlenecked single > cpu on the host, observed threads seem to visit all emulatorpins. > 3. We bring isolcpus back and redeploy the cluster with Train/Nautilus > on ubuntu-1804. Observations are identical to #1. > 4. We tried replacing vcpu_pin_set to cpu_shared_set and > cpu_dedicated_set to be able to pin emulator cpuset to 0-4 to no > avail. Multiple guests on a host can easily deplete resources and IOPS > drops. > 5. Isolcpus are still in place and we deploy Ussuri with kolla-ansible > and Train (to limit the moving parts) with ceph-ansible both on > ubuntu-1804. Now we see 7K/7K read/write IOPS. > 6. We destroy only the compute node and boot it with ubuntu-2004 with > isolcpus set. Add it back to the existing cluster and fio shows > slightly above 10K/10K read/write IOPS. > > > What we think happens: > > 1. Since isolcpus disables scheduling between given cpus, qemu process > and its threads are stuck at the same cpu which created the > bottleneck. They should be runnable on any given emulatorpin cpus. > 2. Ussuri is more performant despite isolcpus, with the improvements > made over time. > 3. Ubuntu-2004 is more performant despite isolcpus, with the > improvements made over time in the kernel. > > Now the questions are: > > 1. What else are we missing here? > 2. Are any of those assumptions false? > 3. If all true, what can we do to solve this issue given that we > cannot upgrade openstack nor ceph on production overnight? > 4. Has anyone dealt with this issue before? > > We welcome any opinion and suggestions at this point as we need to > make sure that we are on the right path regarding the problem and > upgrade is not the only solution. Thanks in advance. > > > > ------------------------------ > > Message: 2 > Date: Tue, 27 Dec 2022 07:00:30 -0800 > From: Dave Wilde <dwilde(a)redhat.com> > To: openstack-discuss(a)lists.openstack.org > Subject: [keystone][Meeting] Reminder Keystone meeting is cancelled > today > Message-ID: > <CAJEkJ+qYCHZayR-t9w4e=ZB846CZSrggcqdYKE85fWkj2XAo5w(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Just a quick reminder that there won?t be the keystone weekly meeting > today. We?ll resume our regulararly scheduled programming on 03-Jan-2023. > Please update the agenda if you have anything you?d like to discuess. The > reviewathon is also cancelled this week, to be resumed on 06-Jan-2023. > > /Dave >

1 0

[Tacker][SRBAC] Update regarding implementation of project personas in Tacker
by manpreet kaur 28 Dec '22

28 Dec '22

Hi Ogawa san and Tacker team, This mailer is regarding the SRBAC implementation happening in Tacker. In the Tacker release 2023.1 virtual PTG [1], it was decided by the Tacker community to partially implement the project personas (project-reader role) in the current release. And in upcoming releases, we will implement the remaining project-member role. To address the above requirement, I have prepared a specification [2] and pushed the same in Gerrit for community review. Ghanshyam san reviewed the specification and shared TC's opinion and suggestion to implement both the project-reader and project-member roles. The complete persona implementation will depreciate the 'owner' rule, and help in restricting any other role to accessing project-based resources. Additionally, intact legacy admin (current admin), works in the same way so that we do not break things and introduce the project personas which should be additional things to be available for operators to adopt. Current Status: Incorporated the new requirement and uploaded a new patch set to address the review comment. Note: The Tacker spec freeze date is 28th Dec 2022, there might be some delay in merging the specification in shared timelines. [1] https://etherpad.opendev.org/p/tacker-antelope-ptg#L186 [2] https://review.opendev.org/c/openstack/tacker-specs/+/866956 Thanks & Regards, Manpreet Kaur

3 3

Re: openstack-discuss Digest, Vol 50, Issue 62
by Kerem Çeliker 28 Dec '22

28 Dec '22

Hello Vincent, To allow a user from a container to access files on OpenStack, you can use the --volume or -v option when creating the container to mount a host file or directory as a volume inside the container. For example: Copy code docker run -it --volume /path/on/host:/path/in/container image_name This will mount the host file or directory located at /path/on/host as a volume inside the container at /path/in/container. The user inside the container will be able to access the files in the volume at /path/in/container. You can also use the --mount option to mount a volume. This option provides more control over the volume, such as specifying the volume driver and options. For example: Copy code docker run -it --mount type=bind,source=/path/on/host,target=/path/in/container image_name This will also mount the host file or directory located at /path/on/host as a volume inside the container at /path/in/container, and the user inside the container will be able to access the files in the volume at /path/in/container. Note that the /path/on/host must be an absolute path and must exist on the host system. The /path/in/container can be any path inside the container and does not need to exist prior to the mount. It's also important to note that the user inside the container must have the appropriate permissions to access the mounted files. You can use the --user option to specify the user that the container should run as, or you can set the ownership and permissions of the mounted files on the host system to allow the user inside the container to access them. Hope it works for you.. — Best, Regards, Kerem Çeliker IBM | Red Hat Champion keremceliker.medium.com Sent from my iPhone > On 27 Dec 2022, at 15:07, openstack-discuss-request(a)lists.openstack.org wrote: > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > or, via email, send a message with subject or body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. Container access mounted device (vincent lee) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Dec 2022 19:01:21 +0800 > From: vincent lee <vincentlee676(a)gmail.com> > To: openstack-discuss(a)lists.openstack.org > Subject: Container access mounted device > Message-ID: > > > Hi, I have deployed a working OpenStack and would like to know if there are > any possible options I can enable so that when creating a new container, > files can be mounted to it, and a user from the container can access it. > For instance, having a mounted device from the compute host and allowing > the /dev/(mounted device name) file to be accessible in the container. > > Best regards, > Vincent >

1 0

[keystone][Meeting] Reminder Keystone meeting is cancelled today
by Dave Wilde 27 Dec '22

27 Dec '22

Just a quick reminder that there won’t be the keystone weekly meeting today. We’ll resume our regulararly scheduled programming on 03-Jan-2023. Please update the agenda if you have anything you’d like to discuess. The reviewathon is also cancelled this week, to be resumed on 06-Jan-2023. /Dave

1 0

[ops][nova] RBD IOPS bottleneck on client-side
by Can Özyurt 27 Dec '22

27 Dec '22

Hi everyone, I hope you are all doing well. We are trying to pinpoint an IOPS problem with RBD and decided to ask you for your take on it. 1 control plane 1 compute node 5 storage with 8 SSD disks each Openstack Stein/Ceph Mimic deployed with kolla-ansible on ubuntu-1804 (kernel 5.4) isolcpus 4-127 on compute vcpu_pin_set 4-127 in nova.conf image_metadatas: hw_scsi_model: virtio-scsi hw_disk_bus: scsi flavor_metadatas: hw:cpu_policy: dedicated What we have tested: fio --directory=. --ioengine=libaio --direct=1 --name=benchmark_random_read_write --filename=test_rand --bs=4k --iodepth=32 --size=1G --readwrite=randrw --rwmixread=50 --time_based --runtime=300s --numjobs=16 1. First we run the fio test above on a guest VM, we see average 5K/5K read/write IOPS consistently. What we realize is that during the test, one single core on compute host is used at max, which is the first of the pinned cpus of the guest. 'top -Hp $qemupid' shows that some threads (notably tp_librbd) share the very same core throughout the test. (also emulatorpin set = vcpupin set as expected) 2. We remove isolcpus and every other configuration stays the same. Now fio tests now show 11K/11K read/write IOPS. No bottlenecked single cpu on the host, observed threads seem to visit all emulatorpins. 3. We bring isolcpus back and redeploy the cluster with Train/Nautilus on ubuntu-1804. Observations are identical to #1. 4. We tried replacing vcpu_pin_set to cpu_shared_set and cpu_dedicated_set to be able to pin emulator cpuset to 0-4 to no avail. Multiple guests on a host can easily deplete resources and IOPS drops. 5. Isolcpus are still in place and we deploy Ussuri with kolla-ansible and Train (to limit the moving parts) with ceph-ansible both on ubuntu-1804. Now we see 7K/7K read/write IOPS. 6. We destroy only the compute node and boot it with ubuntu-2004 with isolcpus set. Add it back to the existing cluster and fio shows slightly above 10K/10K read/write IOPS. What we think happens: 1. Since isolcpus disables scheduling between given cpus, qemu process and its threads are stuck at the same cpu which created the bottleneck. They should be runnable on any given emulatorpin cpus. 2. Ussuri is more performant despite isolcpus, with the improvements made over time. 3. Ubuntu-2004 is more performant despite isolcpus, with the improvements made over time in the kernel. Now the questions are: 1. What else are we missing here? 2. Are any of those assumptions false? 3. If all true, what can we do to solve this issue given that we cannot upgrade openstack nor ceph on production overnight? 4. Has anyone dealt with this issue before? We welcome any opinion and suggestions at this point as we need to make sure that we are on the right path regarding the problem and upgrade is not the only solution. Thanks in advance.

1 0

Container access mounted device
by vincent lee 27 Dec '22

27 Dec '22

Hi, I have deployed a working OpenStack and would like to know if there are any possible options I can enable so that when creating a new container, files can be mounted to it, and a user from the container can access it. For instance, having a mounted device from the compute host and allowing the /dev/(mounted device name) file to be accessible in the container. Best regards, Vincent

1 0

[openstacksdk][cinder] openstacksdk-functional-devstack job is failing
by Rajat Dhasmana 27 Dec '22

27 Dec '22

Hi, Currently the *openstacksdk-functional-devstack* job is failing on the cinder gate[1] due to which gate is blocked. This seems to be due to the new tox 4 enforcement and could be an issue for other projects as well. We've a patch in OpenstackSDK that fixes this issue[2] but that is also failing on the* osc-tox-py38-tips* job. The patch has no update since 21st December which is concerning since it's blocking other projects (at least cinder). I've proposed a patch[3] to make the *openstacksdk-functional-devstack *job non-voting until the situation is resolved on the OpenStackSDK side. [1] https://zuul.opendev.org/t/openstack/build/29c0eb15abd144a8a4f167e70fe61530 [2] https://review.opendev.org/c/openstack/openstacksdk/+/867827 [3] https://review.opendev.org/c/openstack/cinder/+/868596 Thanks Rajat Dhasmana

2 2

[openstack][cinder] Cinder volume id wont change when retype volume
by Nguyễn Hữu Khôi 27 Dec '22

27 Dec '22

Hello guys, I have a problem with cinder: I use cinder volume retype to move my volume to another backend. It worked but when I check on new backend, volume id doest match with id which on Horizon dash board.It expects to have same volume id on Horizon and new backend. I use DellSC and DellPowerstore. Thank you. Nguyen Huu Khoi

2 2

Help overriding Nova policies (Ussuri)
by Jérôme BECOT 27 Dec '22

27 Dec '22

Hello, I should miss something, and I need some help. I've updated some rules that I placed in the /etc/nova/policy.yaml file. I use all defaults for the olso policies (ie scope is not enabled). When I generate the fulle policy with oslopolicy-policy-generator, the rules are applied in the generated output. If I test the policy with oslopolicy-checker under the user's token, the results matches the permissions, but Nova API continue to refuse the operation Policy check for os_compute_api:os-flavor-manage:create failed with credentials I'm using the openstack cli to make the request (openstack flavor create) Thanks for your help J

2 2

[tacker] Cancelling next irc meetings
by Yasufumi Ogawa 26 Dec '22

26 Dec '22

Hi team, Due to the holidays, we are cancelling next two meetings on 27th Dec and 3rd Jun. Cheers, Yasufumi

1 0