August 2021 - openstack-discuss - lists.openstack.org

[Nova][interop]
by Arkady Kanevsky 20 Oct '21

20 Oct '21

Sean and Nova team, Interop WG would like 20-30 minutes on Yaga PTG agenda to discuss latest interop guidelines for Nova. If you can point us to etherpad then we can add it to agenda. Thanks, Arkady -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456

3 6

[all][tc] Yoga TC-PTG Planning
by Ghanshyam Mann 20 Oct '21

20 Oct '21

Hello Everyone, As you already know that the Yoga cycle virtual PTG will be held between 18th - 22nd October[1]. To plan the Technical Committee PTG sessions, please do the following: 1. Fill the below doodle poll as per your availability. Please fill it soon as deadline to book the slot is 21th July. - https://doodle.com/poll/6dfdmdfi4s8wc7cd 2. Add the topics you would like to discuss to the below etherpad. - https://etherpad.opendev.org/p/tc-yoga-ptg NOTE: this is not limited to TC members only; I would like all community members to fill the doodle poll and, add the topics you would like or want TC members to discuss in PTG. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023540.html -gmann

1 2

[tacker] Yoga vPTG planning
by yasufum 15 Oct '21

15 Oct '21

Hi everyone, The next vPTG will be held on 18-22 October as I shared at the previous IRC meeting [1]. Registration has already opened [2]. We've decided to have the next vPTG session on the same timeslots, 6-8 UTC, as previous for most of us join from India and APAC regions. I've prepared etherpad for the next vPTG [3]. If you have any suggestion, please add your topic on it. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023540.html [2] https://openinfra-ptg.eventbrite.com/ [3] https://etherpad.opendev.org/p/tacker-yoga-ptg Thanks, Yasufumi

2 1

[dev][cinder] Consultation about new cinder-backup features
by Daniel de Oliveira Pereira 14 Oct '21

14 Oct '21

Hello everyone, We have prototyped some new features on Cinder for our clients, and we think that they are nice features and good candidates to be part of upstream Cinder, so we would like to get feedback from OpenStack community about these features and if you would be willing to accept them in upstream OpenStack. Our team implemented the following features for cinder-backup service: 1. A multi-backend backup driver, that allow OpenStack users to choose, via API/CLI/Horizon, which backup driver (Ceph or NFS, in our prototype) will be used during a backup operation to create a new volume backup. 2. An improved NFS backup driver, that allow OpenStack users to back up their volumes to private NFS servers, providing the NFS hostpath at runtime via API/CLI/Horizon, while creating the volume backup. Considering that cinder was configured to use the multi-backend backup driver, this is how it works: During a volume backup operation, the user provides a "location" parameter to indicate which backend will be used, and the backup hostpath, if applicable (for NFS driver), to create the volume backup. For instance: - Creating a backup using Ceph backend: $ openstack volume backup create --name <backup_name> --location ceph <volume_id> - Creating a backup using the improved NFS backend: $ openstack volume backup create --name <backup_name> --location nfs://my.nfs.server:/backups <volume_id> If the user chooses Ceph backend, the Ceph driver will be used to create the backup. If the user chooses the NFS backend, the improved NFS driver, previously mentioned, will be used to create the backup. The backup location, if provided, is stored on Cinder database, and can be seen fetching the backup details: $ openstack volume backup show <backup_name> Briefly, this is how the features were implemented: - Cinder API was updated to add an optional location parameter to "create backup" method. Horizon, and OpenStack and Cinder CLIs were updated accordingly, to handle the new parameter. - Cinder backup controller was updated to handle the backup location parameter, and a validator for the parameter was implemented using the oslo config library. - Cinder backup object model was updated to add a nullable location property, so that the backup location could be stored on cinder database. - a new backup driver base class, that extends BackupDriver and accepts a backup context object, was implemented to handle the backup configuration provided at runtime by the user. This new backup base class requires that the concrete drivers implement a method to validate the backup context (similar to BackupDriver.check_for_setup_error) - the 2 new backup drivers, previously mentioned, were implemented using these new backup base class. - in BackupManager class, the "service" attribute, that on upstream OpenStack holds the backup driver class name, was re-implemented as a factory function that accepts a backup context object and return an instance of a backup driver, according to the backup driver configured on cinder.conf file and the backup context provided at runtime by the user. - All the backup operations continue working as usual. Could you please let us know your thoughts about these features and if you would be open to adding them to upstream Cinder? If yes, we would be willing to submit the specs and work on the upstream implementation, if they are approved. Regards, Daniel Pereira

5 6

[kuryr] Virtual PTG October 2021
by Maysa De Macedo Souza 12 Oct '21

12 Oct '21

Hello, I booked the following slots for Kuryr during the Yoga PTG: Oct 19 7-8 UTC and Oct 22 13-14 UTC. If you have any topic ideas you would like to discuss, please include them in the etherpad[1], also it would be interesting to include your name there if you plan to attend any Kuryr session. See you on the next PTG. Cheers, Maysa. [1] https://etherpad.opendev.org/p/kuryr-yoga-ptg

1 2

[Swift][Interop] PTG time
by Arkady Kanevsky 06 Oct '21

06 Oct '21

Swift team, Interop team would like time on Yoga PTG Monday or Tu between 21-22 UTC to discuss Interop guideline coverage for Swift. Thanks, Arkady -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456

3 5

Help with eventlet 0.26.1 and dnspython >= 2
by Thomas Goirand 04 Oct '21

04 Oct '21

Hi, As you may know, eventlet is incompatible with dnspython >= 2.0.0.0rc1. See [1] for the details. However, Debian unstable has 2.0.0. Would there be some good soul willing to help me fix this situation? I would need a patch to fix this, but I'm really not sure how to start. Cheers, Thomas Goirand (zigo)

8 15

[neutron][ovn] support for stateless NAT for floating ip in ml2 ovn
by Moshe Levi 26 Sep '21

26 Sep '21

Hi all, OVN support stateless NAT operations [1] for use case of 1:1 mapped between inner and external ips, i.e dnat_and_snat rule. In openstack is the floating ip use-case. Looking on ml2 ovn support it seem that it only support floating ip with connection tracking. Can ml2 ovn support also the stateless NAT option? Is there concerns using stateless NAT? [1] - https://patchwork.ozlabs.org/project/openvswitch/cover/1570154179-14525-1-g…

3 8

[ironic] Yoga PTG
by Iury Gregory 23 Sep '21

23 Sep '21

Hello Ironicers! We are approaching the time of the next PTG (it's in October but we need to make some decisions). Our yoga etherpad is available[1], feel free to add any topics we shall discuss. In the ethercalc[2] you can find the slots we already booked, we may add more slots for APAC if someone is willing to run the meeting and discussions. Don't forget to register! [3]. [1] https://etherpad.opendev.org/p/ironic-yoga-ptg [2] https://ethercalc.openstack.org/8tum5yl1bx43 [3] https://openinfra-ptg.eventbrite.com -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 1

Edge for scientific research session on September 13 Edge WG meeting
by Ildiko Vancsa 18 Sep '21

18 Sep '21

Hi, I’m very excited to invite you to a session with the Chameleon project to discuss how edge computing is powering education, scientific research and more! As always in the area of edge there are challenges and gaps that we need to solve together. In that sense the session will start with a presentation that we will then turn into a discussion to turn towards discussing solutions. Please also note that the Chameleon project is using OpenStack to build edge solutions. As they identified some gaps they would like to work with the community to address the challenges that they’ve been hitting. Please join us to get their feedback and find the best way to improve OpenStack to deliver a platform that can be used on the edge! The session will take place on the OpenInfra Edge Computing Group weekly call on __September 13, at 1300 UTC / 6am Pacific__. For the latest dial-in information please refer to this page: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings Please find the details of the session below. Thanks and Best Regards, Ildikó Title: Chameleon: a cloud to edge infrastructure for science Abstract: The NSF-funded Chameleon project (www.chameleoncloud.org) provides an OpenStack-based bare metal reconfigurable cloud that supports systems research, education, and emergent application projects in science. The facility has been in existence for 6+ years, and has served ~6,000 users working on a variety of projects ranging from networking, operating systems design, and security, to innovative applications in astronomy, physics, and life sciences. Recent research trends in IoT and edge computing, as evidenced by increased numbers of project applications in those areas, made it clear that Chameleon needed to expand into the edge space. Remaining within the OpenStack framework allowed us to leverage end-user features that we developed for Chameleon, such as access via federated identity and Jupyter integration. Accordingly, we developed infrastructure called CHI@Edge that adapts Zun to provision containers on edge devices and significantly expands its capabilities to work in the edge space. The talk will describe our use case and the emergent product definition, the OpenStack adaptations we made to the current preview implementation, the directions we plan to take in our further work, as well as the ecosystem of projects and NSF infrastructure deployments leveraging this work and collaborating with us.

3 9