December 2022 - openstack-discuss

live resize
by Parsa Aminian 15 Mar '23

15 Mar '23

hello on openstack with ceph backend is it possible to live resize instances ? I want to change flavor without any down time .

5 6

[kolla-ansible] [yoga] [magnum] [k8s] cannot attach persistent volume to pod
by Stuart Whitman 24 Feb '23

24 Feb '23

Hello, When I try to attach a persistent cinder volume to a pod, I get FailedMount and FailedAttachVolume timeout events. I also get these errors in the log of the csi-cinder-controllerplugin-0 pod: E1020 13:38:41.747511 1 reflector.go:126] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.VolumeAttachment: the server could not find the requested resource E1020 13:38:41.748187 1 reflector.go:126] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.CSINode: the server could not find the requested resource I fixed a CrashLoopBackoff error with the csi-snapshotter container in the csi-cinder-controllerplugin-0 pod by providing the label "csi_snapshotter_tag=v4.0.0" when I created the cluster template. I found that suggestion in an issue on the GitHub cloud-provider-openstack project. I'm not finding any help with this error on Google. Thanks, -Stu _____________________________________ The information contained in this e-mail and any attachments from Group W may contain confidential and/or proprietary information and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, be aware that any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately of that fact by return e-mail and permanently delete the e-mail and any attachments to it.

3 5

[charms] Team Delegation proposal
by Chris MacNaughton 09 Feb '23

09 Feb '23

Hello All, <tl;dr> I would like to propose some new ACLs in Gerrit for the openstack-charms project: - openstack-core-charms - ceph-charms - network-charms - stable-maintenance </tl;dr> With an increasing focus split among the openstack-charmers team, I'm observing that people are focused on more specific subsets of the charms, and would like to propose that new ACLs are created to allow us to recognize that officially. I've chosen the breakdown above as it aligns neatly with where the focus lines are at this point, letting developers work on their specific focus areas. This proposal would not reduce permissions for anybody who is currently a core on the openstack-charms project and, in fact, future subteam core members could aspire to full openstack-charmers core as well. Ideally, this approach will let us escalate developers to "core" developers for the subteam(s) where they have demonstrated the expertise we expect in a core-charmer. It also allows a more gradual escalation to being a core in the openstack-charms project, making it a progression rather than a single destination. As a related addition, I'm appending to this proposal the creation of a stable-maintenance ACL which would allow members to manage backports without a full core-charmer grant. --- Chris MacNaughton

5 7

[Openstack Tacker] - Issue while creating NS
by Lokendra Rathour 16 Jan '23

16 Jan '23

Hi Team, Was trying to create NS using the document : https://docs.openstack.org/tacker/yoga/user/nsd_usage_guide.html But getting an error, the bug has been opened, requesting your kind assistance. https://bugs.launchpad.net/tacker/+bug/1999502 thanks once again. -- ~ Lokendra skype: lokendrarathour

2 1

[ironic] Bugfix branches being EOL'd first week of Jan, 2023
by Jay Faulkner 13 Jan '23

13 Jan '23

OpenStack Community and Operators, As documented in https://specs.openstack.org/openstack/ironic-specs/specs/approved/new-relea…, Ironic performs bugfix releases in the middle of a cycle to permit downstream packagers to more rapidly deliver features to standalone Ironic users. However, we've neglected as a project to cleanup or EOL any of these branches -- until now. Please take notice that during the first week in January, we will be EOL-ing all old, unsupported Ironic bugfix branches. This will be handled similarly to an EOL of a stable branch; we will create a tag -- e.g. for bugfix/x.y branch, we would tag bugfix-x.y-eol -- then remove the branch. These branches have been out of support for months and should not be in use in your Ironic clusters. If you are using any branches slated for retirement, please immediately upgrade to a supported Ironic version. A full listing of projects and branches impacted: ironic branches being retired bugfix/15.1 bugfix/15.2 bugfix/16.1 bugfix/16.2 bugfix/18.0 bugfix/20.0 ironic-python-agent branches being retired bugfix/6.2 bugfix/6.3 bugfix/6.5 bugfix/6.6 bugfix/8.0 bugfix/8.4 ironic-inspector branches being retired bugfix/10.2 bugfix/10.3 bugfix/10.5 bugfix/10.10 Thank you, Jay Faulkner Ironic PTL

1 4

Issue resizing volumes attached to running volume backed instances
by Jérôme BECOT 12 Jan '23

12 Jan '23

Hello Openstack, We have Ussuri deployed on a few clouds, and they're all plugged to PureStorage Arrays. We allow users to only use volumes for their servers. It means that each server disk is a LUN attached over ISCSI (with multipath) on the compute node hosting the server. Everything works quite fine, but we have a weird issue when extending volumes attached to running instances. The guests notice the new disk size .. of the last extent. Say I have a server with a 10gb disk. I add 5gb. On the guest, still 10gb. I add another 5gb, and on the guest I get 15, and so on. I've turned the debug mode on and I could see no error in the log. Looking closer at the log I could catch the culprit: 2022-12-08 17:35:13.998 46195 DEBUG os_brick.initiator.linuxscsi [] Starting size: *76235669504* 2022-12-08 17:35:14.028 46195 DEBUG os_brick.initiator.linuxscsi [] volume size after scsi device rescan *80530636800* extend_volume 2022-12-08 17:35:14.035 46195 DEBUG os_brick.initiator.linuxscsi [] Volume device info = {'device': '/dev/disk/by-path/ip-1...1:3260-iscsi-iqn.2010-06.com.purestorage:flasharray.x-lun-10', 'host': '5', 'channel': '0', 'id': '0', 'lun': '10'} extend_volume 2022-12-08 17:35:14.348 46195 INFO os_brick.initiator.linuxscsi [] Find Multipath device file for volume WWN 3624... 2022-12-08 17:35:14.349 46195 DEBUG os_brick.initiator.linuxscsi [] Checking to see if /dev/disk/by-id/dm-uuid-mpath-3624.. exists yet. wait_for_path 2022-12-08 17:35:14.349 46195 DEBUG os_brick.initiator.linuxscsi [] /dev/disk/by-id/dm-uuid-mpath-3624... has shown up. wait_for_path 2022-12-08 17:35:14.382 46195 INFO os_brick.initiator.linuxscsi [] mpath(/dev/disk/by-id/dm-uuid-mpath-3624) *current size 76235669504* 2022-12-08 17:35:14.412 46195 INFO os_brick.initiator.linuxscsi [] mpath(/dev/disk/by-id/dm-uuid-mpath-3624) *new size 76235669504* 2022-12-08 17:35:14.413 46195 DEBUG oslo_concurrency.lockutils [] Lock "extend_volume" released by "os_brick.initiator.connectors.iscsi.ISCSIConnector.extend_volume" :: held 2.062s inner 2022-12-08 17:35:14.459 46195 DEBUG os_brick.initiator.connectors.iscsi [] <== extend_volume: return (2217ms) *76235669504* trace_logging_wrapper 2022-12-08 17:35:14.461 46195 DEBUG nova.virt.libvirt.volume.iscsi [] Extend iSCSI Volume /dev/dm-28; new_size=*76235669504* extend_volume 2022-12-08 17:35:14.462 46195 DEBUG nova.virt.libvirt.driver [] Resizing target device /dev/dm-28 to *76235669504* _resize_attached_volume The logs clearly shows that the rescan confirm the new size but when interrogating multipath, it does not. But requesting multipath few seconds after on the command line shows the new size as well. It explains the behaviour. I'm running Ubuntu 18.04 with multipath 0.7.4-2ubuntu3.2. The os-brick code for multipath is far more basic than the one in master branch. Maybe the multipath version installed is too recent for os-brick. Thanks for the help Jerome

2 2

[tc][mistral][release] Propose to deprecate Mistral
by Elõd Illés 07 Jan '23

07 Jan '23

Hi, Mistral projects are unfortunately not actively maintained and caused hard times in latest official series releases for release management team. Thus we discussed this and decided to propose to deprecate Mistral [1] to avoid broken releases and last minute debugging of gate issues (which usually fall to release management team), and remove mistral projects from 2023.1 Antelope release [2]. We would like to ask @TC to evaluate the situation and review our patches (deprecation [1] + removal from the official release [2]). Thanks in advance, Előd Illés irc: elodilles @ #openstack-release [1] https://review.opendev.org/c/openstack/governance/+/866562 [2] https://review.opendev.org/c/openstack/releases/+/865577

6 7

[kolla] Propose Bartosz Bezak for core reviewer
by Michał Nasiadka 06 Jan '23

06 Jan '23

Hello Koalas, I’d like to propose Bartosz Bezak as a core reviewer for Kolla, Kolla-Ansible, Kayobe and ansible-collection-kolla. Bartosz has recently went through release preparations and release process itself for all mentioned repositories, has been a great deal of help in meeting the cycle trailing projects deadline. In addition to that, he’s been the main author of Ubuntu Jammy and EL9 (Rocky Linux 9 to be precise) support in Kayobe for Zed release, as well as fixing various bugs amongst all four repositories. Bartosz also brings OVN knowledge, which will make the review process for those patches better (and improve our overall review velocity, which hasn’t been great recently). Kind regards, Michal Nasiadka

6 6

Nova libvirt/kvm sound device
by Zakhar Kirpichenko 06 Jan '23

06 Jan '23

Hi! I'd like to have the following configuration added to every guest on a specific host managed by Nova and libvirt/kvm: <sound model='bla'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> </sound> When I add the device manually to instance xml, it works as intended but the instance configuration gets overwritten on instance stop/start or hard reboot via Nova. What is the currently supported / proper way to add a virtual sound device without having to modify libvirt or Nova code? I would appreciate any advice. Best regards, Zakhar

2 2

[designate] Implemeting PTR record restrictions
by Thomas Goirand 06 Jan '23

06 Jan '23

Hi, We implemented this scenario for our public cloud: https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.htm… This is currently in production in beta-mode at Infomaniak's public cloud. We did that, because we want our customers to be able to set any domain name or PTR for the IPs they own. However, we discovered that there's no restriction on what zone customers can set. For example, if customer A owns the IP 203.0.113.9, customer B can do "openstack zone create 9.113.0.203.in-addr.arpa.", preventing customer A to set their PTR record. Is there currently a way to fix this? Or maybe a spec to implement the correct restrictions? What is the way to fix this problem in a public cloud env? Cheers, Thomas Goirand (zigo)

2 1