object: remove default value us-east-1 as region from s3 client #9754

thotz · 2022-02-16T10:28:09Z

Currently s3 client apis sets default value as us-east-1. This patch
removes that, region need to map with zonegroup in the RGW server so we
set that accordingly

Signed-off-by: Jiffin Tony Thottan thottanjiffin@gmail.com

Description of your changes:

Which issue is resolved by this Pull Request:
Resolves #

Checklist:

leseb

This change is not passing CI.

travisn

us-east-1 is still used in the integration tests in ceph_base_object_test.go. How about changing that to something else so we can see the non-default works?

travisn · 2022-02-17T14:52:54Z

tests/framework/clients/bucket.go

@@ -157,9 +157,9 @@ func (b *BucketOperation) CheckBucketNotificationSetonRGW(namespace, storeName,
 	s3AccessKey, _ := helper.BucketClient.GetAccessKey(obcName)
 	s3SecretKey, _ := helper.BucketClient.GetSecretKey(obcName)
 	if tlsEnabled {
-		s3client, err = rgw.NewInsecureS3Agent(s3AccessKey, s3SecretKey, s3endpoint, "", true)
+		s3client, err = rgw.NewInsecureS3Agent(s3AccessKey, s3SecretKey, s3endpoint, storeName, true)


If a different region is specified in the storage class, will this client connection work with the store name? Or does it need to match the storage class?

@travisn : I wondered magic behind us-east-1 as region value. The actual value for s3 client needs to storeName and ideally we should have filled same value for storage class. The us-east-1 works for RGW, I am guessing it skips checks(or maybe bug)

@travisn : [Another update]: us-east-1 as a region no longer valid in master, it works with pacific though. So IMO we might see a similar issue when we start using new ceph versions

So if we remove region from the default examples in rook, it will work with ceph pacific and master? Or will we need different examples for pacific vs quincy? And to be clear, does the ceph master change also affect quincy, or just post-quincy?

Yeah, it will work, this fills internal by Rook. Earlier we are using us-east-1 from this patch we add the actual zone of the rgw server that's the difference.
The us-east-1 worked in quincy as well, but I don't see much code difference in that path for master and Quincy. Need to have a bit of time to understand that

The documented examples we are working on in the other comments only apply to Quincy and newer, correct? So what is the behavior for region in Pacific? The docs need to give that detail, especially since Pacific is still the default version with Rook.

@travisn : Sorry if I created confusion before for RGW in any versions, region is the zone group but (again true for all versions) if we give region as us-east-1 it will bypass some checks in RGW and request succeed. I felt it is kind of a hack. But without knowing much about this context Rook was setting us-east-1 for the internal aws s3 SDK and this was working fine for our use case. But this may create confusion for users when they use us-east-1 works but other region's requests are failing. By this PR we are avoiding hack and using the required value

I'm still confused about how users can understand the region. If us-east-1 is a workaround and a hack, maybe we should just keep that for the simple, local rgw case. What does the user gain by using a different region? Seems like it should only be important for external or multi-site where we need the region name in order to connect. But if it's just the local cluster, can we hide the region from the user so they don't need to worry about it?

Let's find a time to discuss this next week since I'm having such a hard time. :)

@travisn: Sure :). Sounds good to me

pkg/operator/ceph/object/bucket/provisioner.go

BlaineEXE · 2022-02-17T20:13:24Z

deploy/examples/storageclass-bucket-delete.yaml

@@ -9,7 +9,7 @@ reclaimPolicy: Delete
 parameters:
   objectStoreName: my-store
   objectStoreNamespace: rook-ceph # namespace:cluster
-   region: us-east-1
+   # region: us-east-1


If this needs to match with the zone group, perhaps we should add documentation here in the example and also in the official docs to help users set this value correctly.

@BlaineEXE : I will try to add #9556 with this change

@thotz Since the default is us-east-1, should we just leave this default uncommented?

Suggested change

# region: us-east-1

region: us-east-1

thotz · 2022-02-21T14:26:28Z

us-east-1 is still used in the integration tests in ceph_base_object_test.go. How about changing that to something else so we can see the non-default works?

@travisn : do u want to check whether with regions and see s3 client works or not right? It's more or like s3 client kind of test, but I can definitely add those

travisn · 2022-02-21T17:01:47Z

us-east-1 is still used in the integration tests in ceph_base_object_test.go. How about changing that to something else so we can see the non-default works?

@travisn : do u want to check whether with regions and see s3 client works or not right? It's more or like s3 client kind of test, but I can definitely add those

Yes sounds to add some testing for this.

thotz · 2022-02-22T11:37:40Z

us-east-1 is still used in the integration tests in ceph_base_object_test.go. How about changing that to something else so we can see the non-default works?

@travisn : do u want to check whether with regions and see s3 client works or not right? It's more or like s3 client kind of test, but I can definitely add those

Yes sounds to add some testing for this.

The only create bucket request needs the correct region value, all the objects operation works fine with the
invalid region for s3 client. So I guess I need to add a test case for cephobjectstoreuser by creating a bucket to test this out

Documentation/ceph-object-bucket-claim.md

travisn · 2022-02-22T17:57:00Z

tests/framework/clients/bucket.go

@@ -157,9 +157,9 @@ func (b *BucketOperation) CheckBucketNotificationSetonRGW(namespace, storeName,
 	s3AccessKey, _ := helper.BucketClient.GetAccessKey(obcName)
 	s3SecretKey, _ := helper.BucketClient.GetSecretKey(obcName)
 	if tlsEnabled {
-		s3client, err = rgw.NewInsecureS3Agent(s3AccessKey, s3SecretKey, s3endpoint, "", true)
+		s3client, err = rgw.NewInsecureS3Agent(s3AccessKey, s3SecretKey, s3endpoint, storeName, true)


So if we remove region from the default examples in rook, it will work with ceph pacific and master? Or will we need different examples for pacific vs quincy? And to be clear, does the ceph master change also affect quincy, or just post-quincy?

Documentation/ceph-object-bucket-claim.md

travisn · 2022-02-24T14:32:04Z

tests/framework/clients/bucket.go

@@ -157,9 +157,9 @@ func (b *BucketOperation) CheckBucketNotificationSetonRGW(namespace, storeName,
 	s3AccessKey, _ := helper.BucketClient.GetAccessKey(obcName)
 	s3SecretKey, _ := helper.BucketClient.GetSecretKey(obcName)
 	if tlsEnabled {
-		s3client, err = rgw.NewInsecureS3Agent(s3AccessKey, s3SecretKey, s3endpoint, "", true)
+		s3client, err = rgw.NewInsecureS3Agent(s3AccessKey, s3SecretKey, s3endpoint, storeName, true)


The documented examples we are working on in the other comments only apply to Quincy and newer, correct? So what is the behavior for region in Pacific? The docs need to give that detail, especially since Pacific is still the default version with Rook.

Currently s3 client apis sets default value as `us-east-1`. This patch removes that, region need to map with zonegroup in the RGW server so we set that accordingly Signed-off-by: Jiffin Tony Thottan <thottanjiffin@gmail.com>

The default value for region in RGW is us-east-1, if users want to use other regions then they need to create zone/zonegroup accordingly before defining it in storage class. Fixes: rook#9486 Signed-off-by: Jiffin Tony Thottan <thottanjiffin@gmail.com>

travisn · 2022-03-07T18:41:05Z

Documentation/ceph-object-bucket-claim.md

  bucketName: ceph-bucket [4]
 reclaimPolicy: Delete [5]
 ```
 1. `label`(optional) here associates this `StorageClass` to a specific provisioner.
 1. `provisioner` responsible for handling `OBCs` referencing this `StorageClass`.
-1. **all** `parameter` required.
+1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to [zonegroup](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, Rook will fill this value accordingly. Please check example at the end of the doc.


Shall we mention the default here? Otherwise, I'm not sure what it means for Rook to "fill this value".

Suggested change

1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to [zonegroup](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, Rook will fill this value accordingly. Please check example at the end of the doc.

1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to [zonegroup](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, the default is `us-east-1`. Please check example at the end of the doc.

@travisn : I don't what I missed earlier if the user does not define the region, Rook will fill it from Zonegroup from ceph object store context and don't use us-east-1 at all(at least that was my first intention of PR).

us-east-1 is not the default value from RGW(at least not in RGW code base). It is a value that always works mysteriously. Maybe because a lot of s3 clients use this as default for region, but again not defined as default by RGW

Ok, does that mean rook can just take care of this internally? Why do we need to expose the region setting at all?

@travisn : The region defined in storage class of libbucket provisioner. Not sure whether Rook can hide it from user, maybe we can ignore the value. But this was available earlier release not sure whether it right to remove the variable. AFAIR I have sent #8766 as per request from the user, he wants to set the custom region for his use case.

travisn · 2022-03-07T18:46:03Z

deploy/examples/storageclass-bucket-delete.yaml

@@ -9,7 +9,7 @@ reclaimPolicy: Delete
 parameters:
   objectStoreName: my-store
   objectStoreNamespace: rook-ceph # namespace:cluster
-   region: us-east-1
+   # region: us-east-1


@thotz Since the default is us-east-1, should we just leave this default uncommented?

Suggested change

# region: us-east-1

region: us-east-1

travisn · 2022-03-07T18:46:18Z

deploy/examples/storageclass-bucket-retain.yaml

@@ -8,7 +8,7 @@ reclaimPolicy: Retain
 parameters:
   objectStoreName: my-store # port 80 assumed
   objectStoreNamespace: rook-ceph # namespace:cluster
-   region: us-east-1
+   # region: us-east-1


Suggested change

# region: us-east-1

region: us-east-1

travisn · 2022-03-07T18:53:33Z

tests/framework/clients/bucket.go

 	} else {
-		s3client, err = rgw.NewS3Agent(s3AccessKey, s3SecretKey, s3endpoint, "", true, nil)
+		s3client, err = rgw.NewS3Agent(s3AccessKey, s3SecretKey, s3endpoint, storeName, true, nil)


Why is the storeName used here, but the zonegroup is used in the example for using a different region? Shouldn't this use the zonegroup as well? Or in the test, the storeName and zonegroup are the same anyway?

Yeah this should be zone group, since we testing only internal ceph cluster without multisite, I just set directly storeName which is value of zonegroup as well

travisn · 2022-03-07T18:57:57Z

Documentation/ceph-object-bucket-claim.md

 1. `bucketName` is required for access to existing buckets but is omitted when provisioning new buckets.
 Unlike greenfield provisioning, the brownfield bucket name appears in the `StorageClass`, not the `OBC`.
 1. rook-ceph provisioner decides how to treat the `reclaimPolicy` when an `OBC` is deleted for the bucket. See explanation as [specified in Kubernetes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#retain)
 + _Delete_ = physically delete the bucket.
 + _Retain_ = do not physically delete the bucket.
+
+##### Example: Custom Region
+If user is providing the `region` value other than `us-east-1` then additional CRDs for zonegroup/zone/realm need to be created. For example, here user is providing `region` value as `us-west-1`. So make sure following [multisite related CRDs](ceph-object-multisite-crd.md) are defined as well. The Rook Operator will create required `zonegroup` for RGW server.


Suggested change

If user is providing the `region` value other than `us-east-1` then additional CRDs for zonegroup/zone/realm need to be created. For example, here user is providing `region` value as `us-west-1`. So make sure following [multisite related CRDs](ceph-object-multisite-crd.md) are defined as well. The Rook Operator will create required `zonegroup` for RGW server.

To specify a `region` other than `us-east-1`, a custom zone group must be created that matches the desired region name. In the following example, the `region` is set to `us-west-1`. For more details, see the [related multisite CRDs](ceph-object-multisite-crd.md).

BlaineEXE · 2022-03-07T22:19:55Z

pkg/operator/ceph/object/bucket/provisioner.go

+	if len(sc.Parameters[key]) > 0 {
+		p.region = sc.Parameters[key]
+	} else {
+		// If user does not define, then set region to Zonegroup, since RGW internally maps
+		// aws region to ZoneGroup
+		p.region = p.objectContext.ZoneGroup
+	}


I'm a little bit confused. What is the point of overriding region if the default is mapped to ZoneGroup and if the user has to create a ZoneGroup resource if they want to override region? Would it be simpler to just remove this parameter and rely on users to create a ZoneGroup instead?

Is this only useful if there are multiple zone groups? What happens in the case where there are multiple zone groups? Then what is the default?

@BlaineEXE : region is an optional value for storage-class. If it is not defined then we need to fill up with Zonegroup from object store context, This value changes in different scenarios:
1.) normal cluster, it is name of object store
2.) external cluster it is default
3.) if multiple zones are configured then it depends on value set in object-store CR.

If the user wants to use a custom region then he defines Zonegroup that's different scenario. Hope this avoids the confusion

In all three of those cases, I don't think we need to have the region parameter.

If external cluster with no zone group defined, use default

If external cluster with external zone group defined, use the zone group

If internal cluster with no zone group defined, use name of object store

If internal cluster with zone group defined, use the zone group

Is this not correct? Are there any cases missing?

@BlaineEXE : Please see #9754 (comment) why the region is needed.
Above cases are right, but please note 2.) is not support in Rook atm

BlaineEXE

If we can fill in a default value for "region" from the zone group, is region even a valid parameter?

BlaineEXE · 2022-03-07T22:23:11Z

Documentation/ceph-object-bucket-claim.md

  bucketName: ceph-bucket [4]
 reclaimPolicy: Delete [5]
 ```
 1. `label`(optional) here associates this `StorageClass` to a specific provisioner.
 1. `provisioner` responsible for handling `OBCs` referencing this `StorageClass`.
-1. **all** `parameter` required.
+1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to [zonegroup](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, Rook will fill this value accordingly. Please check example at the end of the doc.


Suggested change

1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to [zonegroup](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, Rook will fill this value accordingly. Please check example at the end of the doc.

1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to the [zone group](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, Rook will fill this value accordingly. Please check example at the end of the doc.

BlaineEXE · 2022-03-07T22:23:48Z

Documentation/ceph-object-bucket-claim.md

  bucketName: ceph-bucket [4]
 reclaimPolicy: Delete [5]
 ```
 1. `label`(optional) here associates this `StorageClass` to a specific provisioner.
 1. `provisioner` responsible for handling `OBCs` referencing this `StorageClass`.
-1. **all** `parameter` required.
+1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to [zonegroup](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, Rook will fill this value accordingly. Please check example at the end of the doc.


This is still not very clear. What is the region set to if the user doesn't define it? "Accordingly" isn't clear enough.

@BlaineEXE : earlier version was Rook Operato fill this value from object store context internally. But @travisn suggested it better not to give internal code details for the end-user. Hence changed like this. I can revert back the change

Even the text "fill this value from object store context internally" doesn't explain to the user what the value will be. In order for the user to understand when they need to modify the value, they must understand what the default value is. In words good for a user, what value will be the default?

This is also assuming that region is even a necessary parameter to have still.

Okay will update it again next push

BlaineEXE · 2022-03-07T22:24:12Z

Documentation/ceph-object-bucket-claim.md

  bucketName: ceph-bucket [4]
 reclaimPolicy: Delete [5]
 ```
 1. `label`(optional) here associates this `StorageClass` to a specific provisioner.
 1. `provisioner` responsible for handling `OBCs` referencing this `StorageClass`.
-1. **all** `parameter` required.
+1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to [zonegroup](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, Rook will fill this value accordingly. Please check example at the end of the doc.


Please add a link to the example in the doc for users.

BlaineEXE · 2022-03-07T22:24:56Z

Documentation/ceph-object-bucket-claim.md

 1. `bucketName` is required for access to existing buckets but is omitted when provisioning new buckets.
 Unlike greenfield provisioning, the brownfield bucket name appears in the `StorageClass`, not the `OBC`.
 1. rook-ceph provisioner decides how to treat the `reclaimPolicy` when an `OBC` is deleted for the bucket. See explanation as [specified in Kubernetes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#retain)
 + _Delete_ = physically delete the bucket.
 + _Retain_ = do not physically delete the bucket.
+
+##### Example: Custom Region
+If user is providing the `region` value other than `us-east-1` then additional CRDs for zonegroup/zone/realm need to be created. For example, here user is providing `region` value as `us-west-1`. So make sure following [multisite related CRDs](ceph-object-multisite-crd.md) are defined as well. The Rook Operator will create required `zonegroup` for RGW server.


Do users need to create all of the resources, or only zone group?

If I understand correctly zonegroup is not an independent resource. Rooks mandates to have realm for zonegroup and in RGW does not make sense to have zonegroup without zones (zonegroup is collection of zones and zone is collection of RGW servers in short)

alimaredia · 2022-03-07T23:00:17Z

@thotz I was taking at glance at this PR and I don't quite understand the use case/problem this is trying to solve, even after reading the doc changes. Could you summarize what the object-store/obc's couldn't do before this PR was written and what the PR solves?

thotz · 2022-03-08T06:31:30Z

@thotz I was taking at glance at this PR and I don't quite understand the use case/problem this is trying to solve, even after reading the doc changes. Could you summarize what the object-store/obc's couldn't do before this PR was written and what the PR solves?
@alimaredia : Please refer #9754 (comment) for details

thotz · 2022-03-08T06:32:44Z

@BlaineEXE @travisn : I have minor nits need to address in this PR. But before refreshing the PR I want to make sure everyone is on the same page

BlaineEXE · 2022-03-08T15:03:21Z

@BlaineEXE @travisn : I have minor nits need to address in this PR. But before refreshing the PR I want to make sure everyone is on the same page

It is still unclear what is wrong currently. The description in #9754 (comment) isn't quite enough for me to understand. Please be very clear about whether behavior is broken or not. Is there broken behavior? Can you make a test case that causes any failures? If yes, outline the failing case.
If we can't make a failing test case, then why are we making the code more complex? Wouldn't that mean the parameter is just unnecessary?

Once we understand what is wrong, we can do a much better job of reviewing the PR for behavior and usability and not merely code.

thotz · 2022-03-09T05:45:13Z

@BlaineEXE @travisn : I have minor nits need to address in this PR. But before refreshing the PR I want to make sure everyone is on the same page

It is still unclear what is wrong currently. The description in #9754 (comment) isn't quite enough for me to understand. Please be very clear about whether behavior is broken or not. Is there broken behavior? Can you make a test case that causes any failures? If yes, outline the failing case. If we can't make a failing test case, then why are we making the code more complex? Wouldn't that mean the parameter is just unnecessary?

Once we understand what is wrong, we can do a much better job of reviewing the PR for behavior and usability and not merely code.
@BlaineEXE : there are two commits in this PR :

replacing instance of us-east-1 with zone group of RGW server
document how to use custom region in storage class of OBC for the user

The second part is clear I guess. The reason for the why region is needed is explained in earlier replies

Now talking about the first part, most of the cases will work with current(i.e using us-east-1) but it is semantically correct to use zone-group instead.It is based on @cbodley's suggestion.
I have added a test case with the invalid region for the s3 client https://github.com/rook/rook/pull/9754/files#diff-5f2c0f5640c927aba71e73e05b71d0f3116c972f7e0f99a40c6e2b1a986b0431R210. EIther zonegroup or us-east-1 as the region for s3 client the request will succeed, so not sure whether it requires to have test cases based on it, If need I can add those as well

BlaineEXE · 2022-03-09T19:31:52Z

@BlaineEXE @travisn : I have minor nits need to address in this PR. But before refreshing the PR I want to make sure everyone is on the same page

It is still unclear what is wrong currently. The description in #9857 isn't quite enough for me to understand. Please be very clear about whether behavior is broken or not. Is there broken behavior? Can you make a test case that causes any failures? If yes, outline the failing case. If we can't make a failing test case, then why are we making the code more complex? Wouldn't that mean the parameter is just unnecessary?
Once we understand what is wrong, we can do a much better job of reviewing the PR for behavior and usability and not merely code.
@BlaineEXE : there are two commits in this PR :

replacing instance of us-east-1 with zone group of RGW server

document how to use custom region in storage class of OBC for the user

The second part is clear I guess. The reason for the why region is needed is explained in earlier replies

@thotz as I explained in the message you replied to, it is not clear to those of us trying to understand what is going on. Please summarize again, and be thorough. Several of us have concerns about this approach, and we need better information to make sure we are applying the correct fix for this.

Now talking about the first part, most of the cases will work with current(i.e using us-east-1) but it is semantically correct to use zone-group instead. It is based on @cbodley's suggestion.

From that discussion, it has become clear to me that there is something wrong with the region setting, but I am not confident that the current proposed changes are the best solution. I still want some sort of proof that simply removing the field as a configurable option isn't a better solution.

I have added a test case with the invalid region for the s3 client https://github.com/rook/rook/pull/9754/files#diff-5f2c0f5640c927aba71e73e05b71d0f3116c972f7e0f99a40c6e2b1a986b0431R210. EIther zonegroup or us-east-1 as the region for s3 client the request will succeed, so not sure whether it requires to have test cases based on it, If need I can add those as well

I should have been more clear. I am not interested in seeing a unit test. Unit tests cannot show the actual behavior of a running RGW. I want to see the details for creating an end-to-end scenario where there is a failure.

From the discussion linked, it seems that we are be able to induce some failure by setting region to some value other than us-east-1. If changing this value is the only way to induce a failure, then the right solution is probably to ignore the region option in Rook.

In order to determine if we need changes other than removing the value entirely, we want to need to have a failing scenario with region left unspecified (it gets its default value). If we can make this failing scenario, then we need better defaults (but we still may not need the region option).

Once we have better defaults, the question becomes: can we make another failing scenario (internal or external ceph cluster) such that we can't compute the default ourselves? If we can, then users will need an option to override region. If we can't then the updated computation is all we needed, and we can ignore the region setting.

BlaineEXE · 2022-03-09T20:17:47Z

This documentation for RHCS 3 states that the RGW now uses the terminology "zone-group" instead of "region". https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/object_gateway_guide_for_red_hat_enterprise_linux/rgw-multisite-rgw

Since Rook now has multisite configs zone/zonegroup/realm, I think we probably no longer need the "realm" option in the OBC storageclass. I think it's probably vestigial. I think that we likely only need to figure out what the zone group is and use that value.

My best guess at what a failing scenario would be is to :

Create a ceph cluster (cluster A) with an RGW using a non-"default" zone group
Create a Rook cluster in external mode (cluster B) whose CephObjectStore references cluster A, and do not set zone/zonegroup info.

I suspect this scenario will cause a failure because the S3 client in cluster B won't be able to connect properly to the RGW in cluster A since the zone group in cluster A is not "default". (This PR did some related work recently: #9751)

From the information I have, I think the most appropriate fix for this would be to make sure that creating a zone and zone group that reference the external cluster are created in cluster B. And we must also update docs and examples to remove the "realm" config.

@alimaredia has an open PR to better allow configuring zone/zonegroup endpoints for external clusters. I'm not sure if that PR is directly related to this discussion. #9622

@alimaredia does this breakdown make some sense to you?

thotz · 2022-03-14T11:30:11Z

After discussing with developers from Rook and RGW planning to close this PR infavour of #9906

leseb requested changes Feb 16, 2022

View reviewed changes

thotz force-pushed the remove-default-value-for-region-s3client branch from 572bbae to e8ba957 Compare February 17, 2022 06:53

thotz requested a review from leseb February 17, 2022 07:38

leseb added the backport-release-1.8 label Feb 17, 2022

travisn requested changes Feb 17, 2022

View reviewed changes

leseb requested changes Feb 17, 2022

View reviewed changes

pkg/operator/ceph/object/bucket/provisioner.go Show resolved Hide resolved

BlaineEXE requested changes Feb 17, 2022

View reviewed changes

thotz mentioned this pull request Feb 22, 2022

docs: Explain about region in storage class for OBC #9556

Closed

10 tasks

thotz force-pushed the remove-default-value-for-region-s3client branch 5 times, most recently from dcc908a to 238178d Compare February 22, 2022 13:55

thotz requested review from leseb, BlaineEXE and travisn February 22, 2022 14:31

travisn requested changes Feb 22, 2022

View reviewed changes

thotz force-pushed the remove-default-value-for-region-s3client branch from 1b7bcce to cd70ca5 Compare February 23, 2022 09:48

thotz requested a review from travisn February 23, 2022 09:57

travisn requested changes Feb 23, 2022

View reviewed changes

Documentation/ceph-object-bucket-claim.md Outdated Show resolved Hide resolved

Documentation/ceph-object-bucket-claim.md Outdated Show resolved Hide resolved

thotz force-pushed the remove-default-value-for-region-s3client branch from cd70ca5 to 380dd49 Compare February 24, 2022 06:26

thotz requested a review from travisn February 24, 2022 06:27

travisn requested changes Feb 24, 2022

View reviewed changes

thotz force-pushed the remove-default-value-for-region-s3client branch from 380dd49 to 89a7cbe Compare March 2, 2022 12:50

thotz requested a review from travisn March 2, 2022 12:50

thotz added 2 commits March 7, 2022 10:52

thotz force-pushed the remove-default-value-for-region-s3client branch from 89a7cbe to 5a2f5ad Compare March 7, 2022 05:24

travisn requested changes Mar 7, 2022

View reviewed changes

BlaineEXE reviewed Mar 7, 2022

View reviewed changes

BlaineEXE requested changes Mar 7, 2022

View reviewed changes

alimaredia self-requested a review March 7, 2022 22:52

thotz requested review from BlaineEXE and travisn March 8, 2022 06:31

thotz closed this Mar 14, 2022

	1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to [zonegroup](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, Rook will fill this value accordingly. Please check example at the end of the doc.
	1. `region`(optional) defines the region in which the bucket should be created. For RGW, this maps to [zonegroup](https://docs.ceph.com/en/latest/radosgw/multisite/#zone-groups) of the server. If user does not define `region`, the default is `us-east-1`. Please check example at the end of the doc.

	If user is providing the `region` value other than `us-east-1` then additional CRDs for zonegroup/zone/realm need to be created. For example, here user is providing `region` value as `us-west-1`. So make sure following [multisite related CRDs](ceph-object-multisite-crd.md) are defined as well. The Rook Operator will create required `zonegroup` for RGW server.
	To specify a `region` other than `us-east-1`, a custom zone group must be created that matches the desired region name. In the following example, the `region` is set to `us-west-1`. For more details, see the [related multisite CRDs](ceph-object-multisite-crd.md).

object: remove default value us-east-1 as region from s3 client #9754

object: remove default value us-east-1 as region from s3 client #9754

Conversation

thotz commented Feb 16, 2022 • edited

leseb left a comment

Choose a reason for hiding this comment

travisn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thotz Feb 22, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thotz Feb 24, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thotz commented Feb 21, 2022

travisn commented Feb 21, 2022

thotz commented Feb 22, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BlaineEXE Mar 7, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BlaineEXE left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alimaredia commented Mar 7, 2022

thotz commented Mar 8, 2022

thotz commented Mar 8, 2022

BlaineEXE commented Mar 8, 2022 • edited

thotz commented Mar 9, 2022 • edited by BlaineEXE

BlaineEXE commented Mar 9, 2022

BlaineEXE commented Mar 9, 2022

thotz commented Mar 14, 2022

thotz commented Feb 16, 2022 •

edited

thotz Feb 22, 2022 •

edited

thotz Feb 24, 2022 •

edited

BlaineEXE Mar 7, 2022 •

edited

BlaineEXE commented Mar 8, 2022 •

edited

thotz commented Mar 9, 2022 •

edited by BlaineEXE