- openstack-discuss - lists.openstack.org

[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

[tc] No TC weekly meeting next week
by Nikolla, Kristi 31 Mar '23

31 Mar '23

Hi all, There will be no TC meeting on Tuesday, April 4th. The next TC meeting will be held on Tuesday, April 11 at 18.00 UTC. More information and an ICS file can be found here https://meetings.opendev.org/#Technical_Committee_Meeting Thank you, Kristi Nikolla

1 0

[release] Release countdown for week R-26, Apr 03 - 07
by Elõd Illés 31 Mar '23

31 Mar '23

Hi, Welcome back to the release countdown emails! These will be sent at major points in the 2023.2 Bobcat development cycle, which should conclude with a final release on October 4th, 2023. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2023.2 Bobcat development cycle and approving 2023.2 Bobcat specs. General Information ------------------- 2023.2 Bobcat is a 28 weeks long development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/bobcat/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2023.1 Antelope release are continued in 2023.2 Bobcat with a similar release model. Upcoming Deadlines & Dates -------------------------- Bobcat-1 milestone: May 11th, 2023 OpenInfra Summit + PTG Vancouver 2023 - June 13-15, 2023 Előd Illés irc: elodilles @ #openstack-release

1 0

[heat][qa][requirements] Pinning tempest in stable/xena constraints
by Takashi Kajinami 31 Mar '23

31 Mar '23

Hello, I have had some local discussions with gmann, but I'd really like to move this discussion forward to fix the broken stable/xena gate in heat so I will start this thread, hoping the thread can provide more context behind my proposal. Historically stable branches of heat have been frequently affected by any change in requirements of tempest. This is mainly because in our CI we install our own in-tree integration tests[1] into tempest venv where tempest and heat-tempest-plugin are installed. Because in-tree integration tests are tied to that specific stable branch, this has been often causing conflicts in requirements (master constraint vs stable/X constraint). [1] https://github.com/openstack/heat/tree/master/heat_integrationtests In the past we changed our test installation[2] to use stable constraint to avoid this conflicts, but this approach does no longer work since stable/xena because 1. stable/xena u-c no longer includes tempest 2. latest tempest CAN'T be installed with stable/xena u-c because current tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c. [2] https://review.opendev.org/c/openstack/heat/+/803890 https://review.opendev.org/c/openstack/heat/+/848215 I've proposed the change to pin tempest[3] in stable/xena u-c so that people can install tempest with stable/xena u-c. [3] https://review.opendev.org/c/openstack/requirements/+/878228 I understand the reason tempest was removed from u-c was that we should use the latest tempest to test recent stable releases.I agree we can keep tempest excluded for stable/yoga and onwards because tempest is installable with their u-c, but stable/xena u-c is no longer compatible with master. Adding pin to xena u-c does not mainly affect the policy to test stable branches with latest tempest because for that we anyway need to use more recent u-c. I'm still trying to find out the workaround within heat but IMO adding tempest pin to stable/xena u-c is harmless but beneficial in case anyone is trying to use tempest with stable/xena u-c. Thank you, Takashi Kajinami

4 10