- openstack-discuss - lists.openstack.org

No bug meeting today
by Sofia Enriquez 02 Nov '22

02 Nov '22

-- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[Kolla-ansible][Yoga] which version of fedora-core to use with Magnum?
by wodel youchi 01 Nov '22

01 Nov '22

Hi, Could you point out which version of fedora-core to use with magnum? Is it the same as Xena : fedora-core 33? Regards.

1 0

[Kolla-ansible][Xena] How to update an Openstack deployment with new containers?
by wodel youchi 01 Nov '22

01 Nov '22

Hi, The documentation of kolla-ansible Xena does not talk about updating an existing Xena deployment with new containers. Could you please help with this? I found some lines about that in Yoga version, saying that, to update an existing deployment you have to : 1 - Update kolla-ansible it self : $ source xenavenv (xenavenv) $ pip install --upgrade git+ https://opendev.org/openstack/kolla-ansible@stable/xena 2 - Update the container Images with Docker pull 3 - Update my local registry if I am using one, and in my case I am, so I deleted the registry images then I recreated them. 4 - Then finally deploy again (xenavenv) $ kolla-ansible -i multinode deploy Is this the right procedure? because I followed the same procedure and I think it didn't change anything. For example I am taking nova-libvirt container as and example, in my local registry I have this : [root@rcdndeployer2 ~]# docker images | grep nova-libvirt 192.168.2.34:4000/openstack.kolla/centos-source-nova-libvirt xena 5be83d680102 31 hours ago 2. 34GB quay.io/openstack.kolla/centos-source-nova-libvirt xena *5be83d680102* *31 hours ago * 2. 34GB [root@rcdndeployer2 ~]# docker inspect -f '{{ .Created }}' *5be83d680102 * *2022-10-25*T02:33:13.172550584Z But in my compute nodes I have this : root@computehci24 ~]# docker ps | grep nova-lib b56a12bfd482 192.168.2.34:4000/openstack.kolla/centos-source-nova-libvirt:xena "dumb-init --single-…" *5 months ag**o Up Up 5 months (healthy) nova_libvirt* Regards.

1 1

[cinder][PTG] 2023.1 Antelope PTG Summary
by Rajat Dhasmana 01 Nov '22

01 Nov '22

Hello everyone, Here[1] is the summary of 2023.1 Antelope Cinder PTG conducted from 18th October to 21st October 2022, 1300-1700 UTC. The link to the etherpad and recordings are included. The action items are added in *conclusion* section of each topic. Let me know if any information needs to be updated. [1] https://wiki.openstack.org/wiki/CinderAntelopePTGSummary - Rajat Dhasmana

1 0

[all] [tripleo] opendev Gerrit is down
by Cédric Jeanneret 01 Nov '22

01 Nov '22

Hello there, For those who didn't get the IRC notification earlier today: gerrit is dead. The Infra team is working on that issue, but it will apparently take some time. Thank you for your patience! Cheers, C. -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/

1 1

Discontinuing Winstackers
by Lucian Petrut 01 Nov '22

01 Nov '22

Running Openstack on Windows has been driven by Cloudbase Solutions ever since Folsom (2012). Here are the most noteworthy contributions: * nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver * os-win - common Windows library for Openstack * neutron hyperv ml2 plugin and agent * ovs on Windows and neutron ovs agent support * cinder drivers - SMB and Windows iSCSI * os-brick Windows connectors - iSCSI, FC, SMB, RBD * ceilometer Windows poller * manila Windows driver * glance Windows support * freerdp gateway * last but not least, CI test systems for (most of) the above Due to a shift in business focus and the increased operational costs of maintaining the CI systems, we are no longer in a position to proactively support Openstack on Windows. However, we will continue to support Cloudbase-init (cloud-init equivalent for Windows) as well as the Openstack Windows imaging tools. If there are any interested parties that would like to step up as Winstacker maintainers, please let us know and we will provide any required assistance. Regards, Lucian Petrut Cloudbase Solutions Winstackers PTL

1 0

Delivery reports about your e-mail
by mark＠stackhpc.com 01 Nov '22

01 Nov '22

The original message was received at Tue, 1 Nov 2022 07:26:06 +0900 from stackhpc.com [42.37.153.10] ----- The following addresses had permanent fatal errors ----- <openstack-discuss(a)lists.openstack.org>

1 0

[OSSN-0091] BMC emulators developed in OpenStack community do not preserve passwords on VMs
by Jay Faulkner 31 Oct '22

31 Oct '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ## Summary ## When deploying VirtualBMC or Sushy-Tools in an unsupported, production-like configuration, it can remove secret data, including VNC passwords, from a libvirt domain permanently. Operators impacted by this vulnerability must reconfigure any secret data, including VNC passwords, for the libvirt domain. These virtual machine emulators are tools to help emulate a physical machine's Baseboard Management Controller (BMC) to aid in development and testing of software that would otherwise require physical machines to perform integration testing activities. They are not intended or supported for production or long-term use of any kind. ## Affected Services / Software ## * Sushy-Tools, <=0.21.0 * VirtualBMC, <=2.2.2 There is no impact to any OpenStack software or services intended for production use. ## Patches ## * VirtualBMC: https://review.opendev.org/c/openstack/virtualbmc/+/862620 * Sushy-Tools: https://review.opendev.org/c/openstack/sushy-tools/+/862625 ## Discussion ## To perform some advanced operations on Libvirt virtual machines, the underlying XML document describing the virtual machine's domain must be extracted, modified, and then updated. These specific actions are for aspects such as "setting a boot device" (VirtualBMC, Sushy-Tools), Setting a boot mode (Sushy-Tools), and setting a virtual media device (Sushy-Tools). This issue is triggered when a VM has any kind of "secure" information defined in the XML domain definition. If an operator deploys VirtualBMC or Sushy-Tools to manage one of these libvirt VMs, the first time any action is performed that requires rewriting of the XML domain definition, all secure information -- including a VNC console password, if set -- is lost and removed from the domain definition, leaving the libvirt VM's exposed to a malicious console user. ## Recommended Actions ## Operators who may have been impacted by this vulnerability should immediately remove use of VirtualBMC and/or Sushy-Tools from their production environment. Then, validate and if necessary, reconfigure passwords for VNC access or any other impacted secrets. ## Notes ## The OpenStack team will ensure documentation is updated to clearly state these software packages are intended for development/CI use only, and are not safe to run in production. ## Credits ## Julia Kreger from Red Hat ## References ## Author: Jay Faulkner, G-Research Open Source Software This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0090 Original Storyboard bug: https://storyboard.openstack.org/#!/story/2010382 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2022-44020 -----BEGIN PGP SIGNATURE----- Version: FlowCrypt Email Encryption 8.3.8 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAGBQJjYDhhACEJEGt12Tm0JMbUFiEEvF1YmsGLSYuWqE+ta3XZ ObQkxtSCUw/9FEeakvlf06BWrk5Lc3TGwUKV0WiLaE4M0xjljkzg/3/580/E nhOTl/raPszlzgkGdrQTaH3Sj4AwUTdPHqqxjyK/Xb1DIm+CfS3bdbP0aLHG Y3Su4Z74unMaKbnbyDYhM1qMIzPyBruLpqiyYJGhSuzU/fu1O/LCWfSicvKK YDmAHJ9TjXuTMdWrLrkMknvJaLe0aJrNW5iqDnIh6YrUC2Pioi5h+OFKwDpn Ea+YnlAxKR7OQGRGcY3AwP1Jq87pdHZagcVThc/wnCATKT/FtaIogDkUnoMn qI+6MNjV3R4kyQCbyo35KeIDWm+541XsK0GoR5hcvR1AkwciSPBAkt3VHxpa p0g9hVcNTv+tWwN8LrdLRPMDuqKA51eNUvQCV8W+H42wS0uoaMPXglbZIuwv AmEoK8UC8Gii8cPoIkiZGSSOo4i+tlE/q+L/Mgs1opyt1Klcxs/Lm1PNylET XqLw70qKrfqWabZpKUxMS3F9JwyCkgnD5+t2x/qsqg5Hq+kUZqP8be3Oc7K7 He/gIneWDMpH1+J9Tm5ofyxtJCA+V96+cXoXYk8SncVf/O5djgd48UkQo1iJ NZlKxJsaKH5+JyPuXkR6hyqDrIkmbJRh4aU9nJBQyFho0fXuQVlC2iUOGa0F BgUFs5J6oQtglAAuyUoNuhuBJBwdW09NxQ4= =6yXE -----END PGP SIGNATURE-----

1 1

[oslo][tooz][openstack-ansible] Discussion about coordination (tooz), too many backend options, their state and deployment implications
by Christian Rohmann 31 Oct '22

31 Oct '22

Hallo openstack-discuss, apologies for this being quite a long message - I tried my best to collect my thoughts on the matter. 1) The role of deployment tooling in fulfilling the requirement for a coordination backend I honestly write this, triggered by openstack-ansible plans to add coordination via the Zookeeper backend (https://lists.openstack.org/pipermail/openstack-discuss/2022-October/031013…) On 27/10/2022 13:10, Dmitriy Rabotyagov wrote: > * Add Zookepeer cluster deployment as coordination service. > Coordination is required if you want to have active/active > cinder-volume setup and also actively used by other projects, like > Octavia or Designate. Zookeeper will be deployed in a separate set of > containers for LXC path First of all I believe it's essential for any OpenStack deployment tooling to handle the deployment of a coordination backend as many OS projects just rely in their design and code to have it in place. But I am convinced though there too many options, that some stronger guidance should be given to people designing and then deploying OS for their platform. This guidance certainly can be in the form of a comparison table - but when it comes to using deployment tooling like openstack-ansible, the provided "default" component or options for something might just be worth more than written text explaining all of the possible approaches. This hold especially true to me as you can get quite far with no coordination configured which then results in frustration and invalid bugs being raised. And it's not just openstack-ansible thinking about coordination deployment / configurations. To just point to a few: * Kolla-Ansible: https://lists.openstack.org/pipermail/openstack-discuss/2020-November/01883… * Charms: https://bugs.launchpad.net/charm-designate/+bug/1759597 * Puppet: https://review.opendev.org/c/openstack/puppet-oslo/+/791628/ * ... 2) Choosing the "right" backend driver I've recently been looking into the question what would be the "best" tooz driver to cover all coordination use cases the various OS projects require. Yes, the dependencies and use of coordination within the OS projects (cinder, designate, gnocchi, ...) are very different. I don't want to sound unfair, but most don't communicate which of the Tooz services they actually require. In any case, I might just like something to cover all possible requirements to "set it (up) and forget it, no matter what OS projects run on the platform. Apart from basic compatibility, there are qualities I would expect (in no particular order) from a coordination backend: * no "best-effort" coordination, but allowing for actual reliance on it (CP if talking CAP) * HA - this needs to be working just as reliably as my database as otherwise the cloud cannot function * efficient in getting the job done (e.g. support for events / watches to reduce latency) * lightweight (deployment), no additional components, readily packaged * very little maintenance operations * easy monitoring I started by reading into the tooz drivers (https://docs.openstack.org/tooz/latest/user/drivers.html) of which there are more than enough to require some research. Here are my rough thoughts: a) I ruled out the IPC, file or RDBMs (mysql, postgresql) backend options as they all have strong side-notes (issues when doing replication or no HA at all). Additionally they usually are not partition tolerant or support watches. b) Redis seems quite capable, but there are many side notes about HA and this also requires setting up and maintaining sentinel. c) Memcached supports all three services (locks, groups, leader-election) tooz provides and is usually already part of an OpenStack infrastructure. So looked appealing. But it's non-replicating architecture and lack of any strong consistency guarantees make it less of a good "standard". I was even wondering how tooz would try it's best to work with multiple memcached nodes (https://bugs.launchpad.net/python-tooz/+bug/1970659) d) Then there only is Zookeeper left, which also ticks all the (feature-)boxes (https://docs.openstack.org/tooz/latest/user/compatibility.html) and is quite a proven tool for coordination also outside of the OpenStack ecosystem. On the downside it's not really that well known and common (anymore) outside the "data processing" context (see https://cwiki.apache.org/confluence/display/ZOOKEEPER/PoweredBy) Being a Java application it requires a JVM and its dependencies and is quite memory heavy to store just a few megabytes of config data. Looking at more and more people putting their OS control plane into something like Kubernetes it also seems even less suitable to be "moved around" a lot. Another issue might be the lack of a recent and non-EoL version packaged in Ubuntu - see https://bugs.launchpad.net/ubuntu/+source/zookeeper/+bug/1854331. Maybe (!) this could be an indication of how commonly it is used outside of e.g. Support from TLS was only added in 3.5.5 (https://zookeeper.apache.org/doc/r3.5.5/zookeeperAdmin.html#Quorum+TLS) e) Consul - While also well known and loved, it has, like Zookeeper, quite a big footprint and is way more than just a CP-focused database. It's more of an application with man use cases. f) A last "strong" candidate is etcd. It did not surprise me to see it on the list of possible drivers and certainly is a tool known to many from running e.g. Kubernetes. It's actually already part of openstack-ansible deployment code as a role (https://github.com/openstack/openstack-ansible/commit/2f240dd485b123763442a…) as it is required when using Calico as SDN. While etcd is also something one must know how to monitor and operate, I allow me to say it might just be more common to find this operational knowledge. Also etcd has a smaller footprint than Zookeeper and it beeing "just a Golang binary" comes with (no) less dependencies. But I noticed that it does not even support "grouping", according to the feature matrix. But apparently this is just a documentation delay, seehttps://bugs.launchpad.net/python-tooz/+bug/1995125. What's left to implement would be leader-election, but there seems to be no technical reason why this cannot be done. this by no means is a comparison with a clear winner. I just want to stress how confusing having lots of options with no real guidance are. The requirement to chose and deploy coordination might not be a focus when looking into designing an OS cloud. 3) Stronger guidance / "common default", setup via OS deployment tooling and also used for DevStack and tested via CI To summarize, there are just too many options and implications in the compatibility list to quickly chose the "right" one for one's own deployment. While large-scale deployments might likely not mind for coordination to have a bigger footprint and requiring more attention in general. But for smaller and even mid-size deployments, it's just convenient to offload the configuration of coordination and the selection the backend driver to the deployment tooling. Making it way too easy for such installations to not use coordination and running into issues or every other installation using a different backend creates a very fragmented landscape. Add different operating system distributions and versions, different deployment tooling, different set and versions of OS projects used, there will be so many combinations. This will likely just cause OS projects to receive more and non-reproducible bugs. Also not having (a somewhat common) coordination (backend) used within CI and DevStack does not expose the relevant code paths to enough testing. I'd like to make the analogy to having "just" MySQL as the default database engine, while still allowing other engines to be used (https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.…) Or labeling certain options as "experimental" as Neutron just did with "linuxbridge" (https://docs.openstack.org/neutron/latest//admin/config-experimental-framew…) or cinder with naming drivers unsupported (https://docs.openstack.org/cinder/ussuri/drivers-all-about.html#unsupported…) My point is that just having all those backends and no active guidance might make Tooz a very open and flexible component. I myself would wish for some less confusion around this topic and having a little less to think about this myself. Maybe the "selection" of Zookeeper by openstack-ansible is just that? I would love to hear your thoughts on coordination and why and how you ended up with using what. And certainly what your opinion on the matter of a stronger communicated "default" is. Thanks for your time and thoughts! Christian

3 3

[neutron] Bug Deputy Report October 24-30
by Nurmatov Mamatisa 31 Oct '22

31 Oct '22

Hi, Below is the week summary of bug deputy report for last week. One RFE was proposed and already discussed on drivers meeting, more information should be provided. Details: Critical -------- - https://bugs.launchpad.net/neutron/+bug/1995091 - [CI] "neutron-functional-with-oslo-master" failing with timeout - Confirmed - Unassigned - https://bugs.launchpad.net/neutron/+bug/1994491 - Functional tests job is failing on Ubuntu 22.04 - Incomplete - Assigned to Rodolfo Alonso Medium ------ - https://bugs.launchpad.net/neutron/+bug/1995031 - [CI][periodic] neutron-functional-with-uwsgi-fips job failing - Confirmed - Unassigned - https://bugs.launchpad.net/neutron/+bug/1994635 - [CI][tempest] Error in "test_multiple_create_with_reservation_return" - Confirmed - Assigned to Rodolfo Alonso Undecided --------- - https://bugs.launchpad.net/neutron/+bug/1995078 - OVN: HA chassis group priority is different than gateway chassis priority - New - Unassigned RFEs ---- - https://bugs.launchpad.net/neutron/+bug/1994137 - [RFE] Specify the precedence of port routes if multiple ports attached to a VM - Incomplete - Unassigned Best regards, Mamatisa Nurmatov Advanced Software Technology Lab / Cloud Technologies Research

1 0

[all][tc] What's happening in Technical Committee: summary 2022 Oct 28: Reading: 5 min
by Ghanshyam Mann 29 Oct '22

29 Oct '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Oct 27. Most of the meeting discussions are summarized in this email. Meeting logs are available @ https://meetings.opendev.org/meetings/tc/2022/tc.2022-10-27-15.00.log.html * Next TC weekly meeting will be on Nov 3 Thursday at 15:00 UTC, feel free to add the topic to the agenda[1] by Nov 2. 2. What we completed this week: ========================= * 2021 User Survey TC Question Analysis[2] * Appointed hongbin as Zun PTL[3] 3. Activities In progress: ================== TC Tracker for 2023.1 cycle --------------------------------- * I have prepared the 2023.1 tracker etherpad which includes the TC working items for the 2023.1 cycle[4]. Open Reviews ----------------- * Four open reviews for ongoing activities[5]. 2023.1 cycle TC PTG Summary ------------------------------------- I sent the TC sessions and TC+Leader discussion summary on ML[7][8]. User Survey: --------------- TC worked on the modification of TC questions for the 2023 survey[9]. TC chair nomination & election process ----------------------------------------------- We are formalizing the process of TC chair nomination process. Two options are up for the review[10][11]. Fixing Zuul config error ---------------------------- We request projects having zuul config error to fix them, Keep supported stable branches as a priority and Extended maintenance stable branch as low priority[12]. Project updates ------------------- * None. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15:00 UTC [14] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. See you all next week in PTG! [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/836888 [3] https://review.opendev.org/c/openstack/governance/+/860759 [4] https://etherpad.opendev.org/p/tc-zed-tracker [5] https://review.opendev.org/q/projects:openstack/governance+status:open [7] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030954… [8] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030953… [9] https://etherpad.opendev.org/p/tc-2023-user-survey-questions [10] https://review.opendev.org/c/openstack/governance/+/862772 [11] https://review.opendev.org/c/openstack/governance/+/862774 [12] https://etherpad.opendev.org/p/zuul-config-error-openstack [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[tacker][ptg] Antelope PTG Summary
by Yasufumi Ogawa 28 Oct '22

28 Oct '22

Hi all, We had great PTG sessions in Tacker team, and hopefully all. This is a summary of what we discussed during our sessions in three days. All of items and the results of discussion is here [1]. Day 1 (18 Oct 2022) 1. Reducing resources for FTs - We shared suggestions for fixing critical issues in functional tests in which we've had some unreasonable failures, especially at the end of releases. - Removing/deprecating unecessary legacy features and its tests. - Quick analysis for the failures [1]. - Wishlist for the item [2]. - Agree to focus on jobs has the large num of failures to revise tests. 2. Support tacker-db-manage for Multi DB backend - Support for PostgreSQL doesn't work, for insatnce, some issues in tacker-db-manage. - We agreed to not only fix the issues, but also take care other backends. - Revise tacker-db-manage for supporting multi DB backend. Start to support Postgres in antelope first, and other ones in the next releases then. - Proposed design is not so mature for now, so continue to discuss to revise. 3. Migrate OpenStack testing from Ubuntu Focal (20.04) to Ubuntu Jammy (22.04) - We agreed to migrate Focal to Jammy Ubuntu release as one of the community goal in this release [4]. - Candidate patches for the update have already proposed by manpreetk not only for tackder but also other releated projs. - https://review.opendev.org/c/openstack/tacker/+/861137 - https://review.opendev.org/c/openstack/tacker-horizon/+/861571 - https://review.opendev.org/c/openstack/python-tackerclient/+/861572 - https://review.opendev.org/c/openstack/tosca-parser/+/861136 - https://review.opendev.org/c/openstack/heat-translator/+/861158 https://etherpad.opendev.org/p/migrate-to-jammy 4. Bug Triage in Tacker - Add item of bug triage in IRC etherpad to discuss about bug triage. Day 2 (19 Oct 2022) 1. Operator Hour - Guys from KDDI and NTT Docomo joined and proposed their proposals as telcom operators [5]. 1.1. Support of redanduncy - For availability, essential to make Tacker redundant for commercial use, but less than we expected for the current impl. - What is the tacker specific consideration point is store VNF packages. 1.2. Error handling and recovering operation - More tests for changing error status, disaster recovery are required. 1.3. Detailed logs - Not enough log messages especially for management drivers. - Error message in tacker-server.log and tacker-conductor.log is usefull and enough for vnfm-admin, but like openstack vnflcm op show comannd and api's information is not enough for vnfm-user. 1.4. Roadmap - Having explicit roadmap is helpful for oprators to be interested. - Comply with ETSI NFV Rel4 is one of the good example for the direction. 2. Add sample coordinate VNF script using coordination API - We agreed to implement interfaces ETSI NFV SOL002 v3.5.1 defines the Coordination VNF interface for coordination with external management components. 3. Revise automatic operation state transition for N-Act configuration - v2API has a function to automatically transition opocc in an intermediate state to the final state when the tacker-conductor starts up, to recover inoperable opocc in the PROCESSING state by conductor down. - It causes a problem in N-Act setting. The opocc which are being handled by other working conductors are also automatically transitioned to the final state. We propose solutions for limiting opocc to be transitioned to those handled by the downed conductor. 4. Set different number of instances for same delta and aspectId - Fix overwriting the value for same aspect and delta id. - Multi VDUs Scale of V1 API isn’t supported by the issue. 5. Continue to update the remaining patch from Zed version - Move forward reviews on gerrit. Day 3 (20 Oct 2022) 1. Enhancement of Tacker API Resource Access Policy - Current Tacker policy control access to API resources by default role such as admin or any only. - We propose Fine-grained API resource access management based on user and VNF information according to operator usecases. 2. Secure RBAC: Implement support for project-reader persona in Tacker - As per the TC and community wide goal, next cycle 2023.1 is the must for all projects to implement the phase-1 (project personas). Plan to do it in Tacker in 2023.1 cycle will be helpful in community wide goal [6][7]. - Conclusions: Clarify conflicts can be caused while introducing new roles of S-RBAC to implement the fine grained APIs 3. Support Tacker auto-scale and auto-heal without NFVO (k_fukaya) - Zed release supported, Fault Management/ Performance Management(FM/PM) interfaces, and AutoHeal and AutoScale with external monitoring. However, Heal or Scale execution must be triggered by NFVO. This feature proposes implementing support receiving alerts from external monitoring tools, which can be VNFM driven AutoHeal and AutoScale without NFVO. 4. Discuss Tacker support versions and updates for K8s/Helm/Prometheus - The support versions in Antelope should be determined, as some versions may be inconsistent and support may expire before release. Considering the support period and development risk, it seems good to decide on the following. - k8s : 1.25 (current latest version) - helm : 3.10 (current latest version) - prometheus : 2.42 (next LTS version) - Update test patch for k8s 1.25.2 and helm 3.10.1 - https://review.opendev.org/c/openstack/tacker/+/860633 (Zuul +1) - Add version information under user guide. 5. AWS vim support - Add support for EC2 as VIM for the first step for AWS. - Whole discussion is here [8]. 6. Marking Deprecated and obsoleting of Legacy API - Should start to discussion about deprecation and obsoleting Legacy Tacker API (excluding VIM feature). - Deprecation process should follow as "Deprecation Guidelines" [9]. - The key point is - APIs should be marked deprecated before obsoleting and should be marked for at least 12 months. - An email thread will be started on openstack-discuss to determine how many people are using the deprecated API. - We will continue our discussion and move towards removing the Legacy API (excluding VIM feature). [1] https://etherpad.opendev.org/p/tacker-antelope-ptg [2] https://etherpad.opendev.org/p/tacker-antelope-failures-analysis [3] https://bugs.launchpad.net/tacker/+bug/1993187 [4] https://governance.openstack.org/tc/goals/selected/migrate-ci-jobs-to-ubunt… [5] https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-tacker [6] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [7] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030863… [8] https://etherpad.opendev.org/p/tacker-antelope-aws-vim-support [9] https://docs.openstack.org/project-team-guide/deprecation.html#guidelines

1 0

[horizon] missing reviews for cinder backup filtering
by Mohammed Naser 28 Oct '22

28 Oct '22

Hi folks, We're nearing a very long time that this patch has been open, it's undergone several revisions from our team and sitting idle almost 2 months. https://review.opendev.org/c/openstack/horizon/+/791532/ Can we please help get this landed, we're trying our best to stick to our upstream only :) Thanks Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[Ceilometer] RADOS GW metrics : cannot get radosgw.objects.size metric
by Taltavull Jean-François 28 Oct '22

28 Oct '22

Hello, I'm trying to get the 'radosgw.objects.size' metric, that is the total bucket objects size per tenant. I expected to get one sample per tenant but I get one sample per bucket instead, as with the 'rados.containers.objects.size' metric. Here is my pollster definition: ''' - name: "radosgw.objects.size" sample_type: "gauge" unit: "B" value_attribute: ". | value['usage'] | value.get('rgw.main',{'size':0}) | value['size']" url_path: "FQDN/admin/bucket?stats=True" module: "awsauth" authentication_object: "S3Auth" authentication_parameters: my_access_key,my_secret_key,FQDN user_id_attribute: "owner | value.split('$') | value[0]" project_id_attribute: "tenant" resource_id_attribute: "id" ''' I tried with "resource_id_attribute: "tenant" but it does not work better. Any idea ? Is there something wrong in the pollster definition ? Regards, Jean-Francois

2 5

Outreachy Mentorship Programme
by Victor Ekwueme 28 Oct '22

28 Oct '22

Hello, I am a programmer who is visually impaired. I set up devstack on a Digital Ocean droplet on Ubuntu 20.04 Server. It installed successfully. I am trying to make a contribution on 1599140. So my questions are: 1. How do I set up a development environment for this or any other contribution? 2. Do I work directly on the droplet and push from to the repo from there? Any assistance will be of tremendous help. Regards, Victor O. Ekwueme

2 1

[neutron] CI meeting Nov 1st cancelled
by Slawek Kaplonski 28 Oct '22

28 Oct '22

Hi, As we discussed on IRC, Nov 1st is public holiday for me and many other folks who usually attend Neutron CI meeting so meeting next week is cancelled. See You on the CI meeting on Nov 8th. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Help us plan the next PTG!
by Kendall Nelson 28 Oct '22

28 Oct '22

Hello Everyone! Congratulations on a great virtual PTG last week :) The OpenInfra Foundation is hosting the OpenInfra Summit in Vancouver [1], June 13 -15, 2023. We are trying to determine the level of interest among contributors to OpenInfra projects on attending a co-located PTG in Vancouver. *The exact format and dates are still being determined.* At this time, we are evaluating the level of interest from an attendee and employer perspective. Please complete the following poll so we can measure the level of interest and plan accordingly. Future updates will be distributed to the project mailing lists as well as previous PTG attendees. Poll: https://openinfrafoundation.formstack.com/forms/openinfra_ptg_2023 As a reminder, we are also gathering feedback for the virtual PTG here: https://etherpad.opendev.org/p/Oct2022_PTGFeedback -Kendall Nelson (diablo_rojo) [1] https://openinfra.dev/summit/

6 8

network monitor
by Parsa Aminian 28 Oct '22

28 Oct '22

hello Im using openstack kolla-ansible . Could you please tell me how I can monitor instances' network usage ? 1-download and upload speed 2-traffic usage for example send and receive per month for each instance

3 3

[neutron] Neutron drivers meeting Oct 28th
by Rodolfo Alonso Hernandez 27 Oct '22

27 Oct '22

Hello Neutrinos: The drivers meeting will take place tomorrow at 14UTC. The agenda has one single topic: * https://bugs.launchpad.net/neutron/+bug/1994137: [RFE] Specify the precedence of port routes if multiple ports attached to a VM Regards.

1 0

[openstack-ansible][ptg] Antelope PTG results
by Dmitriy Rabotyagov 27 Oct '22

27 Oct '22

Hi everyone! As you might know, the OpenStack-Ansible team had Project Team Gathering on October 18, 2022 and we had quite good discussions. This email is a relatively short sum-up of decisions that were taken during it: * Add Zookepeer cluster deployment as coordination service. Coordination is required if you want to have active/active cinder-volume setup and also actively used by other projects, like Octavia or Designate. Zookeeper will be deployed in a separate set of containers for LXC path * Move out Ubuntu Jammy from experimental state except Ceph integration. This is because community repo does not have ceph packages built for Ubuntu 22.04, so we will switch default to use Ubuntu's native repository to get ceph from. With that you won't be able to pick what ceph version to use, but it will work for most usecases. * Continue supporting Ubuntu Focal (20.04) until Antelope release as upgrade path from Yoga to Antelope should exist and on TC PTG it was decided that it should be tested by projects on Ubuntu 20.04. * Update docs regarding level of support for integrated ceph-ansible deployment with openstack-ansible to address expectations on upgrade path. * Address concerns regarding Glance configuration with COW backends, with regards to OSSN notice: https://wiki.openstack.org/wiki/OSSN/OSSN-0090 * Switch distro path to experimental due to lack of maintainers. We should document that and mention that help is needed to keep it alive. If not - the feature can be removed in the future. * Cover OVN with TLS encryption. Leverage PKI role for that. * We also agreed to switch the default network driver used by OpenStack-Ansible to OVN as default. However, at the moment there is not much hands-on experience on OVN from the core team, so we can not switch default right now as we won't be efficiently helping with OVN deployments. So following switching plan was defined: ** Document reference OVN architecture that we are going to provide ** Document implementation of extra networks that are required for octavia, trove, etc. ** Switch AIO to OVN as default ** Add LXB jobs to neutron role ** Switch default for non-AIO ** Ensure that users who were relying on previous default (and using LXB) have proper override during upgrade. * Improve documentation for the Ironic role with adding a couple of scenarios. * Convert our dynamic inventory to an inventory plugin which will be installed during ansible bootstrap. * Create a repository for the skyline role. We are allowed to take https://github.com/jrosser/openstack-ansible-os_skyline as base and move it under openstack-ansible umbrella * Simplify documentation regarding provider_networks in openstack_user_config and suggest using neutron_provider_networks instead. * Continue working on improving our CI coverage, including returning to molecule testing but rely on the ansible and constraints version from the integrated repo. At the same time finish cleanup of old functional tests, including run_tests.sh, tox, etc. * Deprecate rsyslog_server/client roles as they are hardly used as of today. You can also check etherpad [1] where notes were taken during PTG and that we aim to update with progress on these points implementation: [1] https://etherpad.opendev.org/p/osa-antelope-ptg

1 0

[all][tc] Technical Committee next weekly meeting on 2022 Oct 27 at 1500 UTC
by Ghanshyam Mann 27 Oct '22

27 Oct '22

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2022 Oct 27, at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Oct 26 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[cinder] Problem with restoring purestorage volume backup
by Ришат Азизов 26 Oct '22

26 Oct '22

Hello! We have a problem with cinder-backup with cephbackup driver and volume on purestorage. When backing up purestorage volume with cinder-backup with cephbackup driver it creates in ceph pool and everything is ok. But when we try to restore the backup, it is not restored with an error "rbd.ImageNotFound" in the screenshot attached to this email. This happens because the original image is not in rbd, it is in purestorage. It is not clear why the cinder is trying to look for a disk in the ceph. Could you please help with this? Thanks. Regards.

2 1

[cinder] Bug report from 10-12-2022 to 10-26-2022.
by Sofia Enriquez 26 Oct '22

26 Oct '22

This is a bug report from 10-12-2022 to 10-26-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Undecided - https://bugs.launchpad.net/cinder/+bug/1994018 "The volume multiattach and in-use after retyping another backend, then can not detach it." - https://bugs.launchpad.net/cinder/+bug/1994021 "Cinder cannot work when 1 node of 3 rabbit node cluster down." Low - https://bugs.launchpad.net/cinder/+bug/1993282 "Fail to get pools by volume_type filter key." Assigned to zhaoleilc. No fix proposed to master yet. - https://bugs.launchpad.net/os-brick/+bug/1994083 "FileNotFoundError: [Errno 2] No such file or directory: is raised when dmidecode is not installed." Fix proposed to os-brick master. Wishlist - https://bugs.launchpad.net/cinder/+bug/1994150 "Image signature verification does not verify certificates." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1992493 "Cinder fails to backup/snapshot/clone/extend volumes when the pool is full." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1992685 "Automate generation of snapshot transfer api-ref samples for MV 3.55." Assigned. No fix proposed to master yet. Invalid - https://bugs.launchpad.net/cinder/+bug/1993577 " [JovianDSS] Unable to provide target prefix through iscsi_target_prefix ." Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[neutron] Neutron team meeting cancelled Nov 1st
by Rodolfo Alonso Hernandez 26 Oct '22

26 Oct '22

Hello Neutrinos: The next Neutron team meeting on November 1st is cancelled (All Saints' Day [1]). The next one will take place at the same time on November 8th. Regards. [1]https://en.wikipedia.org/wiki/All_Saints%27_Day

1 0

[manila] Antelope PTG Summary
by Carlos Silva 25 Oct '22

25 Oct '22

Hello, Zorillas and interested stackers. Thank you for the productive PTG we had last week. Here goes the summary for the past week's discussions. In case you would like to see the expanded versions, please refer to [0] or check out the recordings in the Manila YouTube Channel [11]. Different approaches for the images we use in our jobs - Recent changes in the Manila CI (related to the service image) made the jobs take longer to run and become more resource intensive, causing jobs to fail more often due to lack of resources in dsvm - We have been looking for approaches to tackle this issue - In the short term, if a job keeps failing due to such issues, we will split it into two jobs - One to run scenario tests (these tests spawn VMs) - One to run API tests - We agreed that this can get worse in the future with dsvm images that could be even more resource demanding, and that we will look for containerized approaches to try and solve this issue Share backup - (kpdev) The proposed approach for share backup has changed - An existing specification [1] was restored - The idea is to have new APIs for share backup and a new generic Backup driver in a similar way to what Cinder does. - This would allow backends to have their specific implementations for share backups - Reviews for this specification are ongoing Secure RBAC changes - Goutham has shared with the community all the good progress we had in Manila, and also mentioned what we did in Zed, after all the operator's feedback. - Now, we are entering a phase where we want to test a lot! - We have a CI jobs and some test cases covered, but we still want to have more coverage - During Antelope, we will promote a hackathon in order to accelerate the functional tests coverage Outreachy Internships - On this topic, ashrodri, fmount, gouthamr and carloss shared the two proposed Outreachy project that are Manila related - ashrodri and fmount are proposing a project to have an intern creating a multi-node test environment with Devstack and Ceph [2], as these tests are becoming more resource demanding - carloss and gouthamr are proposing a project for an intern to work in Manila UI [3]. The idea is to close down the gap of features between Manila UI and the Manila API. OpenStackSDK Manila Status - This has been an effort for some time, and during the Zed cycle some code was merged for integrating share groups and share group snapshots. - This is a good candidate project for an internship, and the idea is that we will be able to get some interns working on this project (potentially a project for a college capstone project) OSC Updates - Zed was the release we targeted to reach feature parity with the native client, and we made it! - We had an idea to add a deprecation warning to the native manila client, but that will need to wait - There is still a missing bit for adding the deprecation warning: having version autonegotiation working, which is something we are targeting for Antelope - OSC is now the primary focus of the project when doing implementations for CLIs. Bandit Testing / VMT - The Manila team was introduced to the VMT (vulnerability management team) and Bandit, and we had contributors sharing their ideas around having manila under the VMT and running bandit tests. - VMT - The audience agreed with the conditions to be under the overseen repos. - Goutham has volunteered to be the security liaison for Manila - Bandit - There were some errors pointed out in a preliminar test run [4]. - We will add a bandit non-voting job and file bugs against third party drivers that have issues pointed out by the new job - New bugs will be filed and will be distributed across community members All Things CephFS - Ingress aware NFS Ganesha - Ceph Orchestrator is now capable of creating an ingress service to front-end a cluster of active-active NFS Ganesha instances via a single load-balanced IP address - Previously, we would only use one single instance of NFS Ganesha. This introduces a SPOF and is not suitable for production environments without HA being handled externally (like TripleO deployments do). With this change, Manila CephFS NFS users would be able to deploy multiple NFS Ganesha servers and leverage inbuilt HA capabilities - Currently though manila client restrictions (access rules) will not work since NFS-Ganesha sees the ingress service's IP instead of the client's IP address. - ffilz proposed his design to support the PROXY protocol with NFS-Ganesha. Ceph Ingress can pass the Client's IP address to NFS-Ganesha [5] - An alternative would be to have cephadm assign stable IP addresses to ganesha instances - No driver changes are anticipated in either approach - AI: Investigating deploying ceph-ingress with devstack - Migration tool for Manila with CephFS NFS - After the new helper was introduced to the driver, we are able to interact with cephadm-deployed CephNFS service (which comes with a lot of benefits) - Now, we need to figure out how to upgrade deployments with CephFS NFS using the current helper (which interacts with NFS Ganesha through DBUS) - There are two main issues: - Representing a change in exports when migrating across NFS Servers (current use case) or when decommissioning NFS Servers - Representing exports from multiple servers - a special case enabling migration where an old server will eventually be decommissioned: - These issues were talked through and possible solutions were proposed and will be worked on in the following cycles. More details on [6] - DHSS=True for CephFS driver - Currently, CephFS driver, whether you'd like to use it for Native CephFS, NFS via DBUS, NFS via ceph-mgr only supports DHSS=False. The request of this feature was raised during the OpenInfra Summit in Berlin from several Manila users. - We discussed some alternatives for making it happen: - 1) Operator determines Ceph cluster limits, and creates isolated file systems and declares multiple manila backends with each filesystem - 2) Subvolume groups - pinning a subvolume group to mds can isolate/dedicate mds load - CephFS CI issues - The lack of resources in the dsvms is affecting the CephFS Native and NFS jobs, causing them to be unstable. The jobs often run into timeouts - The situation could get worse as Jammy Jellyfish packages are not available yet - We will ask the ceph-users if jammy release bits can be made available Oversubscription enhancements - Storage pools supporting thin provisioning are open to oversubscription. This caused some problems mentioned in [7]. - We have an open specification which we intend to merge in the Antelope cycle, as well as the changes to address such issue FIPS - We have shared our testing status with regards to FIPS. We have jobs merged on stable branches up to wallaby for both manila and python-manilaclient repositories. - The next steps would be a more in-depth code audit to identify non-compliant libraries and making our jobs voting - We agreed to make our jobs voting when the Ubuntu images supporting FIPS are out - For drivers using non FIPS compliant libraries, we will notify the maintainers Metadata API update - Metadata APIs for share snapshots were added during the Zed cycle - The goal for this cycle is to have functional testing and the CLI merged. Both patches are under review and expected to be merged not late in the release. Manila CSI - The CSI plugin's been pretty stable in the last six months [8] - There was a good talk presented at KubeCon by Robert Vasek [9] - The next steps include getting a fix for an issue involving long snapshot names in the CephFS backend and supporting volume expansion in the OpenShift Manila CSI driver operator Manila Configuration of VLAN Network information - A issue was found where Contrail Neutron Plugin did not return the VLAN ID during port allocation [10] - To tackle this issue, we have agreed to add metadata to the share network APIs so the administrators would be able to add VLAN as metadata and drivers would be able to consume it. *Better use of bug statuses* - Our bugs were stuck in "New" instead of "Confirmed" or "Triaged" and this could be misleading. - We agreed to tag the bugs as confirmed or triaged depending on the outcome of our triaging and not leave bugs as "new" - We will ask the bug assignees to update their open bugs in case one of them has the new status, so we can have a better visibility [0] https://etherpad.opendev.org/p/antelope-ptg-manila [1] https://review.opendev.org/c/openstack/manila-specs/+/330306 [2] https://www.outreachy.org/outreachy-december-2022-internship-round/communit… [3] https://www.outreachy.org/outreachy-december-2022-internship-round/communit… [4] https://gist.github.com/gouthampacha/c0d96966670956761b2b620be730efe2 [5] https://docs.google.com/document/d/1orjNjtEeeyRrgvbQuFU5BdsCnZG9gF3MymDCZl-… [6] https://etherpad.opendev.org/p/antelope-ptg-manila-cephfs [7] https://etherpad.opendev.org/p/manila_oversubscription_enhancements [8] https://github.com/kubernetes/cloud-provider-openstack/commits/master/pkg/c… [9] https://www.youtube.com/watch?v=XfpP9pBTXfY&t=1145s [10] https://bugs.launchpad.net/charm-manila/+bug/1987315 [11] https://www.youtube.com/playlist?list=PLnpzT0InFrqBzbSP6lcYDStKpbEl3GNHK Thanks, carloss

1 0