April 2022 - openstack-discuss - lists.openstack.org

[TripleO] please stop posting patches for tripleo* stable/ussuri (going EOL)
by Marios Andreou 12 Apr '22

12 Apr '22

Hello TripleO As proposed at [1] and also discussed in yesterday's TripleO Z PTG meet [2] we are going to move stable/ussuri for all tripleo repos to EOL. In order to move ahead we need to have no open patches against stable/ussuri. ** please stop posting patches to stable/ussuri tripleo repos ** If you have open patches can you please either get them merged, or abandon them by next Tuesday 12th. After this we will have to abandon any open patches (e.g. folks moved on/not even looking there) and then I can update the EOL proposal at [3] with the latest commit hashes so we can proceed. For reference the repos with open reviews at time of writing are at [4] below. Please speak up if you need more time or with any other comments regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028025.ht… [2] https://etherpad.opendev.org/p/tripleo-zed-ci-load [3] https://review.opendev.org/c/openstack/releases/+/834049 [4] ( list of repos with open reviews for stable/ussuri): * https://review.opendev.org/q/project:openstack%252Fos-net-config+status:ope… * https://review.opendev.org/q/project:openstack%252Fpaunch+status:open+branc… * https://review.opendev.org/q/project:openstack%252Fpuppet-tripleo+status:op… * https://review.opendev.org/q/project:openstack%252Fpython-tripleoclient+sta… * https://review.opendev.org/q/project:openstack%252Ftripleo-ansible+status:o… * https://review.opendev.org/q/project:openstack%252Ftripleo-common+status:op… * https://review.opendev.org/q/project:openstack%252Ftripleo-heat-templates+s… * https://review.opendev.org/q/project:openstack%252Ftripleo-puppet-elements+… * https://review.opendev.org/q/project:openstack%252Ftripleo-validations+stat…

1 1

[Kolla-ansible][Xena] Test Trove module
by wodel youchi 12 Apr '22

12 Apr '22

Hi, I am testing the deployment of Xena, and part of my testing is to test the different modules. I am trying to test the Trove module and for now there is no dev image for Xena here : https://tarballs.opendev.org/openstack/trove/images/ So I decided to build the image, my base system is Rocky Linux, I followed the documentation here : https://docs.openstack.org/trove/latest/admin/building_guest_images.html#bu… But when executing the build command [deployer@rscdeployer scripts]$ ./trovestack build-image ubuntu bionic true ubuntu $HOME/images/trove-guest-ubuntu-bionic-dev.qcow2 ******************************************************************************* Params for cmd_build_image function: ubuntu bionic true ubuntu /home/deployer/images/trove-guest-ubuntu-bionic-dev.qcow2 ******************************************************************************* *Ensuring we have all packages needed to build image.sudo: apt-get: command not found* *I got this : sudo: apt-get: command not found * Do I have to build the image on an ubuntu system? I thought that it is similar to building the octavia image, that it is not tied to the Linux distro you are using. Regards. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 5

(Ansible Galaxy) Assign static ip to build a sever
by borges.ds＠gmail.com 12 Apr '22

12 Apr '22

Hi folks, I am using the server module to build/decomm virtual machines. However I am only able to build VMs using dynamic IP assignment.. Whenever I try to assign a static using float ips, the instruction is ignored. Could you help me to figure this out? The collection documentation is not clear about that... -- Aguardo sua resposta, David Borges de Sousa (3374-9157 / 87846638)

1 0

Resize instance vm Linux error
by Joao Oliveira 12 Apr '22

12 Apr '22

How I can Resize a Instance in the dashboard ?? [cid:image004.png@01D84B6B.A5B5F960] I try this and it is not working. Any sugestions ?? Thanks João de Deus Oliveira Ingeniero de Infraestructura [Descripción: Descripción: Descripción: Logo ITC Servicios] Informática, Tecnología & Comunicaciones Edificio ITC Tower Av. Las Ramblas #100, Torre B Barrio Equipetrol Norte Santa Cruz - Bolivia Tel: +(591) 3 344-4424 Ext. 4368 Fax: +(591) 3-344-4433 Móvil: +(591) 67011038 E-mail: joliveira(a)itcservicios.com<mailto:joliveira@itcservicios.com> Web: www.itc-e.com<http://www.itc-e.com/> AVISO DE CONFIDENCIALIDAD Y PRIVACIDAD: El uso de la información transmitida en este correo electrónico está limitado a la persona a la cual va dirigido. El correo puede contener información privada, privilegiada, confidencial o exenta de revelación bajo las leyes aplicables. Si usted no es el destinatario pretendido o sospecha que el mensaje le hubiera sido enviado sin la debida autorización, queda avisado que está estrictamente prohibido cualquier uso, diseminación o copia de esta información. Si usted ha recibido este mensaje por equivocación le pedimos notificarnos a vuelta de correo y borrar el mensaje. CONFIDENTIALITY AND PRIVACY NOTICE: This email is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us via reply email and delete this message. De: Abhishek Kekane <akekane(a)redhat.com> Enviado el: jueves, 7 de abril de 2022 14:33 Para: Anurag Singh Rajawat <anuragsinghrajawat22(a)gmail.com> CC: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Asunto: Re: [glance] Outreachy 2022 Hi Anurag, Sorry that we were not able to address you on IRC. Currently glance team is busy in PTG which will end tomorrow evening and that is why we might have missed your ping on IRC. I would suggest to share your failures so that we can guide you. I think from Monday onwards everyone will be back to their daily routine so outreachy glance team will help you to resolve your queries. Meanwhile if it is urgent then you can share your doubts and I will try my best to resolve them. Thanks and Regards, Abhishek On Thu, 7 Apr, 2022, 22:30 Anurag Singh Rajawat, <anuragsinghrajawat22(a)gmail.com<mailto:anuragsinghrajawat22@gmail.com>> wrote: Dear glance team, I'd setup glance, glance-store and glance-client on my local setup, but some tests for glance were failing, also is there any good first issues so that I can understand the project more clearly? I also asked about it in IRC but doesn't got response. Thanks Sincerely Anurag

2 2

[qa][ptg] PTG Summary
by Martin Kopec 12 Apr '22

12 Apr '22

Hello everyone, thank you to all who participated in the PTG discussions and shared their thoughts and opinions. It's very much appreciated! Here is the summary of the discussions [1]: * Yoga Retrospective ** more details in [1] * Secure RBAC ** Devstack - mostly done, it has already options to enable enforce scope ** Tempest - tests will need to be migrated *** will be started after Keystone and Nova are migrated * FIPS current status and next plans ** Tempest will use ecdsa keys by default (instead of rsa) ** QA team will help reviewing related patches *** https://etherpad.opendev.org/p/qa-zed-ptg-fips * Tempest tests in mixed-architecture environments ** there is no support in Zuul for a testing like this ** still in a brainstorming phase looking for a potential solution, if you have any ideas, feel free to reach out * Direction on replacing the scenario manager ** in progress, the plan is to finish it (merge related patches) sooner in the cycle * Retirement of QA projects ** openstack-health ** tempest-lib ** os-testr *** ostestr command was removed from os-testr repo * Future of Centos Stream support ** we'd like to create at least an experimental job on Rocky linux ** during the Zed cycle we would like to deprecated Centos 8 Stream and influence projects to start using Centos 9 Stream jobs The discussed topics are transformed into priority items [2] we will be focusing on this cycle. [1] https://etherpad.opendev.org/p/qa-zed-ptg [2] https://etherpad.opendev.org/p/qa-zed-priority Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 0

[openstack-ansible][PTG] Zed PTG results
by Dmitriy Rabotyagov 12 Apr '22

12 Apr '22

Hi everyone! Thanks everybody for taking time and attending a session. Despite we didn't have much topics in our agenda, I believe it we had great discussion about further steps in project development. We have defined topics that we aim to implement before releasing Yoga: * Move os_octavia role to use PKI role * Implement keystone RBAC support and switch services role to `service`. Be ready for final migration in Zed. * Start implementing support for encrypting connection between haproxy and it's backends * We will also try to get Ubuntu 22.04 support before release, despite in general we add Ubuntu LTS support in autumn. Following plans regarding Zed release were set: * Add unit testing of collections and common roles, with molecule. At same time we should use dependencies from integrated repo for that. * We will support concept of Tick/Tock releases and add testing for jumping through releases. * Implement shared queues for our jobs and see effect from that * Fix repo server to _really_ support multiple distros in the same environment * We should revise in AA PTL if we should keep support for non-SSL deployments, and keep upgrade path in Zed. There was an agreement to EOL Pike and Queens releases in nearest future. We also move Victoria to EM soon. With lack of contributions/interest regarding some of features we are reaching to community and interested parties to help out with support of: * Installation path from distro packages * Support of CentOS distributions If you're interested in continuation of being these part of OSA, please reach us out via ML or IRC to get more information about how you can help out. -- Kind regards, Dmitriy Rabotyagov

1 0

[all] New CFN(Computing Force Network) SIG Proposal
by niujie 12 Apr '22

12 Apr '22

Hi all I'm from China Mobile, China Mobile is recently working on build a new information infrastructure focusing on connectivity, computing power, and capabilities, this new information infrastructure is called Computing Force Network, we think OpenStack community which gathers global wisdom together is a perfect platform to discuss topics like CFN, so we are proposing to create a new SIG for CFN(Computing Force Network). Below is CFN brief introduction and initial SIG scope. With the flourish of new business scenarios such as hybrid cloud, multi-cloud, AI, big data processing, edge computing, building a new information infrastructure based on multiple key technologies that converged cloud and network, will better support global digital transformation. This new infrastructure is not only relates to cloud, it is getting more and more connected with network, and at the same time, we also need to consider how to converge multiple technologies like AI, Blockchain, big data, security to provide this all-in-one service. Computing Force Network(CFN) is a new information infrastructure that based on network, focused on computing, deeply converged Artificial intelligence, Block chain, Cloud, Data, Network, Edge computing, End application, Security(ABCDNETS), providing all-in-one services. Xiaodong Duan, Vice president of China Mobile Research Institute, introduced the vision and architecture of Computing Force Network in 2021 November OpenInfra Live Keynotes by his presentation Connection + Computing + Capability Opens a New Era of Digital Infrastructure, he proposed the new era of CFN. We are expecting to work with OpenStack on how to build this new information infrastructure, and how to promote the development and implementation of next generation infrastructure, achieve ubiquitous computing force, computing & network convergence, intelligence orchestration, all-in-one service. Then computing force will become common utilities like water and electric step by step, computing force will be ready for access upon use and connected by single entry point. The above vision of CFN , from technical perspective, will mainly focus on unified management and orchestration of computing + network integrated system, computing and network deeply converged in architecture, form and protocols aspect, bringing potential changes to OpenStack components. CFN is aiming to achieve seamlessly migration of any application between any heterogeneous platforms, it's a challenge for the industry currently, we feel that in pursuit of CFN could potentially contributes to the development and evolution of OpenStack. In this CFN SIG, we will mainly focus on discussing how to build the new information infrastructure of CFN, related key technologies, and what's the impact on OpenStack brought by the network & could convergence trend , the topics are including but not limited to: 1, A computing basement for unified management of container, VM and Bare Metal 2, Computing infrastructure which eliminated the difference between heterogeneous hardware 3, Measurement criteria and scheduling scheme based on unified computing infrastructure 4, Network solutions for SDN integrating smart NIC for data center 5, Unified orchestration & management for "network + cloud", and "cloud + edge + end" integrated scheduling solution We will have regular meetings to investigate and discuss business scenarios, development trend, technical scheme, release technical documents, technical proposal and requirements for OpenStack Projects, and propose new project when necessary. We will also collaborate with other open source projects like LFN, CNCF, LFE, to have a consistent plan across communities, and align with global standardization organization like ETSI, 3GPP, IETF, to promote CFN related technical scheme become the standard in industry. If you have any thoughts, interests, questions, requirements, we can discuss by this mailing list. Any suggestions are welcomed, and we are really hoping to hear from anyone, and work with you. Jie Niu China Mobile

1 0

[Kolla-ansible][Xena] How to undeploy (remove) a service
by wodel youchi 12 Apr '22

12 Apr '22

Hi, How can I remove a deployed service with kolla-ansible? Regards. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 1

[nova][placement] Zed PTG summary
by Sylvain Bauza 12 Apr '22

12 Apr '22

Yet again, let me try to provide you a summary about our previous PTG, this time for the Zed release. You can see all the notes thanks to this read-only etherpad : https://etherpad.opendev.org/p/r.75a986ce3ac43bb74b93c5de63d84fe9 ### Cross-project discussions ### # Neutron cross-project discussion with Nova - The nova community asked how to require Neutron backends to support a list of Neutron API extensions (for example multiple port bindings). We discussed whether it was rather a documentation issue or a code issue, but eventually it was rather a supporting concern as we don't test all of the backends for Nova. We then agreed on discussing this during the next OpenInfra Summit in Berlin with operators then, if possible. - We agreed on providing a new job for verifying whether heal_instance_info_cache_interval is no longer needed. # Cinder cross-project discussion with Nova - We discussed how we could remove the os-brick rootwrap config from nova and rather moving the config into directly os-brick. We eventually agreed on trying to rather implement the rootwrap->privsep transition, hopefully, thanks to some Stephen's help ;) # Cyborg cross-project discussion with Nova - We agreed on continuing to accept to provide traits for Resource Providers for owners (OWNER_NOVA at least). Context is https://review.opendev.org/c/openstack/nova-specs/+/836583 and we discussed about some implementation nits. ### Nova specific topics ### # Procedural discussions - We discussed on Yoga retrospective. We were happy to not have a RC2, to have new contributors and to have provided features to Placement for the last two cycles. We agreed to stopping to accept blind rechecks and to use the review priority label. Eventually we agreed on maybe adding new stable cores. - We need to fix Placement tests that verify the number of traits as for the moment it creates some issues. We agreed on relaxing those tests and to add a PTL doc saying we would bump os-traits and os-resource-classes usage in placement before RC1. - We agreed on having the same deadlines that for the last cycle, which are, Spec approval freeze for Zed-2 milestone (July 14th), and FeatureFreeze for Zed-3 (Sep 1st). We will have two spec review days - We agreed on keeping the same release model for os-vif - We agreed on continuing to use the review priority label in Gerrit and encourage contributors to use it (once we land the necessary changes in Gerrit) - Follow-up discussion on the novaclient CLI deprecation we agreed on Yoga. We'll modify the spec template to ask for rather updating OSC instead of the shell, and how to return some warnings if you use the shell. - We agreed on having some bug triage rotation between our contributors. I'll explain it in our next team meeting today :-) - We agreed on saying 'Unsupported' instead of 'Deprecated" for some features that need help if we don't want to remove them :-) - Again, we loudly said ***NO FOR BLIND RECHECKS*** https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-te… # New Release cadence (ie. the tick-tock release balance) - We agreed on writing some guidelines in our Nova documentation explaining the differences between tick and tock releases from a nova perspective and what people could do. We agreed on *not* bumping the compute minimum supported version in a tick release. That would also be super cool if we could have some sphinx directive in reno that contributors would use if they add/modify things in a tock release but want operators to know in the next tick. # Planned API modifications - We agreed on testing new policy defaults in the gate and not yet enforce new scopes until we are sure everything works correctly. Devstack will need modifications for those enablements and proper communication has to be made to deployment projects to make sure they're on the same page before we change anything. - We agreed on deprecating the possibility to generate new keypairs thru the Nova API. Only keypair imports will be accepted in the future. - We agreed on some usecase for adding network domain name in our metadata API. Things have to be further discussed in a spec but the direction sounds reasonable. - We agreed on letting userdata be editables. Details were discussed about the limits of this new mutable field (configdrive et when to apply) but spec will be updated accordingly. - Being able to unshelve an instance by passing a destination seems a valid usecase, spec has to be reviewed besides the implementation. - We'll try to somehow ensure that renaming tenant_id into project_id in our API isn't yet again deferred to the next cycle, even tho the series is large and merge conflicts are important. - Manila shares could be attached or detached to instances thru a new API and notifications would be emitted # Other - Centos9 will be tested on a weekly basis in our gate at first - Nova healthcheck is definitely a thing we want, but we miss hands on deck. - having PCI devices being tracked in Placement is also something we'd love to see arriving on this cycle - we'll continue further testing emulated hardware. Maybe some blueprints would come up but we also said we'll try to give visibility on the periodic gate runs by looking at them in our weekly meeting. - We discussed a very interesting case with the Scaphandre project that needs to use virtio-fs for passing system usage to the guests. We eventually agreed on two possible directions, with one preferred, which is to reuse the Manila shares support we're going to add in Zed. - We can be smarter on placing guest CPUs on physical cores or dies, but this requires a blueprint at least as we agreed on providing some flavor extraspec or image property for letting operators to define the CPU placement. - Windows guests would benefit from new enlightenments in Zed if we merge some small change - Having CPU cores be externally managed by a daemon that would turn them on/off based on consumption seems a valid usecase. We discussed about some details but spec has to be reproposed. That's it. If you reached this line, kudos, you're brave. I tried to be short, but it looks to me I failed. Anyway, the source of truth remains the etherpad, just please avoid to amend it now. -Sylvain

1 0

[openstack-helm] No meeting this week
by Gage Hugo 12 Apr '22

12 Apr '22

Hey team, Since there is nothing on the agenda the meeting for this week is cancelled. We will meet next week at the usual time.

1 0