October 2021 - openstack-discuss - lists.openstack.org

[OpenStack-Ansible] LXC containers apt upgrade
by Taltavull Jean-Francois 29 Oct '21

29 Oct '21

Hi All, Following the recent Let's Encrypt certificates expiration, I was wondering what was the best policy to apt upgrade the operating system used by LXC containers running on controller nodes. Has anyone ever defined such a policy ? Is there an OSA tool to do this ? Regards, Jean-François

2 2

[masakari] Yoga PTG summary
by Radosław Piliszek 29 Oct '21

29 Oct '21

Hi! This is a quick summary of Masakari's Yoga PTG. Quick as the PTG itself was quite quick. :-) We have summarised the progress made in Xena and decided to continue the efforts related to supporting monitoring with Consul and tracking issued evacuations. We have also discussed one new topic regarding circuit breaking in case of a mass failure of instances (e.g., due to a storage network failing in one location). To this end, the proposal is to introduce a protection mechanism (circuit breaking) based on a static time window (static at least in the first iteration) per segment. suzhengwei is to write the spec for this. Raw notes are available at https://etherpad.opendev.org/p/masakari-yoga-ptg Kind regards, -yoctozepto

1 0

[sahara][ptg] Yoga PTG Summary
by Juntingqiu Qiujunting (邱军婷) 29 Oct '21

29 Oct '21

Hi all: Thank everyone for taking time and attending session. The discussion content of the PTG meeting is as follows: https://etherpad.opendev.org/p/sahara-yoga-ptg 1、Sahara has supported boot virtual machine from volume. https://specs.openstack.org/openstack/sahara-specs/specs/backlog/boot-from-… 2、Sahara deploys a dedicated clusters need the network to be a flat one for instances. Could set up a "jumphost" which can be reached by the controllers, and that can reach the instances, need not the network to be a flat one for instance. https://docs.openstack.org/sahara/latest/admin/advanced-configuration-guide… 3、Discuss about which Plugins should be kept and updated and which ones should be dropped? The conclusion is that such as HDP、CDH、MapR Storm and Spark can be deleted in Yoga. 4、Improve the unit testing and documentation of Sahara project. Currently, the activity of the Sahara project is relatively low. We can discover its potential and expand its usage scenarios. Thank you Fossen --------------------------------- Fossen Qiu | 邱军婷 CBRD | 云计算与大数据研发部 T: 18249256272 E: qiujunting(a)inspur.com<mailto:qiujunting@inspur.com> 浪潮云海

1 0

[ptg][cinder] yoga virtual PTG summary
by Brian Rosmaita 28 Oct '21

28 Oct '21

Sorry for the delay, it's posted here: https://wiki.openstack.org/wiki/CinderYogaPTGSummary The wiki page contains links to all the recordings. It's a wiki page, so feel free to make clarifications or corrections. Action items are noted in the "conclusions" sections of most of the summaries, so please look to remind yourself what you have committed yourself to. cheers, brian

1 0

Problems with Openstack internal:external router
by Jibsan Joel Rosa Toirac 28 Oct '21

28 Oct '21

Hello I finished to set up a brand new Openstack server, I had already other up and running without any problems, yet on mine the router wich allows the external connection has all the interfaces down and I don't know what else to do. I've tried everything but it still not working. Please any help with this? I let you here a couple of screenshots of my network topology

1 0

[manila] FIPS compliance (Notice: third party drivers)
by Carlos Silva 28 Oct '21

28 Oct '21

Hello Zorillas and interested stackers! During the PTG week, we had a session where we discussed FIPS compatibility and compliance. In this PTG recording [1] you can see the discussion around this topic and our motivations to achieve such things for Manila. We're writing to follow up on the PTG discussion we had, and to update you on our move towards FIPS compatibility and compliance. We're aiming for manila FIPS compatibility with the Yoga cycle, meaning our CI jobs should be passing. FIPS compliance is a Z(orilla) cycle goal. For third party maintainers, to test if your code is FIPS compatible, use an image with fips enabled as discussed in [3]. In the etherpad we used in our previous discussion [2], there's a mention for some drivers that are using non-FIPS compliant libraries, and some examples of libraries that shouldn't be used. If FIPS is enabled in the controller where the driver is, and the driver is using one of the non permitted libraries, it will possibly lead the driver to malfunctioning. If you have any questions, please feel free to reach out to us (carloss and ashrod98) in #openstack-manila. We're always here to support our community. [1] https://youtu.be/mlTx71GIp1w?t=4864 [2] https://etherpad.opendev.org/p/yoga-manila-FIPS [3] https://etherpad.opendev.org/p/state-of-fips-in-openstack-ci-yoga Thanks! ---- Carlos da Silva (carloss) Ashley Rodriguez (ashrod98)

1 0

[kolla] Yoga PTG summary
by Michał Nasiadka 28 Oct '21

28 Oct '21

Hi everyone, Thank you all who participated in the PTG discussions and shared their thoughts and opinions. Here is the summary of the topics we have discussed: # General ## We agreed to stop using Launchpad’s Blueprints functionality (which was inconsistently used by us). ## We’ve discussed recently proposed services to Kolla: Adjutant has a complicated status now (vacant PTL seat and looking for contributors) Skyline Venus We agreed that a project can be added to Kolla/Kolla-Ansible once it fulfills following the criteria of being in OpenStack governance for 1 cycle and having 1 release. An exception to this criteria is when the patch content is in good quality and there are core reviewers interested in making this functionality merged (but still the project needs to be in OpenStack governance). ## We also discussed adding OSISM collection of Grafana dashboards and Prometheus Alertmgr rules in order to improve the “default deployment” experience for Kolla-Ansible users. ## There was a decision taken to finally retire kolla-cli (since it has been deprecated long time ago). # Kolla ## We have discussed deprecating and dropping of binary type of Kolla images: Pros: * less CI load, less maintenance burden (for a limited Kolla team), users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images CI jobs as voting) Cons: * User survey showed that a considerable amount of users is using them - unclear if because that’s a default - or they have chosen to do so. * Overriding package versions in source variant can be more troublesome than it is in binary Action plan: * Improve documentation for source images, especially focusing on its advantages and what might change for current users of binary (when they make the transition) * Mark binary images as deprecated in Yoga cycle (add a note about deprecation in kolla-build CLI output) * Improve override options for source images (upper-constraints, etc) ## The next discussion item was to use a common base (single Linux distribution) for Kolla images Action plan (to make it possible): * Fix Bifrost and OVN builds for Debian (which are broken now) * Create CI jobs for mixed host-os/in-container-image-os (including upgrade jobs) * Deprecate binary images after those two actions are done * Provide a decent plan with justification and operator feedback in https://etherpad.opendev.org/p/kolla-only-on-debian <https://etherpad.opendev.org/p/kolla-only-on-debian> * Deprecate CentOS only images (like qdrouterd) At the same time we agreed on not pursuing CentOS Stream 9 or Ubuntu 22.04 LTS image builds, when those will show up/be required. ## Migration from ElasticSearch to AWS OpenSearch (Elasticsearch fork after ES changed license) Action items: * Deprecate Elasticsearch in Yoga * Build OpenSearch in Yoga # Kolla-Ansible ## Podman support We agreed to implement it with as minimum Ansible playbooks/roles changes as possible (mainly rework kolla_docker.py) Action plan: * Reduce scope of existing patch to deploy a single service (e.g. MariaDB) * Write up a rough implementation plan in https://etherpad.opendev.org/p/kolla-docker-systemd-podman <https://etherpad.opendev.org/p/kolla-docker-systemd-podman> * Add systemd units support for existing Docker implementation * Add podman installation in Kolla-Ansible’s baremetal role * Add podman support upon systemd support for Docker ## Change default deployment to use ML2/OVN (instead of ML2/OVS) We agreed on the criteria to do so: * Debian OVN packages in Yoga * Working and reliable migration path * A way to prevent accidental migration to OVN for existing deployments And until that is resolved - we’re not going to pursue that decision. ## Keystone system scope continued Action plan: * Proposed to split into 3 parts ** use system scope for keystone admin user (done in Xena) ** assign admin role to service users with system scope ** provide flags to enable scope enforcement and new defaults ## Let’s Encrypt Resume efforts to implement it (since we upgraded to HaProxy 2.2 which enables seamless TLS key/cert replacement) ## More HA settings by default Action plan: * Add a docs HA page that describes typical Kolla-Ansible deployment (haproxy, galera cluster, etc) with references to other projects HA configurations (e.g. neutron, octavia) ## Rocky Linux Host OS support Proposal: Replace CentOS Stream support to Rocky Linux in the longer run Action plan: * Add support for Rocky Linux as Host OS (no Kolla container images) # Kayobe ## Multiple environments part 3 Proposed improvements: * merge OpenStack custom configs * merge Kolla Ansible group_vars * dependencies between environments * CI testing ## Support RAID with Bifrost via cleaning steps and deploy steps Action plan: * Add support to baremetal_node_action Ansible module for manual cleaning and passing deploy steps * Option: Enable automated cleaning to erase metadata * Add support for using this functionality to Bifrost * Add passing of deploy_steps and cleaning_steps from Kayobe to Bifrost ## Create collection(s) for external Ansible roles that Kayobe depends on (those from StackHPC namespace) * Group Kayobe external roles to collections (the whole ,,ecosystem’’ of stackhpc.* roles) * Encourage Kayobe role users to move to collections * Add/improve CI testing for the collection For details please check the Kolla Yoga PTG etherpad: https://etherpad.opendev.org/p/kolla-yoga-ptg <https://etherpad.opendev.org/p/kolla-yoga-ptg> And see you on the weekly meetings: https://meetings.opendev.org/#Kolla_Team_Meeting <https://meetings.opendev.org/#Kolla_Team_Meeting> Best Regards, Michal Nasiadka

1 0

答复: [cyborg][ptg] Yoga PTG Summary
by Brin Zhang(张百林) 28 Oct '21

28 Oct '21

More details on etherpad: https://etherpad.opendev.org/p/cyborg-yoga-ptg brinzhang 发件人: Brin Zhang(张百林) 发送时间: 2021年10月28日 19:37 收件人: 'openstack-discuss(a)lists.openstack.org' <openstack-discuss(a)lists.openstack.org> 抄送: 'xin-ran.wang(a)intel.com' <xin-ran.wang(a)intel.com>; Alex Song (宋文平) <songwenping(a)inspur.com>; Jorhson Deng (邓兆森) <dengzhaosen(a)inspur.com>; Juntingqiu Qiujunting (邱军婷) <qiujunting(a)inspur.com>; 'eric_xiett(a)163.com' <eric_xiett(a)163.com> 主题: [cyborg][ptg] Yoga PTG Summary Hi everyone! First of all I would like to thank everyone for taking time and attending session. I think we had pretty productive time and discussions. You may find discussion summaries below: * With nova-cyborg interaction ** Cyborg vGPU support, we write a spec that adds the prefilter and the traits against every Nova RP and then cyborg contributors to provide a subsequent spec for Cyborg using their own trait ** Continue to work on resume/suspend feature, add the unit tests and update the PoC codes ** Works on PMEM instance cold migration in Nova, the spec is already merged in Xena release, and it need to re-propose it in Yoga release * Introducing some new accelerators driver ** xilin FPGA Driver ** PMEM Driver ** Optimization the exist device function, such as FPGA program interface, GPU/vGPU support * New feature will be support in Yoga release ** Get device profile get by name. It’s need to add a microversion, because of the request path_url changed, proposed the spec but need to update *** SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/813183 ** Add disable/enable device status to mark the device whether can be use or not ***SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/815460 ** We would like to improve the parameter validation, consider checking the api parameters with schema ** Add batch query ARQs for more than one instance support in Get *One* Accelerator Request API * Docs improving, such as nova-cyborg interaction manual and API ref docs * Improve the exception mechanism, improve the efficiency of abnormal judgment in unit testing * Improve the abnormal instance handling scenarios, for example, when the host is disconnected and the device is damaged, how should we set the device status and the accelerator instance state at this time. brinzhang

1 0

[cyborg][ptg] Yoga PTG Summary
by Brin Zhang(张百林) 28 Oct '21

28 Oct '21

Hi everyone! First of all I would like to thank everyone for taking time and attending session. I think we had pretty productive time and discussions. You may find discussion summaries below: * With nova-cyborg interaction ** Cyborg vGPU support, we write a spec that adds the prefilter and the traits against every Nova RP and then cyborg contributors to provide a subsequent spec for Cyborg using their own trait ** Continue to work on resume/suspend feature, add the unit tests and update the PoC codes ** Works on PMEM instance cold migration in Nova, the spec is already merged in Xena release, and it need to re-propose it in Yoga release * Introducing some new accelerators driver ** xilin FPGA Driver ** PMEM Driver ** Optimization the exist device function, such as FPGA program interface, GPU/vGPU support * New feature will be support in Yoga release ** Get device profile get by name. It’s need to add a microversion, because of the request path_url changed, proposed the spec but need to update *** SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/813183 ** Add disable/enable device status to mark the device whether can be use or not ***SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/815460 ** We would like to improve the parameter validation, consider checking the api parameters with schema ** Add batch query ARQs for more than one instance support in Get *One* Accelerator Request API * Docs improving, such as nova-cyborg interaction manual and API ref docs * Improve the exception mechanism, improve the efficiency of abnormal judgment in unit testing * Improve the abnormal instance handling scenarios, for example, when the host is disconnected and the device is damaged, how should we set the device status and the accelerator instance state at this time. brinzhang

1 0

[manila][ptg] Yoga cycle PTG summary
by Goutham Pacha Ravi 28 Oct '21

28 Oct '21

Hello Zorillas and other awesome Stackers, Thank you for participating in the Yoga cycle Project Teams Gathering. A special thanks to the folks at the OpenInfra Foundation who provided the platform for this event! We brainstormed on numerous topics. You'll find the unabridged notes and links in the main etherpad [1]. Video recordings from the event are posted on our Youtube channel [2]. The following is my summary of the proceedings. Please feel free to follow up here, or on OFTC's #openstack-manila if you have any questions. == Xena cycle retrospective == Etherpad: https://etherpad.opendev.org/p/manila-xena-retrospective * We celebrated successful Outreachy internships (Kafilat Adeleke and Archana Kumari), completion of the senior design project of students from Boston University (Ashley Rodriguez, Nicole Chen and Mark Tony) and two Open Source Day mentoring events at the Grace Hopper Celebration. * We have long term contributors in kafilat and archanaserver, along the lines of ashrod98 (who is now a Red Hatter!), disap (at Microsoft!), kiwi_36 (continuing his unified limits work), maaritamm (at city network, is manila core!) and many others. Very proud of the effort the team puts in to attract and retain such talent in the community. * We also discussed the mentoring efforts coinciding with the Yoga release (Northeastern University Cloud Computing course project, Outreachy internships, others). * We anticipate more changes to the maintainers team in the Yoga cycle in our continued effort to build domain expertise around the team, and avoid reviewer burn out. * Thanks to the enthusiastic participation, and to a well groomed bug backlog (kudos, vhari) we had two successful bugsquash weeks and a hack-a-thon during the Xena cycle. We're pruning down the list of stale issues collaboratively. The team liked the frequency of these events. * We discussed the responses for the 2021 User Survey and key takeaways (need for active/active HA, unified limits, unified cli, virtiofs) * Action Items: ** Plan a hack-a-thon in Yoga (topics welcome) ** Update questions for the 2022 user survey ** Plan periodic collaborative code review events alongside the bug squash events to prevent languishing patches. == Share transfers == * haixin highlighted the need for APIs to safely transfer shares across project namespaces and discussed some caveats, and a rough workflow for the feature * To ensure secure multi-tenancy, many back end share drivers use the project_id metadata in their provisioning paths - so transferring resources must send appropriate notifications * For DHSS=True, transfering the share alone makes little sense without first transfering the share network onto which the share is exported - however, multiple shares can be associated with one share network, so this could need a multi-phase transfer needing an ability to rollback. * Action Items: * Propose a spec and discuss the multi-stage implementation of this feature == Project testing and Interoperability improvements == * vhari shared plans for the improvement of the interop guidelines associated with manila * We touched upon the work lkuchlan and vhari are doing to align optional feature testing with tempest's best practices * Third party CI maintainers were reminded that they must be running scenario tests * Action Items: * Team looks at the possible tests to add as advisory to the 2021.11 guideline: https://etherpad.opendev.org/p/refstack-test-analysis == CephFS driver and integration changes == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-cephfsnfs-cephadm * vkmc highlighted the changes intended in the Manila CephFS driver to adopt the ceph mgr nfs APIs instead of the DBUS interactions that the Ganesha interace is coded to perform. The ceph mgr NFS APIs would only work on cephadm-deployed ceph nfs (nfs-ganesha) clusters. * Ceph nfs can be deployed like any other ceph daemon in an active/active HA cluster. One concern was the backwards incompatible changes to default nfs-ganesha configuration - this is being worked out. * TripleO developers joined us to discuss deployment changes, and the upgrade concerns including the eventual change in the NFS VIP. * Action Items: * Share notes about the deployment and upgrade changes necessary to get manila's CephFS driver to work with an active/active NFS HA cluster for the benefit of operators as well as deployment tools like tripleo, kolla-ansible, juju charms, etc. == Manila deployment at the Edge == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-at-the-edge * I quizzed fultonj about the use cases and architecture of the Distributed Compute Node edge deployments that tripleo is capable of orchestrating. * DCN now supports persistent block storage, and enables setting up the service in a multi-backend configuration with local-to-compute backends associated with availability zones that represent the edge sites. * We captured work items to similarly support manila-share at edge sites in this architecture to enable RWX storage at edge sites, and brainstormed future possibilities around the feature (cross site share replication) * Action Items: - A spec to support manila-share in an active/active HA configuration - Testing template for A/A with vendor share drivers == Metadata APIs for all user facing resources == Etherpad: https://etherpad.opendev.org/p/yoga-manila-metadata * ashrod98 discussed the ongoing work to generalize user defined metadata to all end-user facing resources. Currently users can attach metadata to shares and access rules, and the service provides metadata to export locations. * There are changes to the initial design that were brainstormed wrt RBAC and service/operator metadata. * The new APIs are going to be supported in the openstackclient shell implementation * Action Items: * Reviewer attention needed for the changes to the metadata spec, and for new RBAC guarding operator metadata. == Manila UI updates == * vkmc, carloss and haixin presented the plan to update the UI's feature parity * We have two outreachy internship proposals around implementing new UX around share networks and for enhancing integration testing for manila-ui * Action items: * Outreachy contributor period is open, lookout for applicants seeking reviews * Identify trivial API features that can be supported with little effort for the Yoga cycle hack-a-thon == VirtIOFS == Etherpad: https://etherpad.opendev.org/p/nova-manila-virtio-fs-support-yptg-october-2… * tbarron presented updates regarding the ongoing prototyping for nova's support of virtiofs. * There's a demo of how the feature's expected to work: https://asciinema.org/a/IZ7UrhwspxBN63XsOl9JrTcUX?speed=1.5 * The nova discussion (https://etherpad.opendev.org/p/nova-yoga-ptg) included mechanics of supporting read-only attachments, os-share library, mount tags and use cases for baremetal nodes. The specification will be refined to answer some of these questions. * This continues to be a multi-release effort as changes in libvirt, qemu, kvm were needed for live virtiofs attachments. * Action Items: * Review/Refine nova spec: https://review.opendev.org/c/openstack/nova-specs/+/813180 == Multiple share network subnets in an AZ == Etherpad: https://etherpad.opendev.org/p/ptg-multiple-subnet * nahimsouza and felipe_rodrigues presented the use case for share networks to allow multiple subnets per availability zone. * This proposal would make dual stack ipv4/ipv6 networking possible for DHSS=True * Users would also have the ability to modify share networks that were in use - new network allocations will be possible for existing share servers, however, network allocations cannot be deleted. * Concerns were raised regarding the user experience and error signalling when port allocations cannot be made from all relevant subnets. * Action items: * Determine what needs to happen when a subnet has run out of allocations * Propose a specification discussing the API and driver interface impact to accommodate this change == FIPS compatibility and compliance == Etherpad: https://etherpad.opendev.org/p/yoga-manila-FIPS * carloss, ashrod98 and ade_lee spoke of the cross project effort to get FIPS compatibility and compliance testing * We discussed manila's direct/indirect use of cryptographic libraries and FIPS compliant alternatives (md5 in code, and paramiko's use of non-fips compliant digests); manila-tempest-plugin needs fixes along the same lines since it relies on paramiko. * Currently, the team's writing new CI jobs to test compatibility - these should merge by the end of the Yoga release cycle; the goal for compliance would be the Zorilla release (yes, i said it). * Action items: * Work on FIPS compatibility jobs in the Yoga release cycle == Secure RBAC changes in Yoga == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-srbac * vhari and I rounded up the work done so far to update the default RBAC policies across manila APIs and highlighted known issues, and pending work items * Cross service arbitrations on behalf of a user are ongoing discussions elsewhere - examples of these include manila's generic driver where the user's namespace and quota are consumed to create the nas server, backing volume and networking * We are continuing to implement tempest tests and anticipate a large portion to be completed during the Yoga cycle. * We don't plan to support cloud profiles with the manilaclient shell. Users are encouraged to switch to the openstackclient shell to use cloud profiles. * Action items: * Close on known issues in manila code * Complete protection and tempest test coverage == Paying down some technical debt in Yoga == * python-manilaclient still uses keystoneclient instead of keystoneauth1 - vkmc and gouthamr will work on this early in the Yoga release cycle * sqlalchemy2.0 changes - ack'ing SADeprecationWarnings and switching to using the new db engine facade exposed by oslo.db - felipe_rodrigues and gouthamr will work on this during the Yoga cycle * these are wishlist items that need volunteers to drive them to completion: * the generic driver doesn't yet support online extensions - * the generic driver can support more than 26 volumes per share server - this is a wishlist item that needs a volunteer to drive it * we need to publish the container driver image to a container registry from its development within the manila-image-elements project == Backing up shares == Etherpad: https://etherpad.opendev.org/p/ptg-backup-manila * We were joined by operators and storage experts from SAP, CSI Piemonte, NetApp, Red Hat and CERN to discuss current use cases and methods to backing up manila shares * Existing data protection and disaster recovery tools within manila (creating and mounting snapshots, cloning snapshots to new shares, reverting snapshots in-place, replicating shares and snapshots) were compared against the need for scheduling, efficient, incremental, durable/ex-situ/non-homogenous backup destinations, whole container vs selective file backup and recovery. * Available DIY external tooling (restic, borg, urbackup, other) and wrappers were discussed * Creating a backup solution based off-of the manila-data service was considered in the past, the spec was abandoned. It could be revived; however, we could benefit from presenting the need, a state of affairs as they are before exploring solutions. * Action Items: * We'll write up a doc on data protection for manila shares and invite operators to review them and propose future plans; anyone interested in collaborating in this space can get in touch with felipe_rodrigues == OpenStackCLI updates == Etherpad: https://etherpad.opendev.org/p/manila-osc-yoga * Thanks to maaritamm's awesome work, and the enthusiastic hack-a-thon participation from the community, we're very close to parity between OSC and the manilaclient shell. So, the team decided to stop adding new features in the manilaclient shell as a way to gradually wean users off of it. * When using the manilaclient shell from the Yoga release, users will be shown a deprecation warning suggesting an eventual removal (looking at the "A" release for this one, thoughts are welcome). * maaritamm proposed a hack-a-thon for completing the functional testing around manilaclient's osc plugin. * The osc plugin also needs the api microversion negotiation bits that the manilaclient shell currently has. * Action items: * We assigned owners to pending reviews, and missing osc commands * Deprecate the native manilaclient shell. == Manila CSI updates == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-csi * gman0 and tbarron presented the state of the kitchen for manila-csi since the Xena PTG and shared future plans * share backup is now a focus area for pvs serviced by manila-csi - the design involves being able to mount manila snapshots as read only PVs on backup pods and extracting relevant files. * we discussed e2e testing that's being added to the cloud-provider-openstack repository and the results of the perf/scale testing with manila-csi on openshift == OpenStackSDK updates == Etherpad: https://etherpad.opendev.org/p/yoga-manila-openstacksdk-update * we've had several interns working on exposing manila APIs within the openstacksdk since the wallaby release * kafilat has numerous open changes, wrapped up a successful outreachy internship recently * megharth, Jiabo, tutkuna and rishabhdutta from Northeastern University picked up the implementation of the remaining API resources for the Yoga cycle * this continues to be a multi-cycle effort and the plan is to eventually use manila APIs via the openstacksdk within manila-ui, ansible-collections-openstack and manila's OSC plugin. * Action Items: * team will review open changes against the openstacksdk repository pertaining to manila Thanks for reading thus far. It's possible a lot can get lost in translation :) As a reminder, do check out the complete recordings on our Youtube channel! [2] -- Goutham Pacha Ravi PTL, OpenStack Manila [1] https://etherpad.opendev.org/p/yoga-ptg-manila [2] https://www.youtube.com/watch?v=wVAClI82Ths&list=PLnpzT0InFrqDhp1A3lBi_guLA…

1 0