Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(storage): mark preserve_acl as deprecated #9518

Closed
wants to merge 5 commits into from

Conversation

emar-kar
Copy link
Contributor

Closes: #9482

As was asked in the comments, argument preserve_acl marked as deprecated.

@emar-kar emar-kar added type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. api: storage Issues related to the Cloud Storage API. labels Oct 23, 2019
@emar-kar emar-kar self-assigned this Oct 23, 2019
@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Oct 23, 2019
@emar-kar emar-kar marked this pull request as ready for review October 23, 2019 07:36
@tseaver tseaver added the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Oct 24, 2019
new_blob.acl.save(acl={}, client=client)
if preserve_acl is not None:
warnings.warn(
"The 'preserve_acl' argument is deprecated. Please update the bucket's ACL manually.",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't "deprecation": we are changing the behavior, and emitting a warning. If we are going to deprecate the argument, then we should preserve the existing behavior, and emit an explicit deprecation, e.g.:

        if preserve_acl is not None:
            warnings.warn(
                "The 'preserve_acl' argument is deprecated.  For forward compatibility, "
                 "please update the blob's ACL manually.",
                 DeprecationWarning,
                 stacklevel=2,
            )
        if not preserve_acl and preserve_acl is not None:
            new_blob.acl.save(acl={}, client=client)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do that then, the warning will always be emitted. I think the change makes sense. Otherwise we can do a soft deprecation and only mark it in documentation.

SOURCE, BLOB_NAME, DEST, NEW_NAME
source.copy_blob(blob, dest, NEW_NAME, client=client, preserve_acl=False)
mock_warn.assert_called_once_with(
"The 'preserve_acl' argument is deprecated. Please update the bucket's ACL manually.",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't assert the warning message (it also happens to be incorrect, as the ACL is for the blob, not its bucket).

@tseaver
Copy link
Contributor

tseaver commented Oct 24, 2019

ISTM that we could make the preserve_acl argument actually work, rather than deprecating it, by passing the ACL in the body of the objects.copy request, as suggested in the docs.

@frankyn
Copy link
Member

frankyn commented Nov 8, 2019

@tseaver just closing the loop, as noted in the reference issue, let's not copy the ACL for the user. Instead it would be better for the user to supply blob metadata that can be used in the copy request. It's a clear opt-in.

Let's deprecate this field and instead look at introducing acl= parameter a user can set in a subsequent PR?

@tseaver
Copy link
Contributor

tseaver commented Nov 11, 2019

@frankyn Seems like we should provide a mechanism for copying any properties into the new blob. Maybe the most elegant would be to add a new method to Blob, copy_from. The usage would be:

source = source_bucket.blob('source-name')
dest = dest_bucket.blob('dest-name')
dest.content_type = source.content_type
# Copy other properties here?
dest.copy_from(source, copy_acl=True)

@frankyn
Copy link
Member

frankyn commented Nov 11, 2019

This exact question came up in Ruby, short update:

The GCS API will copy a subset of metadata from the object on copy or rewrite (excluding ACL's).
As long as the body doesn't include metadata for the object then GCS copies the metadata.
One issue is if the user wants to provide metadata for the copied object, then GCS will not copy the source metadata.

I like the example:

source = source_bucket.blob('source-name')
dest = dest_bucket.blob('dest-name')
dest.content_type = source.content_type
# User Modifies ACLs and copy_from only uses source for its media. 
dest.copy_from(source) 
# no additional parameters here "unless" the user wants to copy over existing metadata in the same way GCS does. We did this in Ruby using a flag force_metadata_copy to respect GCS behavior when a resource is provided. Otherwise, only the metadata provided on the copy/rewrite will be kept. 

@emar-kar
Copy link
Contributor Author

@frankyn So, the question is that we need probably separate those tasks. First, deprecate preserve_acl. In this question, I'm voting for the deprecation warning. I think users need to see that this argument is not affecting ACL of the new blob to avoid misunderstandings and incorrect behavior. Secondly, open a FR issue to add a new method to copy source data.

@plamut
Copy link
Contributor

plamut commented Feb 10, 2020

Please reopen in the new repo, if this PR is still on track, thanks!

@IlyaFaer IlyaFaer closed this Feb 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: storage Issues related to the Cloud Storage API. cla: yes This human has signed the Contributor License Agreement. do not merge Indicates a pull request not ready for merge, due to either quality or timing. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants