Bug 1833109 - storageManaged stays true if spec.storage is changed
Summary: storageManaged stays true if spec.storage is changed
Keywords:
Status: VERIFIED
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Image Registry
Version: 4.1.z
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 4.6.0
Assignee: Ricardo Maraschini
QA Contact: Wenjing Zheng
URL:
Whiteboard:
: 1814709 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-07 19:54 UTC by Oleg Bulatov
Modified: 2020-09-15 12:23 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: After initial operator bootstrap storageManaged was set to true on status. If user decided to update the storage config manually this field remained as true. Consequence: 1. When setting the registry as Removed it attempts to delete its storage, on the scenario where the user manually updated the config it will attempt to remove user provided storage. 2. With storageManaged as true the operator attempts to sets some defaults on the storage (such as encryption), on the scenario where the user provided config manually this should not be done. Fix: Providing an extra config field (spec.storage.storageManagementState) so user can indicate its intention with regard with managing the storage. This field accepts Managed or Unmanaged, on the latter the operator won't try to delete the storage and or apply its defaults. Result: User can now indicate that the storage should not be managed by the operator by setting it to Unmanaged.
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift api pull 717 None closed Bug 1833109: Adding ManagementState property to storage 2020-09-16 16:17:20 UTC
Github openshift cluster-image-registry-operator pull 588 None closed Bug 1833109: Refactoring for Azure Driver 2020-09-16 16:17:21 UTC
Github openshift cluster-image-registry-operator pull 596 None closed Bug 1833109: Spec.Storage.ManagementState implementation 2020-09-16 16:17:21 UTC

Description Oleg Bulatov 2020-05-07 19:54:35 UTC
Description of problem:

When I create a new bucket and want to use it for the registry instead of the bucket that was provided by the registry operator, the operator starts to manage.

Version-Release number of selected component (if applicable):


How reproducible:

always

Steps to Reproduce:
1. create a new bucket
2. update config.imageregistry spec.storage.s3.bucket, use the new bucket

Actual results:

The operator starts to use the new bucket, but status.storageManaged stays true.

Expected results:

storageManaged should become false.

Additional info:

Comment 3 Oleg Bulatov 2020-05-26 14:46:06 UTC
It's too risky to fix this in 4.5.0, moving to 4.6

Comment 17 Ricardo Maraschini 2020-09-01 08:21:06 UTC
*** Bug 1814709 has been marked as a duplicate of this bug. ***

Comment 18 Wenjing Zheng 2020-09-04 03:19:06 UTC
I still can see status.storageManaged==true when I use self-created bucket on 4.6.0-0.nightly-2020-09-03-191144:
 storage:
    managementState: Managed
    s3:
      bucket: wzheng-test-3
      encrypt: true
      region: us-east-1
      virtualHostedStyle: false
  storageManaged: true

Comment 19 Ricardo Maraschini 2020-09-04 08:44:58 UTC
This is by design, we bootstrap as Managed and only move to Unmanaged (or storageManaged = false) if the user asks for it. The idea here is, if the user wants to manage the storage by herself she must first change the Spec.Storage.ManagementState to Unmanaged, from this point on the operator won't touch the storage anymore.

Comment 20 Wenjing Zheng 2020-09-04 08:52:28 UTC
Thanks for the reply, Ricardo! Then this bug can be verified.


Note You need to log in before you can comment on or make changes to this bug.