[Glance] Antelope PTG Summary

Pranali Deore pdeore at redhat.com
Tue Oct 25 19:43:59 UTC 2022


Hello Everyone,

We had our sixth virtual PTG between 18th OCt to 21st OCT 2022. Thanks to
everyone who joined the virtual PTG sessions. Using bluejeans app we had
all the discussion around different topics for glance, glance + cinder,
glance + ceph, fips and secure RBAC.

I have created etherpad[1] with notes from the session and also included
the recordings of each session. Here is the short summary of the
discussions.

Tuesday, OCT 18th 2022

# Zed Retrospective
 On the positive note, we have merged a number of useful features this
cycle. We managed to implement glance-download internal plugin to download
the image from remote glance,
 Implemented support for immediate caching of an image, Extended the
functionality of stores-detail API to expose store details of other stores
and we have removed the scope scheck
 from scope_types for all project resources and done with phase 1 as per
the revised community goal.

 In addition to that we have successfully organized the review party before
each milestone to perform group review to cover the review load till the
final milestone.
 On the other side we decided to organize a midcycle general cross project
meetup/drivers meetup towards the end of the 2nd milestone to increase our
presence in cross-projects.

Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 1

# Distributed responsibilities among cores/team
    This cycle also we have decided to follow the distributed leadership
internally, we are going to distribute below responsibilities among the
team,
    Release management:pranali
    Bug management: cyril
    Meetings: pranali
    Stable branch management: cyril and Erno
    Cross project communication: abhishekk
    Mailing lists: share responsibility, pranali
    PTG/summit preparation:pranali
    Vulnerability management: glance-coresec group
    Infra management:
        periodic-jobs - abhishekk
        migration of test jobs -abhishekk

   Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 2

 # Default Glance to configure multiple stores
    Glance has deprecated single store configuration since Stein Cycle and
this cycle we are going to start putting our efforts to deploy glance using
multistore by default and then remove
    the single store support from glance.

   Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 3

 # Add missing CLI support for some Glance API in Openstack Client
    The CLI support for all glance APIS is already there in GlanceClient
and the similar CLI support we need to have in OpenstackClient, in this
Cycle we are going to put efforts to have
    OSC support for all the missing glance APIs.

    Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 4

# Glance Cache improvements, restrict duplicate downloads
    This is abou how we can avoid multiple downloading of the same image in
cache on first download
    Spec : https://review.opendev.org/c/openstack/glance-specs/+/734683
    We had this spec in the last cycle & decided to break the image into
chunks and when the first request gets to the backend store it will start
caching that image and if any other
    request comes in between and if caching is still in process it will
read from the chunks created by the first request.  But currently we have
made one caching state to check if the
    image is still in caching but that was relying on md checksum to check
if the image iterator has read the image completely or not but in new
images we might not have checksum,
    multihash or size of the image, bcz if that is not present with the
image we won't be able to change the state of image and thus we will never
be able to resolve the issue of checking
    the image is in caching or not.

    Decided to dig more on the size verification & need to revisit this
topic during mid-cycle meeting and update the spec with the solution for
handling the multiple request and multiple chunks

    Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 5

 Wednesday OCT 19th , 2022

 # Image uploads to the filesystem driver are not fully atomic
    No efficient way to reproduce this issue, so it's decided to mark it as
'Won't fix'

    Recording:  https://bluejeans.com/s/j_UgZFw_jEV - Chapter 1

 # DB migration constant change handling
    Till now we have all the migration scripts by the name of the cycle and
since currently release has been change to 2023.1 which is going to break
the migration test because when our
    DB sync tool runs it will check the initial version liberty and it
finds the migration script from the liberty and traverse through all the
directories till the current release and executes all
    the scripts available in that path.

    Decided to fix this by updating the data migration current release to
'2023.1' and check with actual migration script to check whether there is
any regression or not and check if it executes the scripts in serial
    manner.

  Recording:  https://bluejeans.com/s/j_UgZFw_jEV - Chapter 2

# Configurable Soft Delete
    Stephen initiated this topic for nova and oslo.db but also sent out a
mail for glance, cinder and for other projects, if we would be interested
in the idea

https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030729.html

    But Glance replies a lot on soft delete and doesn't allow hard delete
as glance allows the user to specify the UUID of the image , so it's part
of a security promise of an immutable images that you are not able
    to delete an image and then recreate image with same UUID right after,
hence soft delete model can't be removed from Glance.

    Recording:  https://bluejeans.com/s/j_UgZFw_jEV - Chapter 3

# Secure RBAC
   As per the revised community goal, till zed cycle we must have the
project prosona implementation & drop the system scope which we have
already done in glance. We have implemented project scope for
   image apis in wallaby & in Xena we have managed to move all policy
checks to API layer and implemented project scope of metadef APIs.

   During zed cycle, we had discussed that like which apis should be
exposed to system scope but after the operators feedback & as per the
revised community goal it was decided to drop the system scope, we
   just had to remove the scope scheck from scope_types for all project
resources, so we are done with Phase 1.

   In Antelope Cycle glance is going to switch the new defaults flag ON,
once it is verified by tempest for all the services.

   Recording:  https://bluejeans.com/s/j_UgZFw_jEV - Chapter 4

# Image Export with Metadata
   This is about exporting images with associated metadata for importing
into another Glance deployment.
   This cycle we need some volunteers to work on this, the glance team will
help in terms of reviews/finalizing the design etc otherwise we will
revisit this in the next cycle.

   This session was not recorded as it was a small discussion

# Fips Overview
   Path forward:
  - Investigate on the time outing of the existing glance fips job
  - Try to do the centos9 jobs stable till wallaby, so could possibly move
to voting
  - Have ubuntu jobs working & running and make them stable

  Recording:  https://bluejeans.com/s/j_UgZFw_jEV - Chapter 5

Thursday, OCT 20th, 2022

# Option needed to create image in erasure coded ceph pool
    To use the erasure coded ceph pool feature where the data will be held
needs to be specified during image creation, a config option is needed.
    Decided to write a spec first describing this in detail and modify the
existing devstack job for ceph.

    Recording: https://bluejeans.com/s/cNEJ@Yq_hv5 - Chapter 1

# Parallelization of RADOS image writes when creating an image
    This is for  parallelization of image writes into ceph, by increasing
the amount of data written at once.
    Decided to not have this without testing to measure if there's an
actual gain.

    Recording:  https://bluejeans.com/s/cNEJ@Yq_hv5 - Chapter 2

# Add chunk download support for rbd backend
    Rbd supports random reading, and the rbd driver is designed to support
partial download. But the current version disables this feature, and
doesn't implement the chunk support.

    There is potential future use for it, but there's nothing that users
would gain from this. If not usable through the API then we will drop this.

    Recording: https://bluejeans.com/s/cNEJ@Yq_hv5 - chapter 3

# Operators hour
   No operator joined the session

# Speedup upload images for Swift backend
    Upload images using Swift backend is slow due to the synchronous way of
uploading fragments and which causes loading that can take several hours,
especially in cases with very large images.

    Decided to update the spec with two implementations one as traditional
& one for multithreaded one, by having a new configuration option
``swift_store_thread_pool_size`` to the Swift store backend.

    Recording: https://bluejeans.com/s/cNEJ@Yq_hv5 - Chapter 4

Friday, OCT 21st, 2022

# Cross project meet with Cinder
# Glance Image Direct URL access Issue
   Glance has OSSN-0090[2] describing the security risk when you are
operating glance with 'show_multiple_locations' or if the end user facing
glance-api has 'show_image_direct_url' options set to true.
   When glance shares a common storage backend with nova & cinder, it is
possible to open some known attack vendors by which malicious data
modification can occur.

   Decided to fix this by going with the solution proposed by Rajat during
last cycle, to remove the show_multiple_locations config option and to have
below 2 new location APIs[3]  which will replace
   the image-update mechanism for consumers like cinder and nova in glance,
    1. Location ADD API:
        Design this api in way that the location will be added only once
during image create when the image is in QUEUED state and no-one should be
allowed to add location after the image is active
        This wouldn't require the 'service role' and a basic check on the
glance side to check image status should suffice.
     2. Location GET API:
         This will show all the locations associated with an existing
image. Returns an empty list if an image contains no locations.
         This would still require the 'service role' since we don't want to
expose locations to end users.

    Glance has dependency on keystone for 'service role' which is going to
be implemented in this cycle as per phase 2 target mentioned in SRBAC
community goals[4].

    Recording : https://bluejeans.com/s/B4Rlifuwx_l - Chapter 1

 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.

[1]: https://etherpad.opendev.org/p/antelope-glance-ptg
[2]: https://wiki.openstack.org/wiki/OSSN/OSSN-0090
[3]:
https://specs.openstack.org/openstack/glance-specs/specs/zed/approved/glance/new-location-info-apis.html
[4]:
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-2


Thanks,
Pranali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221026/49665722/attachment-0001.htm>


More information about the openstack-discuss mailing list