April 2023 - openstack-discuss - lists.openstack.org

[neutron][ovn-bgp-agent] Make ovn-bgp-agent a Neutron stadium project
by Rodolfo Alonso Hernandez 04 Apr '23

04 Apr '23

Hello all: During the last PTG, it was discussed and accepted to migrate the ovn-bgp-agent project [1] to the Neutron stadium umbrella. This mail is a heads-up for anyone using it. In the next days (maybe today), Lucas will send the corresponding patches for "governance" and "project-config" repositories in order to start this migration. If you have any questions, please ask them in this email or via IRC in the #openstack-neutron channel. Regards. [1]https://opendev.org/x/ovn-bgp-agent

1 0

[nova][cinder] Providing ephemeral storage to instances - Cinder or Nova
by Christian Rohmann 04 Apr '23

04 Apr '23

Hello OpenStack-discuss, I am currently looking into how one can provide fast ephemeral storage (backed by local NVME drives) to instances. There seem to be two approaches and I would love to double-check my thoughts and assumptions. 1) *Via Nova* instance storage and the configurable "ephemeral" volume for a flavor a) We currently use Ceph RBD als image_type (https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.im…) so instance images are stored in Ceph, not locally on disk. I believe this setting will also cause ephemeral volumes (destination_local) to be placed on a RBD and not /var/lib/nova/instances? Or is there a setting to set a different backend for local block devices providing "ephemeral" storage? So RBD for the root disk and a local LVM VG for ephemeral? b) Will an ephemeral volume also be migrated when the instance is shutoff as with live-migration? Or will there be an new volume created on the target host? I am asking because I want to avoid syncing 500G or 1T when it's only "ephemeral" and the instance will not expect any data on it on the next boot. c) Is the size of the ephemeral storage for flavors a fixed size or just the upper bound for users? So if I limit this to 1T, will such a flavor always provision a block device with his size? I suppose using LVM this will be thin provisioned anyways? 2) *Via Cinder*, running cinder-volume on each compute node to provide a volume type "ephemeral", using e.g. the LVM driver a) While not really "ephemeral" and bound to the instance lifecycle, this would allow users to provision ephemeral volume just as they need them. I suppose I could use backend specific quotas (https://docs.openstack.org/cinder/latest/cli/cli-cinder-quotas.html#view-bl…) to limit the number of size of such volumes? b) Do I need to use the instance locality filter (https://docs.openstack.org/cinder/latest/contributor/api/cinder.scheduler.f…) then? c) Since a volume will always be bound to a certain host, I suppose this will cause side-effects to instance scheduling? With the volume remaining after an instance has been destroyed (beating the purpose of it being "ephemeral") I suppose any other instance attaching this volume will be scheduling on this very machine? Is there any way around this? Maybe a driver setting to have such volumes "self-destroy" if they are not attached anymore? d) Same question as with Nova: What happens when an instance is live-migrated? Maybe others also have this use case and you can share your solution(s)? Thanks and with regards Christian

3 4

[Neutron] CI meeting 04.04.2023 cancelled
by Slawek Kaplonski 04 Apr '23

04 Apr '23

Hi, I have overlapping internal meeting this week and will not be able to run Neutron CI meeting. So lets cancel it and meet next week. See You there. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[neutron] Neutron drivers meeting
by Rodolfo Alonso Hernandez 04 Apr '23

04 Apr '23

Hello Neutrinos: Next Neutron drivers meeting (April 7) will be cancelled. This is Easter week and most people will have Friday as a holiday. See you next week.

1 0

[nova] 2023.2 Bobcat PTG summary
by Sylvain Bauza 04 Apr '23

04 Apr '23

Hey folks, that's a wrap ! I'm happy to say we had a very productive PTG week with around more than 12 contributors each day. It was nice to see new faces. As a reminder, please don't open the main etherpad link [1] if you use a Web browser with an automatic translation modification feature. If you do it, then it would internally translate all the phrases directly in the etherpad as if you were directly modifying the etherpad by yourself. Please also make sure you don't accidentally remove or modify lines . In order to prevent any misusage, this etherpad is a read-only copy of the main one : https://etherpad.opendev.org/p/r.22d95e20f7133350dcad573c015ed7da Last point but not the least, I'm a human who usually writes bugs [2], including when it's about writing a report of the past week's discussions and the actions taken. Don't feel offended or irritated if you read silly notes of the very beloved chat you had, please rather fix it the opensource way by correcting my errors with a reply on that thread. Enough chat, please grab a coffee [3] (as it's a quite verbose email) and jump straight on below. ### Operator hour ### (specific and distinct read-only etherpad here : https://etherpad.opendev.org/p/r.f94e6dda608450b6a4a5c9afc76e8a88 ) Yet again, we missed a few more operators in this room (at least we had 3 of them, thanks for those that were there !). I'm still wondering why they are not joining a free session where they can discuss their concerns or some wanted features. Anyway, that's what we discussed : - for the moment, no operators have tried to use the Yoga unified limits feature. - operators are happy with the new default RBAC scopes. We could create a small and quick admin-guide section for explaining that and pointing to the oslo.policy documentation. - operators would love to use the (possibly) new virtiofs feature from Bobcat for Manila shares (if we are able to merge it). That being said, they think they couldn't provide it for their environments until Nova can live-migrate the instances using the shares (which is not possible as for the moment, even QEMU doesn't support it) - we also discussed a pain point from an operator and then we asked him to provide a bug report (related to the vm state continuing to be ACTIVE after shelving). For the moment, we can't reproduce the problem. ### Cross-project discussions ### ## Manila/Nova ### # Prevent shares deletion while it's attached to an instance - Nova could add some traits to reflect the share type. - the Manila team will create a manila spec for adding a service-level (or admin-level) lock API with a 'locked-by' parameter (or using service tokens if set) ### Neutron/Nova ### Read Neutron summary email [4] if you want more details. - We agreed on a delete_on_termination feature for ports. We need to see if we can use some already existing Neutron API (tags) or if we need a whole new API. - We are quite OK with the Napatech LinkVirt SmartNics feature, but we need to review the spec and we also want some third-party CI support for it. - the Neutron team accepted to return a HTTP409 Conflict return code if a duplicated port binding action is done by Nova and the Nova team agreed on handling it. - About the SRIOV port tracking in Placement, the Nova team needs to help the spec owner on how to work on it as it's a large and difficult design (but we agreed on the first part of the design). ### Glance/Nova ### Glance wants to add a new API for Image Direct URL access. Nova was quite OK with this new API, but the Nova team was having some concerns about upgrades and client calls to the new API. The Manila team agreed to create a nova spec for discussing those. ### Cinder/Nova ### - The Nova team is quite OK with the usecase for NFV encryption. Since the design is quite simple, maybe this could be a specless feature, just using traits for telling to Placement which computes support NFV encryption. We're OK to test this with cinder NFV jobs and maybe also testing it with a Nova periodic job depending on the implementation. - The Cinder team agreed on using its volume metadata API for tracking the cinder volumes hardware models. ### Horizon/Nova ### Horizon wanted to call the Placement API. We agreed on using the openstackSDK for this as Placement doesn't have python bindings directly. Some new methods may be added against the SDK for calling specific Placement APIs if we think we may need those (instead of directly calling Placement with the standard HTTP verbs and the API URIs) ### Nova-specific topics ### # Antelope retrospective and process-related discussions Shorter cycle than Zed, 6 features landed (same as Zed), 46 contributors (down by 8 compared to Zed), 27 bugfixes (vs. 54 for Zed). We were happy to not have a RC2 for the first time in the Nova history. The bug triage backlog kept small. - We want to discuss on a better review cadence to not look at all the implementations by the last weeks. - We want to get rid of Storyboard stories in Placement. We found and agreed on a way forward. - We will set 5-years-old-and-more bug reports as Incomplete, so bug reporters have 90 days to confirm that the bug is still present on master. - We will add more contrib documentation for explaining more how to find Gerrit changes for one-off reviewers and how to create some changes - We agreed on no longer automatically accepting an already-approved spec from a previous cycle if no code is still not existing. - All efforts on porting our client calls to the SDK should be tagged in Launchpad with the 'sdk' tag. - A Bobcat schedule will be proposed on next Tuesday weekly meeting with feature and spec deadlines + some review days. - We also discussed what we should discuss in the Vancouver PTG. # CI failures continuous improvement - We want to test some alternative image but cirros (alpine as a potential alternative) with a small footprint in some specific nova jobs - We need to continue investigating on the volume detach/attach failures. We may create a specific job that would do serialized volume checks as a canary job for forcing the job to fail more frequently in order to dig down further. - (related) Sylvain will propose a Vancouver PTG cross-project session for a CI debugging war room experience. # The new release cadence We had long arguments whether we should hold deprecations and removals this cycle, given the releasenotes tooling isn't in place yet. As a reminder, since Bobcat is a non-SLURP release, operators are able to skip it and just look at the C releasenotes so we want to make sure we forward-port upgrade notes for them. For the moment, no consensus in place, we defer the outcome into a subsequent nova meeting and in the meantime, we raised the point to the TC for guidance needs. # The problem with hard affinity group policies - We agreed on the fact that hard affinity/anti-affinity policies aren't ideal (operators, if you read me, please prefer soft affinity/anti-affinity policies for various reasons I won't explain here) but since we support those policies and the use case is quite understandable, we need to find a way to unblock instances that can't be easily-migrated from those kind of groups (eg. try to move your instances off a host with hard Affinity between them, good luck) - A consensus has been reached to propose a new parameter for live-migrate, evacuate and migrate that would only skip the hard affinity checks. A backlog spec will be written capturing this consensus. - Since a group policy may be violated, we'll also propose a new server group API modification that would show if a group has its policy violated. # Unified limits next steps - We agreed on the fact we should move on and enable by default unified limits in a close future, but we first need to provide a bit of tooling to help the migration. - tool could be a nova-manage command that would provide the existing quota limits as a yaml file so we could inject those into keystone (to be further defined during Bobcat) - a nova-status upgrade check may be nice for yelling if operators forgot to define their limits in keystone before upgrading to the release (potentially C) that would default to unified limits - testing in the grenade job is a feat. # Frequently written objects may lead to exhaustion of DB primary keys - We agreed on having all new primary keys to have BigInteger as data type. Existing keys should use BigInt but there is a huge upgrade impact to mitigate. - Operators will be sollicited to know their preferences between a costly-at-once data migration vs. a rolling data online migration for existing tables. - We will document which DB tables are safe to reindex (since their PKs isn't normalized as a FK somewhere else) - A backlog spec will capture all of the above # Leftover volumes relationship when you directly call Cinder instead of Nova for detaching - Yup, this is a known issue and we should discuss this with the Cinder team (unfortunately, we didn't did it this week) - We maybe should have a nova-manage script that would cleanup the BDMs but we're afraid of leaking some volume residues in the compute OS - Anyway, we need to understand the main scope and we also need to discuss about the preconditions ('when' should we call this tool and 'what' this tool should be doing ?). Probably a spec. # Misc but not the leasc (heh) - we will fill a rfe bug for lazy-loading instance name from system metadata or update the nested field in the instance object (no additional DB write) - we will add a new policy for cold-migrate specifically when a host is passed as a parameter (admin-only as a default) - We agreed on continuing the effort on compute node hostname robustification (the Bobcat spec seems not controversial) - We agreed on a few things about the server show command and the use of the SDK. Some existing OSC patch may require a bit of rework but it would cover most of the concerns we discussed. - we should fix the post-copy issue when you want to live-migrate a paused instance by removing the post-copy migration flag if so. - we could enable virtio-blk trim support by default. It's both a bugfix (we want to remove an exception) and a new feature (we want to enable it by default) so we'll discuss whether we need a specless blueprint by a next meeting. - we also discuss about a Generic VDPA support feature for Nova, and we asked the owner to provide us a spec for explaining the usecase. ### That's it. ### Yet again, I'm impressed. If you read that phrase, you're done with reading. I just hope your coffee was good and the time you took reading that email was worth it. If you have questions or want to reach me directly on IRC, that's simple : I'm bauzas on #openstack-nova. HTH, -Sylvain (on behalf of the whole Nova community) [1] https://etherpad.opendev.org/p/nova-bobcat-pt g (please remove the empty char between 'pt' and 'g') [2] Unfortunately, I'm very good at creating bugs as I discovered that based on my 10-year unfortunate contributions to OpenStack. [3] Or a tea, or whatever you prefer. [4] https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033115.h…

1 1

[kolla-ansible][zed][15.1.0] Horizon failed to load trunk and QoS
by Stefan Bryzga 04 Apr '23

04 Apr '23

Hi all, Some time ago I deployed a small cluster with kolla-ansible v15.1.0. Before deployment I enabled neutron_qos and neutron_trunk flags in /etc/kolla/globals.yml. Both functions work fine via cli and I can create new entries via dashboard however horizon won't display created trunks/qos on the page (It shows "No items to display"). In web browser console I get this error while loading page: TypeError: Cannot read properties of undefined (reading 'data') at addTrackBy (output.0a9483334bbd.js:1115:59) at processQueue (output.43a09e34a303.js:1581:786) at output.43a09e34a303.js:1585:110 at Scope.$digest (output.43a09e34a303.js:1636:200) at Scope.$apply (output.43a09e34a303.js:1643:269) at done (output.43a09e34a303.js:1356:123) at completeRequest (output.43a09e34a303.js:1375:20) at XMLHttpRequest.requestLoaded (output.43a09e34a303.js:1368:1) 'Possibly unhandled rejection: {}' Does anyone knows how to fix this? Should I modify any configs to display new entries in horizon? Best Regards, Stefan

1 0

Opensearch service upgrade
by Daniel Pawlik 04 Apr '23

04 Apr '23

Hello, We would like to notify you that the Opensearch service [1] would be updated to a newer version on 03.04.2023 at 12:00 PM UTC. This procedure might take a while, depending of the cluster size. During that time, the Opensearch service would not be available. If anyone has any doubts, please reply to the email. Dan [1] - https://opensearch.logs.openstack.org/_dashboards/app/home

1 1

Propose Dale Smith as Magnum Caore
by Jake Yip 04 Apr '23

04 Apr '23

Hi all, I would like to propose Dale Smith as a Magnum Core Reviewer. Dale is a contributor to Magnum, and also takes care of Magnum at his place of employment - Catalyst Cloud NZ. As many Magnum contributors are ourselves operators, I think it is important that we have representation from different cloud providers to help guide and shape Magnum going forward. He will replace Feilong, who is the former PTL and used to work in Catalyst Cloud, in the Core Team. We thank Feilong for his contributions and welcome Dale. Regards, Jake -- Jake Yip Technical Lead, ARDC Nectar Research Cloud

1 0

[nova][heat] The next steps to "fix" libvirt problems in Ubuntu Jammy
by Takashi Kajinami 04 Apr '23

04 Apr '23

Hello, Since we migrated our jobs from Ubuntu Focal to Ubuntu Jammy, heat gate jobs have become very flaky. Further investigation revealed that the issue is related to something in libvirt from Ubuntu Jammy and that prevents detaching devices from instances[1]. The same problem appears in different jobs[2] and we workaround the problem by disabling some affected jobs. In heat we also disabled some flaky tests but because of this we no longer run basic scenario tests which deploys instance/volume/network in a single stack, which means we lost the quite basic test coverage. My question is, is there anyone in the Nova team working on "fixing" this problem ? We might be able to implement some workaround (like checking status of the instances before attempting to delete it) but this should be fixed in libvirt side IMO, as this looks like a "regression" in Ubuntu Jammy. Probably we should report a bug against the libvirt package in Ubuntu but I'd like to hear some thoughts from the nova team because they are more directly affected by this problem. I'm now trying to set up a centos stream 9 job in Heat repo to see whether this can be reproduced if we use centos stream 9. I've been running that specific scenario test in centos stream 9 jobs in puppet repos but I've never seen this issue, so I suspect the issue is really specific to libvirt in Jammy. [1] https://bugs.launchpad.net/nova/+bug/1998274 [2] https://bugs.launchpad.net/nova/+bug/1998148 Thank you, Takashi

3 5

[horizon]display quota volume type on horizon
by Nguyễn Hữu Khôi 04 Apr '23

04 Apr '23

Hello. I see that blueprint is very real case but it has not deployed yet. https://blueprints.launchpad.net/horizon/+spec/quotas-per-cinder-volume-type I am curious why it is abanddoned .

2 2

[designate][ptg] Designate Bobcat (2023.2) PTG summary
by Michael Johnson 03 Apr '23

03 Apr '23

We accomplished some big tasks in Antelope: Finishing the shared zones feature, adding support for SQL Alchemy 2.x, and hard zone deletes. For the Bobcat series, Designate had a pretty straightforward PTG session with good discussion. The focus areas for Bobcat are going to be on the batch serial number update patch[1] (deferred from Antelope) and improving the multiple pools feature[2][3]. Multiple DNS server pools have been a feature in Designate for a number of years now, but we need to improve the test coverage and documentation. Other minor work anticipated for Bobcat is to update the RBAC testing to account for the RBAC "Direction Change"[4] in support of enabling the new Keystone default roles as the default RBAC configuration. We also discussed the new specification that merged during Antelope[5] to add support for catalog zones. This specification is merged and ready for development, but it was not clear that there are developers planning to work on it during Bobcat. We hope this feature can at least get started during the Bobcat series. Thank you to everyone that participated! Michael [1] https://review.opendev.org/c/openstack/designate/+/871255 [2] https://review.opendev.org/c/openstack/designate/+/857978 [3] https://review.opendev.org/c/openstack/designate-tempest-plugin/+/871184 [4] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [5] https://specs.openstack.org/openstack/designate-specs/specs/antelope/catalo…

1 0

[ptls] PyPI maintainer cleanup - Action needed: Contact extra maintainers
by Jay Faulkner 03 Apr '23

03 Apr '23

Hi PTLs, The TC recently voted[1] to require humans be removed from PyPI access for OpenStack-managed projects. This helps ensure all releases are created via releases team tooling and makes it less likely for a user account compromise to impact OpenStack packages. Many projects have already updated https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L33 with a list of packages that contain extra maintainers. We'd like to request that PTLs, or their designate, reach out to any extra maintainers listed for projects you are responsible for and request they remove their access in accordance with policy. An example email, and detailed steps to follow have been provided at https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup-email-tem… . Thank you for your cooperation as we work to improve our security posture and harden against supply chain attacks. Thank you, Jay Faulkner TC Vice-Chair 1: https://opendev.org/openstack/governance/commit/979e339f899ef62d2a6871a99c9…

3 6

[barbican] database is growing and can not be purged
by Pavlo Shchelokovskyy 03 Apr '23

03 Apr '23

Hi all, we are observing the following behavior in Barbican: - OpenStack environment is using both encrypted Cinder volumes and encrypted local storage (lvm) for Nova instances - over the time, the secrets and orders tables are growing - many soft-deleted entries in secrets DB can not be purged by the db cleanup script As I understand what is happening - both Cinder and Nova create secrets in Barbican on behalf of the user when creating an encrypted volume or booting an instance with encrypted local storage. They both do it via castellan library, that under the hood creates orders in Barbican, waits for them to become active and returns to the caller only the ID of the generated secret. When time comes to delete the thing (volume or instance) Cinder/Nova again use castellan, but only delete the secret, not the order (they are not aware that there was any 'order' created anyway). As a result, the orders are left in place, and DB cleanup procedure does not delete soft-deleted secrets when there's an ACTIVE order referencing such secret. This is troublesomes on many levels - users who use Cinder or Nova may not even be aware that they are creating something in Barbican. Orders accumulating like that may eventually result in cryptic errors when e.g. when you run out of quota for orders. And what's more, default Barbican policies do allow 'normal' (creator) users to create an order, but not delete it (only project admin can do it), so even if the users are aware of Barbican involvement, they can not delete those orders manually anyway. Plus there's no good way in API to determine outright which orders are referencing deleted secrets. I see several ways of dealing with that and would like to ask for your opinion on what would be the best one: 1. Amend Barbican API to allow filtering orders by the secrets, when castellan deletes a secret - search for corresponding order and delete it as well, change default policy to actually allow order deletion by the same users who can create them. 2. Cascade-delete orders when deleting secrets - this is easy but probably violates that very policy that disallowed normal users to delete orders. 3. improve the database cleanup so it first marks any order that references a deleted secret also as deleted, so later when time comes both could be purged (or something like that). This also has a similar downside to the previous option by not being explicit enough. I've filed a bug for that https://storyboard.openstack.org/#!/story/2010625 and proposed a patch for option 2 (cascade delete), but would like to ask what would you see as the most appropriate way or may be there's something else that I've missed. Btw, the problem is probably even more pronounced with keypairs - when castellan is used to create those, under the hood both order and container are created besides the actual secrets, and again only the secret ids are returned to the caller. When time comes to delete things, the caller only knows about secret IDs, and can only delete them, leaving both container and order behind. Luckily, I did not find any place across OpenStack that actually creates keypairs using castellan... but the problem is definitely there. Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

2 2

[SWIFT] ssync receiver crash
by Reid Guyett 03 Apr '23

03 Apr '23

Hello, We recently upgraded our swift servers to 20.04 from 18.04. After the upgrades were completed we are seeing 1 server where the ssync receiver keeps crashing. The crash is preventing hand offs from being cleanup up in the cluster (50 servers). Looking for some advice to fix/workaround the issue. We have 20 clusters but are only seeing this issue in 1 cluster. It is strange to me that we only see this ssync receiver error in one server out of the ~1000 we are running. OS: Ubuntu 20.04.5 Swift version: 2.25.2 On the receiver side we are seeing the following trace: object-server: senderIp/d1/2166 EXCEPTION in ssync.Receiver: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/eventlet/wsgi.py", line 209, in _chunked_read self.chunk_length = int(rfile.readline().split(b";",1)[0], 16) ValueError: invalid literal for int() with base 16: b'' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/swift/obj/ssync_receiver.py", line 166, in __call__ for data in self.missing_check(): File "/usr/lib/python3/dist-packages/swift/obj/ssync_receiver.py", line 340, in missing_check line = self.fp.readline(self.app.network_chunk_size) File "/usr/lib/python3/dist-packages/eventlet/wsgi.py", line 226, in readline return self._chunked_read(self.rfile, size, True) File "/usr/lib/python3/dist-packages/eventlet/wsgi.py", line 211, in _chunked_read raise ChunkReadError(err) eventlet.wsgi.ChunkReadError: invalid literal for int() with base 16: b'' On the sender side we are seeing this message when I try to run the reconstructor manually with debug logging: root@use1-saas-p6-paco-9:~# swift-object-reconstructor object-server.conf -p 27999 -v -o object-reconstructor: Starting 271723 object-reconstructor: Spawned worker 271755 with {'override_partitions': [27999], 'override_devices': ['d10', 'd17', 'd19', 'd9', 'd29', 'd15', 'd2', 'd24', ' d32', 'd1', 'd8', 'd14', 'd11', 'd28', 'd27', 'd6', 'd7', 'd16', 'd13', 'd25', 'd26', 'd20', 'd18', 'd12', 'd4', 'd0', 'd22', 'd3', 'd5', 'd21', 'd33', 'd23', 'd30', 'd34', 'd31'], 'multiprocess_worker_index': 0} object-reconstructor: [worker 1/1 pid=271755] Running object reconstructor in script mode. object-reconstructor: [worker 1/1 pid=271755] Run listdir on /srv/node/d22/objects-4/27999 object-reconstructor: [worker 1/1 pid=271755] recieverIP:6200/d31/27999 10.0 seconds: connect receive object-reconstructor: [worker 1/1 pid=271755] 1/26820 (0.00%) partitions reconstructed in 10.14s (0.10/sec, 75h remaining) object-reconstructor: [worker 1/1 pid=271755] Object reconstruction complete (once). (0.17 minutes) object-reconstructor: Forked worker 271755 finished object-reconstructor: Worker 271755 exited object-reconstructor: Finished 271723 object-reconstructor: Exited 271723 Thanks! Reid Guyett Staff Storage Engineer Datto, A Kaseya Company www.datto.com<http://www.datto.com/> Important Notice: This email is intended to be received only by persons entitled to receive the confidential and legally privileged information it presumptively contains, and this notice constitutes identification as such. Any reading, disclosure, copying, distribution or use of this information by or to someone who is not the intended recipient, is prohibited. If you received this email in error, please notify us immediately at legal(a)kaseya.com, and then delete it. To opt-out of receiving emails Please click here<https://info.kaseya.com/email-subscription-center.html>. The term 'this e-mail' includes any and all attachments.

1 0

[nova][dev] image to local block device mapping not supported
by Nemanja Miletic 03 Apr '23

03 Apr '23

Hello, Nova does not support image to local block device mapping since issue in this bug is fixed: https://bugs.launchpad.net/nova/+bug/1377958 In particular I am interested in scenario best described with this command: openstack server create --flavor m1.small --network mgmt --image XXX \ --block-device uuid=YYY,source_type=image,\ destination_type=local,disk_bus=ide,device_type=cdrom,boot_index=1 testvm300 For above command nova gives error: Block Device Mapping is Invalid: Mapping image to local is not supported. Libvirt does not have issues with having two block devices which have file source. My question is what am I missing here? Why Nova does not support image to local block device mapping? Thank you for your help. Nemanja

2 2

[kolla] Image building question
by Satish Patel 03 Apr '23

03 Apr '23

Folks, I am playing with kolla image building to understand how it works. I am using the following command to build images and wanted to check with you folks if that is the correct way to do it. $ kolla-build -b ubuntu -t source keystone nova neutron glance Does the above command compile code from source or just download images from remote repositories and re-compile them? because in command output I've not noticed anything related to the compiling process going on. Here is the output of all images produced by kolla-build command. Do I need anything else or is this enough to deploy kolla? root@docker-reg:~# docker images REPOSITORY TAG IMAGE ID CREATED SIZE kolla/mariadb-server 15.1.0 2a497eee8269 26 minutes ago 595MB kolla/cron 15.1.0 342877f26a8a 30 minutes ago 250MB kolla/memcached 15.1.0 0d19a4902644 31 minutes ago 250MB kolla/mariadb-clustercheck 15.1.0 d84427d3c639 31 minutes ago 314MB kolla/mariadb-base 15.1.0 34447e3e59b6 31 minutes ago 314MB kolla/keepalived 15.1.0 82133b09fbf0 31 minutes ago 260MB kolla/prometheus-memcached-exporter 15.1.0 6c2d605f70ee 31 minutes ago 262MB <none> <none> e66b228c2a07 31 minutes ago 248MB kolla/rabbitmq 15.1.0 8de5c39379d3 32 minutes ago 309MB kolla/fluentd 15.1.0 adfd19027862 33 minutes ago 519MB kolla/haproxy-ssh 15.1.0 514357ac4d36 36 minutes ago 255MB kolla/haproxy 15.1.0 e5b9cfdf6dfc 37 minutes ago 257MB kolla/prometheus-haproxy-exporter 15.1.0 a679f65fd735 37 minutes ago 263MB kolla/prometheus-base 15.1.0 afeff3ed5dce 37 minutes ago 248MB kolla/glance-api 15.1.0 a2241f68f23a 38 minutes ago 1.04GB kolla/glance-base 15.1.0 7286772a03a4 About an hour ago 1.03GB kolla/neutron-infoblox-ipam-agent 15.1.0 f90ffc1a3326 About an hour ago 1.05GB kolla/neutron-server 15.1.0 69c844a2e3a9 About an hour ago 1.05GB kolla/neutron-l3-agent 15.1.0 4d87e6963c96 About an hour ago 1.05GB <none> <none> 486da9a6562e About an hour ago 1.05GB kolla/neutron-linuxbridge-agent 15.1.0 e5b3ca7e099c About an hour ago 1.04GB kolla/neutron-bgp-dragent 15.1.0 ac37377820c6 About an hour ago 1.04GB kolla/ironic-neutron-agent 15.1.0 90993adcd74b About an hour ago 1.04GB kolla/neutron-metadata-agent 15.1.0 8522f147f88d About an hour ago 1.04GB kolla/neutron-sriov-agent 15.1.0 8a92ce7d13c0 About an hour ago 1.04GB kolla/neutron-dhcp-agent 15.1.0 5c214b0171f5 About an hour ago 1.04GB kolla/neutron-metering-agent 15.1.0 7b3b91ecd77b About an hour ago 1.04GB kolla/neutron-openvswitch-agent 15.1.0 1f8807308814 About an hour ago 1.04GB kolla/neutron-base 15.1.0 f85b6a2e2725 About an hour ago 1.04GB kolla/nova-libvirt 15.1.0 0f3ecefe4752 About an hour ago 987MB kolla/nova-compute 15.1.0 241b7e7fafbe About an hour ago 1.47GB kolla/nova-spicehtml5proxy 15.1.0 b740820a7ad1 About an hour ago 1.15GB kolla/nova-novncproxy 15.1.0 1ba2f443d5c3 About an hour ago 1.22GB kolla/nova-compute-ironic 15.1.0 716612107532 About an hour ago 1.12GB kolla/nova-ssh 15.1.0 ae2397f4e1c1 About an hour ago 1.11GB kolla/nova-api 15.1.0 2aef02667ff8 About an hour ago 1.11GB kolla/nova-conductor 15.1.0 6f1da3400901 About an hour ago 1.11GB kolla/nova-scheduler 15.1.0 628326776b1d About an hour ago 1.11GB kolla/nova-serialproxy 15.1.0 28eb7a4a13f8 About an hour ago 1.11GB kolla/nova-base 15.1.0 e47420013283 About an hour ago 1.11GB kolla/keystone 15.1.0 e5530d829d5f 2 hours ago 947MB kolla/keystone-ssh 15.1.0 eaa7e3f3985a 2 hours ago 953MB kolla/keystone-fernet 15.1.0 8a4fa24853a8 2 hours ago 951MB kolla/keystone-base 15.1.0 b6f9562364a9 2 hours ago 945MB kolla/barbican-base 15.1.0 b2fdef1afb44 2 hours ago 915MB kolla/barbican-keystone-listener 15.1.0 58bd59de2c63 2 hours ago 915MB kolla/openstack-base 15.1.0 c805b4b3b1c1 2 hours ago 893MB kolla/base 15.1.0 f68e9ef3dd30 2 hours ago 248MB registry 2 8db46f9d7550 19 hours ago 24.2MB ubuntu 22.04 08d22c0ceb15 3 weeks ago 77.8MB

4 8

[neutron][ptg] Neutron PTG summary
by Rodolfo Alonso Hernandez 03 Apr '23

03 Apr '23

Hello Neutrinos: This is a quick summary of the PTG sessions last week. This is the etherpad used: https://etherpad.opendev.org/p/neutron-bobcat-ptg *Retrospective.* - Good: - Speed on RFE spec reviewal. - Continue the deprecation of non-supported code: Linux Bridge, neutronclient - Good CI tracking of external library dependencies: pyroute2, sqlalchemy - Good progress on TC goals, in particular sRBAC (now supported in Zed). - Close of stale bugs - Bad: - The use of devstack for newcomers, in particular because of Neutron. It was proposed to implement vagrant files that will work with ant IDE and will allow to deploy OpenStack easily. - Scenario CI jobs still running in Ubuntu Focal due to the nested virt provider issues: https://bugs.launchpad.net/neutron/+bug/1999249 - To be improved: - Engagement with students to join the Neutron community *Stadium projects.* SQLAlchemy 2.0 is the main problem right now. The CI "-sqlalchmey-master" jobs should help us to prepare these projects for the next framework version and we need to start now. Train branch is broken in most of the CIs. With https://review.opendev.org/c/openstack/releases/+/878202, all projects will be migrated to EOL. networking-odl will be deprecated: it is still testing against ODL 11, while the latest version is 16. Due to the lack of maintainers, we are no longer delivering a new release. *Release cadence.* New meeting the first Tuesday of each month (Neutron team meeting) to decide when to release a new project version. Transition Train to EOL: https://review.opendev.org/c/openstack/releases/+/878202 *python-neutronclient deprecation.* Both the CLI and the python bindings code: https://etherpad.opendev.org/p/python-neutronclient_deprecation We decided not to spend too much time on this goal, as long as there are other priorities. But we are going to mark this project as deprecated (README and mail); that means we'll only push patches for bugs but no new feature will be accepted. If any project is still using the CLI or the bindings and needs a new feature, it will need to migrate to SDK (that will help us on this common effort). *Port hints feature.* https://review.opendev.org/q/topic:port-hints It was considered to use the "tags" resource attribute but this functionality is very specific to the backend and the property is by default admin-only. We'll keep the current implementation (under review right now). *Stateless security groups.* This issue was found during the implementation of stateless SG in ML2/OVN. Main problems: - Semantics and mechanics defined in the documentation and the API. - DHCP and DHCPv6: as long as other FWs (ML2/OVS native and iptables) support both by default with stateless SGs, it will be implicitly supported too in ML2/OVN. That will be documented. Rationale: DHCP is a networking service and we should be able to provide IP in any case. - Metadata: no support. Users will need to explicitly define the egress/ingress rules to allow the metadata traffic (as is now in ML2/OVS FW drivers). *IPv6 prefix delegation.* https://bugs.launchpad.net/neutron/+bug/1895972 It was decided not to implement this feature during this release. At the same time it was decided to define L3 agent PD feature as "experimental" because the client used, dibbler, ended the support: https://bugs.launchpad.net/neutron/+bug/1916428 *Neutron agent status report.* https://bugs.launchpad.net/neutron/+bug/2011422 It was accepted to have a better report from the agent side of the current status, including if it was during the initial transient period, if the agent was doing a full sync, if it was restarted, etc. This functionality should also provide the ability of reporting customized status for particular agents. *DHCP agents with IPv6 metadata services.* https://bugs.launchpad.net/neutron/+bug/1953165 Several options were considered. The approved one was (3): to schedule a single IPv6 metadata agent per network, regardless of the HA number of DHCP agents. That will prevent the IPv6 DAD error now present; the DHCP agent will use that to stop spawning a new metadata agent (it will consider another DHCP agent has a running metadata server). No DB/API changes will be needed. *sRBAC, phase 2.* A new role called "service" will be created. It will identify the server to service calls during the normal operation. For example: Nova to Neutron port binding activation. During this cycle we need to identify the server-2-server calls, performed by other projects against the Neutron API and update these actions with the new role. *HWOL API for ports.* Same topic as commented during the last PTG: the HWOL functionality implies modifying the port binding, that is an admin-only property (and should always be like that). Normal users cannot create and request a port with this functionality if that port was not created before by an admin. It was also suggested (but at least rejected by me: config driven API is something now recommended) to have a configuration option to allow the creation of HWOL ports by default. *Delete on termination for Neutron ports.* The goal of this new feature is to mark the port in order to know if it needs to be deleted after the VM is deleted or not. This functionality is valid for user created ports, not Nova created ports (the last ones are always deleted when the VM is). Nova folks are investigating if "tags" API is valid or not for this RFE. If not, a new API will be proposed for Neutron ports. *Allow to specify the hardware model in the Neutron port.* The goal of this feature is to tint the port with a HW model. For example "hw_vif_model=virtio" or "hw_vif_model=e1000". Same as before, investigate if "tags" is valid or not. We are also considering improving "tags" to be a key-value model, instead of a list of strings only. *Add support for Napatech LinkVirt SmartNICs* https://review.opendev.org/c/openstack/nova-specs/+/859290 The OVS service is running on the NIC HW. It uses DPDK port representors (similar to devlink port representors but not present in kernel). There is a POC in gerrit to be reviewed (patches in the etherpad). The VNIC type was added some releases ago. The main issue of this RFE: the lack of CI support. This is why the main request for this company is to implement an external CI for zuul, adding some basic tempest tests. *Port binding activation duplication.* https://bugs.launchpad.net/neutron/+bug/1986003 It was decided to implement the current solution ( https://review.opendev.org/c/openstack/neutron/+/853281/) if a duplicated call is received by Neutron, it will raise a Conflict (409) exception, handled by Nova. *SR-IOV port tracking in Placement.* Still under definition. Several alternatives to the current ML2/SRIOV agent-resource reporting (for QoS) are presented, some of them exclusive to the current model. There is a etherpad to track the spec definition: https://etherpad.opendev.org/p/track-sriov-nics-in-placement *"skip-level" jobs this cycle (non SLURP).* It was decided: - To continue testing it but testing master against Zed. - To move the jobs to experimental and periodic queues. *ovn-bgp-agent roadmap.* It was decided to add ovn-bgp-agent to the Neutron stadium. The migration will be done during this release. The current API, provided by networking-bgpvpn, is not enough. It is under consideration to improve it or create a new one, just for OVN. It is also needed to improve the current documentation: installation, current uses, drivers available, etc. *Extend OVN db sync tool.* Now the OVN DB sync tool removes anything in the OVN NB DB that is not present in the Neutron DB. That clashes with some deployments, for example when using the OVN-IC to connect several nodes. E.g.: http://dani.foroselectronica.es/ovn-cluster-interconnection-567/ It will be proposed a pluggable interface to make the sync tool aware of these NB objects that have no counterpart in the Neutron DB but in other OVN DB (ovn-ic-nb, for example). *FIPS jobs, OS support.* Currently this functionality is only tested in CentOS8. CentOS9 has an issue with the conntrack module: https://bugs.launchpad.net/neutron/+bug/1976323 These jobs are not tested in Ubuntu in the CI because this is a paid feature. *Vancouver PTG.* We have registered the Neutron team for the Vancouver PTG. The topics to be discussed will be tracked in https://etherpad.opendev.org/p/neutron-vancouver-2023. Regards.

1 0

[openstack-ansible] Bobcat vPTG results
by Dmitriy Rabotyagov 03 Apr '23

03 Apr '23

Hi everyone, This year we didn't have many attendees, but I want to thank everyone who managed to join the discussion regarding further project plans and goals. 1. Things we'd love to work on to release 2023.1 (Antelope): * Documentation improvements. That includes: ** Since Zed we're using OVN as a default network driver, while most docs still refer to LXB in examples. We'd need to update architecture and most networking docs with regards to this change, as they might be misleading at the moment. ** Update Ironic documentation with regards to the latest changes to the role. ** Describe multi-arch deployments * Finalize internal TLS - encryption between haproxy and uwsgi backends that happens through the management network. We have couple of topics here ** Split haproxy configuration so that backends were configured per-service playbooks rather then while running haproxy one. https://review.opendev.org/q/topic:separated-haproxy-service-config ** Actually patching services to support TLS for backends https://review.opendev.org/q/topic:tls-backend ** Ensure we test in CI both TLS and non-TLS usecases for internal traffic. * Bump MariaDB version to the next LTS release - 10.11 * Adding support for leap upgrades to our upgrade script and CI * After switching to cloudsmith repo to be source for RabbitMQ and Erlang we struggle a lot with packages being obsoleted and removed randomly from the repo. With that we're going to execute following plan: ** Switch rabbitmq back to packagecloud - it contains packages for both deb and rpm ** Use minor releases of erlang rather than specific bugfix releases that will still come from cloudsmith. Hopefully that will fail less. ** File an issue to rabbitmq-erlang-deb to publish releases in github/packagecloud alike to rpms ** Track down state of ELS repo that could be used as alternative to cloudsmith given it's working reliably. * At the moment systemd services don't restart if only init overrides are applied. POC patch was proposed and this topic should track progress: https://review.opendev.org/q/topic:osa%252Fsystemd_restart_on_unit_change We will also attempt to backport this to stable branches with just the single vote as patches are quite trivial. 2. Bobcat goals * Pretty endpoint names. It's great to have a supported way of having pretty names in your endpoints, like compute.example.com. While this is completely possible to achieve with current codebase, we have ways to improve and ease the process of doing so. ** haproxy maps we've added should simplify the process a lot ** Add a boolean variable, that instead of concatenating vip_address + port, do service_type + vip_address in roles with ability of global override ** Fix certificates to include SAN or wildcard for all endpoint names ** document a way of doing that * There is a long-going confusion about variables external/internal_lb_vip_address as they could be either IP or an FQDN and then needing other vars for the IP in haproxy/keepalived. We can attempt to replace this variable with a more meaningful or intuitive one. ** With that change we also have a chance of fixing inconsistent service names (url vs. uri) across roles * At the moment PKI keys/certificates can't be stored in a trusted storage, as community.crypto.openssl_privatekey does require keys to be files on filesystem. With that we can replace such module with openssl_privatekey_pipe as then it can use different lookups. ** With that it would be also great to re-think/document a way of storing user-secrets outside of using ansible-vault (that's trivial). * With RabbitMQ 4.0 HA queues that are used now by default are going to be removed. Quorum queues can be used instead to provide HA for queues. Though they have quite different concepts. In order to migrate to them, the exchange needs to be re-created with the enabled persistence option. Easiest way to do that would be re-creating vhosts, which will result in significant downtime for services like nova or neutron, but that's the price that should be paid for the migration/upgrade. Topic can be tracked here: https://review.opendev.org/q/topic:osa%252Fquorum_queues * ansible-core 2.14 requires >=py39, so Ubuntu 20.04 support will be dropped early in the cycle. * We also discussed resuming efforts of fucntional testing with molecule. We came up with following requirements/pain ponts: ** avoid duplicated boilerplate in all repos ** a way to run tests locally, document that ** clean up current tox/test for projects to avoid confusion * We agreed on having a common role for managing openstack resources, like images, networks, flavors, etc. This is valuable not only for operators, but also for our service roles, like octavia or tempest, where we're creating specific resources in pretty different ways each time. Work has started in the plugins repo with ambition to move that to openstack collection in the future: https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/878794 * We're not sure about current IPv6-only deployments at the moment, when talking about public networks. While private networks is not smth we want to focus on right now, we need to ensure that IPv6-only public networks are supported and documented. Volunteers are highly appreciated for this work. * Releasing skyline role. While we have a POC role, Skyline doesn't meet internal requirements of OSA maintainers. So while we'd love to see role being released, it's unlikely to be a priority for majority of current team. So we're calling for volunteers to make Skyline role ready for releasing in Bobcat. * We also agreed to work on Core reviewers promotion/demotion policies and process, that should be published on Core reviewers page: https://docs.openstack.org/openstack-ansible/latest/contributor/core-review…

1 0

[ptl][monasca] Need PTL volunteer for OpenStack Monasca
by Dmitriy Rabotyagov 03 Apr '23

03 Apr '23

Hi everyone, I am reaching out to find interested parties to maintain the OpenStack Monasca project. At the moment there is no PTL candidate for the next cycle (2023.2), and it is on the leaderless project list [1]. In case there are no interested parties to lead this project, TC might take the decision to retire it. If you're interested to help out with the project maintenance to keep it alive, please kindly reach out to TC either by replying to this email or joining us on IRC OFTC network in #openstack-tc channel. [1] https://etherpad.opendev.org/p/2023.2-leaderless

1 0

[tripleo] Removal of TripleO Master Integration and Component Lines
by Ronelle Landy 03 Apr '23

03 Apr '23

Hello All, Removal of TripleO Master Integration and Component Lines Per the decision to not maintain TripleO after the Zed release [1], the master/main integration and component lines are being removed in the following patches: https://review.rdoproject.org/r/c/config/+/48073 https://review.rdoproject.org/r/c/config/+/48074 https://review.rdoproject.org/r/c/rdo-jobs/+/48075 The last promoted release of master through TripleO is: https://trunk.rdoproject.org/centos9-master/current-tripleo/delorean.repo (hash: ddce25bad764dde7e0515094b4d40471), which was promoted on 03/28/2023. Check/gate testing for the master branch is in process of being removed as well. [1] https://review.opendev.org/c/openstack/governance/+/878799

3 2

[kolla] horizon image build failed
by Satish Patel 03 Apr '23

03 Apr '23

Folks, All other images build successfully but when i am trying to build horizon which failed with following error: $ kolla-build --registry docker-reg:4000 -b ubuntu -t source --tag zed horizon INFO:kolla.common.utils.horizon:Collecting XStatic-Dagre>=0.6.4.0 INFO:kolla.common.utils.horizon: Downloading XStatic_Dagre-0.6.4.1-py2.py3-none-any.whl (140 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 140.0/140.0 kB 14.4 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Collecting XStatic-Dagre-D3>=0.4.17.0 INFO:kolla.common.utils.horizon: Downloading XStatic_Dagre_D3-0.4.17.0-py2.py3-none-any.whl (357 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 357.4/357.4 kB 13.5 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Requirement already satisfied: XStatic-Font-Awesome>=4.7.0.0 in /var/lib/kolla/venv/lib/python3.10/site-packages (from vitrage-dashboard==3.6.1.dev2) (4.7.0.0) INFO:kolla.common.utils.horizon:Collecting XStatic-Graphlib>=2.1.7.0 INFO:kolla.common.utils.horizon: Downloading XStatic_Graphlib-2.1.7.0-py2.py3-none-any.whl (51 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 51.5/51.5 kB 114.3 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Requirement already satisfied: XStatic-jQuery>=1.8.2.1 in /var/lib/kolla/venv/lib/python3.10/site-packages (from vitrage-dashboard==3.6.1.dev2) (1.12.4.1) INFO:kolla.common.utils.horizon:Collecting XStatic-lodash>=4.16.4.1 INFO:kolla.common.utils.horizon: Downloading XStatic_lodash-4.16.4.2-py3-none-any.whl (167 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 167.9/167.9 kB 12.4 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Collecting XStatic-moment>=2.8.4.1 INFO:kolla.common.utils.horizon: Downloading XStatic_moment-2.8.4.3-py3-none-any.whl (58 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 58.0/58.0 kB 66.7 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Collecting XStatic-Moment-Timezone>=0.5.22.0 INFO:kolla.common.utils.horizon: Downloading XStatic-Moment-Timezone-0.5.22.0.tar.gz (99 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 99.7/99.7 kB 45.1 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon: Preparing metadata (setup.py): started INFO:kolla.common.utils.horizon: Preparing metadata (setup.py): finished with status 'error' INFO:kolla.common.utils.horizon: error: subprocess-exited-with-error INFO:kolla.common.utils.horizon: INFO:kolla.common.utils.horizon: × python setup.py egg_info did not run successfully. INFO:kolla.common.utils.horizon: │ exit code: 1 INFO:kolla.common.utils.horizon: ╰─> [6 lines of output] INFO:kolla.common.utils.horizon: Traceback (most recent call last): INFO:kolla.common.utils.horizon: File "<string>", line 2, in <module> INFO:kolla.common.utils.horizon: File "<pip-setuptools-caller>", line 34, in <module> INFO:kolla.common.utils.horizon: File "/tmp/pip-install-dqag1zef/xstatic-moment-timezone_60eeadc1dfb9492781fe3ca90e3b95c2/setup.py", line 2, in <module> INFO:kolla.common.utils.horizon: from xstatic.pkg import moment_timezone as xs INFO:kolla.common.utils.horizon: ImportError: cannot import name 'moment_timezone' from 'xstatic.pkg' (unknown location) INFO:kolla.common.utils.horizon: [end of output] INFO:kolla.common.utils.horizon: INFO:kolla.common.utils.horizon: note: This error originates from a subprocess, and is likely not a problem with pip. INFO:kolla.common.utils.horizon: INFO:kolla.common.utils.horizon:error: metadata-generation-failed INFO:kolla.common.utils.horizon:× Encountered error while generating package metadata. INFO:kolla.common.utils.horizon:╰─> See above for output. INFO:kolla.common.utils.horizon:note: This is an issue with the package mentioned above, not pip. INFO:kolla.common.utils.horizon:hint: See above for details. INFO:kolla.common.utils.horizon: INFO:kolla.common.utils.horizon:Removing intermediate container e6cd437ba529 ERROR:kolla.common.utils.horizon:Error'd with the following message ERROR:kolla.common.utils.horizon:The command '/bin/sh -c ln -s horizon-source/* horizon && sed -i /^horizon=/d /requirements/upper-constraints.txt && SETUPTOOLS_USE_DISTUTILS=stdlib python3 -m pip --no-cache-dir install --upgrade -c /requirements/upper-constraints.txt /horizon && mkdir -p /etc/openstack-dashboard && cp -r /horizon/openstack_dashboard/conf/* /etc/openstack-dashboard/ && cp /horizon/openstack_dashboard/local/local_settings.py.example /etc/openstack-dashboard/local_settings && cp /horizon/manage.py /var/lib/kolla/venv/bin/manage.py && if [ "$(ls /plugins)" ]; then SETUPTOOLS_USE_DISTUTILS=stdlib python3 -m pip --no-cache-dir install --upgrade -c /requirements/upper-constraints.txt /plugins/*; fi && for locale in /var/lib/kolla/venv/lib/python3.10/site-packages/*/locale; do (cd ${locale%/*} && /var/lib/kolla/venv/bin/django-admin compilemessages) done && chmod 644 /usr/local/bin/kolla_extend_start' returned a non-zero code: 1 INFO:kolla.common.utils:========================= INFO:kolla.common.utils:Successfully built images INFO:kolla.common.utils:========================= INFO:kolla.common.utils:base INFO:kolla.common.utils:openstack-base INFO:kolla.common.utils:=========================== INFO:kolla.common.utils:Images that failed to build INFO:kolla.common.utils:===========================

4 8

[Horizon][policy][keystone][yoga] allow __member__ role to create user
by James Leong 03 Apr '23

03 Apr '23

Hi all, I have deploy openstack in yoga version using kolla-ansible. I noticed that only admin role can create a new user. Would it be possible to also allow user with __member__ role to create user in the respective project. Best, James

2 3

Unable to create external vlan network | openstack wallaby
by Swogat Pradhan 01 Apr '23

01 Apr '23

Hi, I have an openstack setup which already has vm's running on it and other external and internal networks. I configured DCN recently adding 2 additional sites and while testing the services, I found I am unable to create external vlan networks for some reason, whereas other networks like geneve are getting created. Horizon is throwing 1 error and that is Internal server error, i am not sure why this happened, or how to solve this issue. Can someone please suggest? With regards, Swogat Pradhan

1 3