<div dir="ltr"><div style="font-family:verdana,sans-serif" class="gmail_default">Hi All,<br><br>We had our fifth virtual PTG between 4th April to 8th April 2022. Thanks to everyone who joined the virtual PTG sessions. Using bluejeans app we had lots of discussion around different topics for glance, glance + cinder, fips and Secure RBAC.<br><br>I have created etherpad [1] with Notes from the session and which also includes the recordings of each discussion. Here is a short summary of the discussions.<br><br>Tuesday, April 5th 2022<br><br># Yoga Retrospective<br>On the positive note, we managed to complete all the work we targeted for the yoga cycle. In addition to that we have organized a first ever glance review party where we managed to perform group reviews which helped us to cover our review load in the final milestone. On the other side we need to reorganize our bi-weekly bugs meeting and also improve our documentation and API references.<br><br>Recording: <a href="https://bluejeans.com/s/kVeDPbu6kX2">https://bluejeans.com/s/kVeDPbu6kX2</a> - Chapter 1<br><br># Cache API - New API to trigger periodic job<br>In Yoga we have managed to put together new endpoints for cache, this cycle we should add a new API to trigger the periodic job to cache the images.<br>Here we have decided to get rid of periodic job and add a new API to cache(pre-cache) the specified image(s) instantly rather than waiting for the next periodic run to pre-cache those images.<br><br>Recordings: <a href="https://bluejeans.com/s/kVeDPbu6kX2">https://bluejeans.com/s/kVeDPbu6kX2</a> - Chapter 2<br><br># Glance Cache improvements, restrict duplicate downloads<br>How we can avoid multiple downloading of the same image in cache on first download.<br>Final design - <a href="https://review.opendev.org/c/openstack/glance-specs/+/734683">https://review.opendev.org/c/openstack/glance-specs/+/734683</a><br><br>Recordings: <a href="https://bluejeans.com/s/kVeDPbu6kX2">https://bluejeans.com/s/kVeDPbu6kX2</a> - Chapter 3<br><br># Distributed responsibilities among cores/team<br>From this cycle we have decided to follow a distributed leadership model internally which will help us to train internal members to take the PTL responsibilities in the upcoming cycle. We have decided to distribute the below responsibilities among ourselves in this cycle.<br><br>Release management: pranali/abhishek<br>Bug management: cyril/abhishek<br>Meetings:pranali<br>Stable branch management: jokke<br>Cross project communication:abhishekk<br>Mailing lists:pranali/abhishekk<br>PTG/summit preparation:pranali/abhishekk<br>Vulnerability management: jokke<br>Infra management: abhishekk<br><br>Recordings: <a href="https://bluejeans.com/s/kVeDPbu6kX2">https://bluejeans.com/s/kVeDPbu6kX2</a> - Chapter 4<br><br># Secure RBAC - System Scope<br>Unfortunately due to time crunch we were not able to find answers to a few of our queries in this PTG, so we have decided to attend the Open office hours and Policy popup meetings to get them sorted. As per community goal we should be enforcing the new RBAC policies from this cycle and support system-admin. Once we get our doubts sorted then we will share more information about the same.<br><br>Recordings: <a href="https://bluejeans.com/s/kVeDPbu6kX2">https://bluejeans.com/s/kVeDPbu6kX2</a> - Chapter 5<br><br># Policy refactoring - Part 2<br>In Xena we have managed to move all policy checks to the API layer. This cycle we need to work on removing dead code of policy and authorization layer. So we are going to ensure that the policy and authorization layer are not used anywhere before removing it from the code base.<br><br>Recordings: <a href="https://bluejeans.com/s/kVeDPbu6kX2">https://bluejeans.com/s/kVeDPbu6kX2</a> - Chapter 6<br><br><br>Wednesday, April 06th 2022<br><br># Proposal for moving away from onion architecture<br>This is a long term goal and from this cycle we should start doing homework on how we can squash two or more layers together and move away from the onion architecture and obtain a popular and simple MVC architecture in upcoming cycles. This cycle we will be mostly working on finalizing the detail spec about this work.<br><br>Recordings: <a href="https://bluejeans.com/s/ZmURX2kOeJy">https://bluejeans.com/s/ZmURX2kOeJy</a> - Chapter 1 <br><br># Import image from another region<br> When dealing with a multi-region cloud it often appears that operators or customers need to copy images from a region to another (it can be public images or even remote backup of instance snapshot).<br> It is currently complicated to implement as customers need to save the image locally, then upload it to the new region. We propose to rely mostly on the web-download code of glance to directly download an image from a remote glance, calling this method « glance-download ». Note that this first version will require a federated Keystone between all the glance in order to avoid all authentication problems (we will rely on the context token of the target glance to authenticate to the remote glance).<br><br>Recordings: <a href="https://bluejeans.com/s/ZmURX2kOeJy">https://bluejeans.com/s/ZmURX2kOeJy</a> - Chapter 2<br><br># Expanding stores-info detail for other stores<br>In Yoga we added a new API ``stores-detail`` to expose the properties of stores but currently it is only exposing details of rbd store, we are planning to extend its support to expose properties of other stores as well.<br><br>Recordings: <a href="https://bluejeans.com/s/ZmURX2kOeJy">https://bluejeans.com/s/ZmURX2kOeJy</a> - Chapter 3<br><br># Discussion of property injection coherency between image import and possible implementation in upload<br>Glance does support injecting certain properties for images created by non-admin users by using inject metadata import plugin, but same is not possible when we do not use import workflow and use traditional way to create the image. This cycle we will be working on supporting injecting the metadata while creating images using upload workflow.<br><br><a href="https://bluejeans.com/s/ZmURX2kOeJy">https://bluejeans.com/s/ZmURX2kOeJy</a> - Chapter 4<br><br><br>Thursday, April 07th 2022<br><br># Refactor glance cinder store<br>Currently we have one file for cinder store where the logic for handling all cinder backend types (on basis of protocol) exists. It makes the code less readable and prone to mistakes and even the  unit testing for code coverage is difficult due to a lot of nested code. The idea of this proposal is to divide the one big file into backend specific files on the basis of operations sharing the same interface. Eg: connect_volume call for most of the backends is the same except for remotefs type drivers where it is handled in a custom way.<br><br><a href="https://bluejeans.com/s/oiS49m8Pj_o">https://bluejeans.com/s/oiS49m8Pj_o</a> - Chapter 1<br><br># Native Image Encryption<br>Barbican updates:<br>- Microversion is done<br>- Secret consumer will be implemented by milestone 1<br>- Luzi is interested to work on image encryption<br>- Glance will keep watch and review the work if posted this cycle<br><br># Default Glance to configure multiple stores<br>Glance has deprecated single stores configuration since Stein cycle and now will start putting efforts to deploy glance using multistore by-default and then remove single store support from glance.<br>This might be going to take a couple of cycles, so in yoga we are going to migrate internal unit and functional tests to use multistore config and also going to modify devstack to deploy glance using multistore configuration for swift and Ceph (for file and cinder it's already supported).<br><br>We need to notify respected deployment teams (ansible/tripleo/ceph-admin) about our work and we are moving from single store configuration.<br><br>Recordings: <a href="https://bluejeans.com/s/oiS49m8Pj_o">https://bluejeans.com/s/oiS49m8Pj_o</a> - Chapter 2<br><br># Fips overview<br>Path forward:<br>- add experimental/periodic fips job on centos 8 (it will run on master)<br>- centos 9 dependency fixes (tempest and swift changes)<br>- Once dependency merges, experimental/periodic job will be run for centos 9 (enough time to verify that it is stable now)<br>- Once it is stable, move it to check/gate queue<br>- Then backport swift/tempest dependencies to stable branches<br>- Run centos 9 fips job as periodic on stable branches<br>- Once stable move those to gate/check queue for stable branches<br>        <br>Recordings: <a href="https://bluejeans.com/s/oiS49m8Pj_o">https://bluejeans.com/s/oiS49m8Pj_o</a> - Chapter 3<br><br># Cross project meet with Cinder<br><br>Discussion 1: New API to expose location information<br>We have OSSN-0065 describing the security risk of enabling ``show_multiple_locations`` option but this is required for cinder to perform certain optimizations when creating a volume from image  (in case of cinder and RBD store). The proposal is to create a new admin only API to provide the location of the image and avoid dependency on the config options.<br><br>Decided to write a spec describing the current API design for the new locations API (alternative: nova's approach of using alternative endpoint and service role/token as well)<br><br>Discussion 2: Clone v2: RBD deferred deletion<br>Recently cinder has utilized Ceph clone v2 support for its RBD backend, since then if you attempt to delete an image from glance that has a dependent volume, all future uses of that image will fail in error state. Despite the fact that the image itself is still inside of Ceph/Glance. This issue is reproducible if you are using ceph client version greater than 'luminous'.<br><br>Decided to fix things on cinder side and see how we can fix glance using the same techniques (also document it since customers face these issues all the time)<br><br>Recordings: <a href="https://bluejeans.com/s/efAqf0e5RDQ">https://bluejeans.com/s/efAqf0e5RDQ</a> - Chapter 2<br><br>Friday, April 08th 2022<br><br># Image Export with metadata<br>Especially if we implement the glance-download discussed on Wednesday it might be worth exploring my old idea of image export, which would bundle the image metadata together with the image payload itself for easier import into the glance environment. This will need bits of work on both sides of the process. The source will need to be able embed the metadata into the end of the datastream sent to the client and the receiving end will need to understand how to pick up and parse that data. To make easier transfer of the image (especially RAW images from all of our Ceph deployments) the original image payload should be compressed on the fly when sent to the client and the metadata can be added after the compression is closed. This way the image can be brought in older glance deployments too that supports the uncompression and if it doesn't know to look at the metadata that part will be just simply ignored.<br><br>Recordings: <a href="https://bluejeans.com/s/C7F5pDPR_v4">https://bluejeans.com/s/C7F5pDPR_v4</a> - Chapter 1<br><br><br>You will find the detailed information about the same in the PTG etherpad [1] along with the recordings of the sessions and milestone wise priorities at the bottom of the etherpad. Kindly let me know if you have any questions about the same.<br><br>[1] <a href="https://etherpad.opendev.org/p/zed-glance-ptg">https://etherpad.opendev.org/p/zed-glance-ptg</a><br><br>Thank you,<br><br>Abhishek<br></div><br></div>