Limit the bucket creation with empty location constraint to master zonegroup (basically defaulting the location to the master zonegroup)

is this really what we want? i tend to think it should default to the zonegroup that issued the CreateBucket request. if the master zonegroup owns it instead, then the issuing zone/zonegroup would have to forward all object operations to the master zonegroup. in that case, the client would lose any benefits of locality with its local zone/zonegroup

cc @smanjara @mattbenjamin

p.s. i reworked some of the forward_request_to_master logic in #50599. just a heads-up that we'll likely see conflicts in RGWCreateBucket::execute

@cbodley With the definition of AWS for the default region, this would make sense to have a default region and if the LocationConstraint was empty - pick the default one for it.
The same applies to GetBucketLocation API when the location is the default region (https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketLocation.html#AmazonS3-GetBucketLocation-response-LocationConstraint).

I would say this would make sure to the clients that they are asking for the right location rather than picking the location that they are requesting as an endpoint (maybe by fault?).

@cbodley I couldn't follow what you meant by forwarding the request to the master. The main idea of this from my PoV was the thing I mentioned in my comment above (bucket creation and...). Are you talking about any more corners here?

With the definition of AWS for the default region, this would make sense to have a default region and if the LocationConstraint was empty - pick the default one for it.

@clwluvw in rgw multisite, the master zonegroup is authoritative for bucket/user metadata, but failover may change which zonegroup is the master. i'm not sure it makes sense to think about the master zonegroup the same way you think about a default region in aws

s3 clients/applications don't need to be aware of rgw's zonegroups at all, they just need to know the address of an http endpoint. generally they'll run some workload that creates a bucket and operates on objects in it. i think it would be unexpected if that whole workload gets redirected to a remote zonegroup instead

clients that do know about the rgw zonegroups have full control over the placement of their buckets via LocationConstraint. but in the absence of a location, making the local zonegroup the bucket owner seems like the obvious choice

I couldn't follow what you meant by forwarding the request to the master.

@clwluvw i was only pointing out that another PR moved around some of the same code that you're touching here

@cbodley That pretty much makes sense - Also I was worried about if we want to follow the same concept then how are we going to deal with null in the API I mentioned cause the SDKs are forced eu-east-1 for that so it wouldn't make sense if the "default" is something else. I dropped the change for that.

Regarding the PR you mentioned, I guess the conflict point in the implementation I proposed is still there:

  // validate the LocationConstraint
  if (!location_constraint.empty() && !relaxed_region_enforcement) {
    // on the master zonegroup, allow any valid api_name. otherwise it has to
    // match the bucket's zonegroup

Basically, I think it's better to check the LocationConstraint if the zonegroup is master as well otherwise the user might though it requested another zonegroup on the wrong HTTP endpoint and it gets 200 as a result and so the thought would be the bucket was placed in the zonegroup in bucket create request but the actual is not. What do you think?

ping @cbodley

This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved

This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved

Reproduction:

1. Have two zonegroups (assuming A as a master zonegroup and B as a secondary zonegroup)
2. Send a CreateBucket Request to the "zonegroup A endpoint" with the following payload:

<CreateBucketConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> 
    <LocationConstraint>B</LocationConstraint> 
</CreateBucketConfiguration >

Results in bucket creation in zonegroup A without any error.

This is a client error as the user is asking to create the bucket in zone B but requesting to zonegorup A.
Doing that in the opposite way (request to zonegroup B with <LocationConstraint>A</LocationConstraint>) would result in 4xx as the endpoint would not match the requested LocationConstraint. But in the way I said - it results in 2xx and bucket creation in the master zonegroup (zone A - requested - but not asked) because of the if clause here: https://github.com/ceph/ceph/pull/52791/files#diff-319900fb50bdb02677039fb81949243b9c0e7d98690f6fddf35e6ca5d5d52b2cL3314

The PR will fix the if clause and check whether the zonegroup is master or not so the above example would result in 4xx as well.

This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

This pull request has been automatically closed because there has been no activity for 90 days. Please feel free to reopen this pull request (or open a new one) if the proposed change is still appropriate. Thank you for your contribution!

jenkins test make check

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

jenkins test submodules

jenkins test windows

<CreateBucketConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> 
    <LocationConstraint>B</LocationConstraint> 
</CreateBucketConfiguration >

Results in bucket creation in zonegroup A without any error.

i would hope that #59960 will cause this bucket's creation to set the correct RGWBucketInfo::zonegroup to zonegroup B, even though it was created on zonegroup A

i would hope that #59960 will cause this bucket's creation to set the correct RGWBucketInfo::zonegroup to zonegroup B, even though it was created on zonegroup A

I don't think so as when you are master you will ignore the location_constraint in the body but the rgwx-zonegroup is playing the role now and letting the bucket be created for the correct zonegroup. so if you request directly to the master zonegroup to create a bucket for zonegroup B it won't work as it is still ignoring the body.

i would hope that #59960 will cause this bucket's creation to set the correct RGWBucketInfo::zonegroup to zonegroup B, even though it was created on zonegroup A

I don't think so as when you are master you will ignore the location_constraint in the body but the rgwx-zonegroup is playing the role now and letting the bucket be created for the correct zonegroup. so if you request directly to the master zonegroup to create a bucket for zonegroup B it won't work as it is still ignoring the body.

thanks. would something like this be reasonable?

if (location_constraint) {
  bucket.zonegroup = api_name_to_zonegroup_id(location_constrant);
} else if (rgwx_zonegroup) {
  bucket.zonegroup = rgwx_zonegroup; // default to requesting zonegroup
} else {
  bucket.zonegroup = local_zonegroup_id; // default to local zonegroup
}

jenkins test make check arm64

passed qa in https://pulpito.ceph.com/cbodley-2025-01-08_19:44:28-rgw-wip-69281-distro-default-smithi/ (batched with #59960)