Process incomplete bucket creation #434

New issue

Closed

opened 2024-07-18 12:12:47 +00:00 by alexvanin · 2 comments

alexvanin commented

2024-07-18 12:12:47 +00:00

Owner

Bucket creation may be interrupted or cancelled during asynchronous container creation. Therefore container will persist, but there would be no policy nor bucket settings for the bucket.

If error happens during policy setup or tree update, then gateway should delete previously created container.

Optionally consider this optimization: on create-new-bucket if container is already exists, gateway may decide to continue setting policy and tree data without returning an error. This should happen only if gateway knows for sure that this is an new container with no settings nor policies.

Bucket creation may be interrupted or cancelled during asynchronous container creation. Therefore container will persist, but there would be no policy nor bucket settings for the bucket. If error happens during policy setup or tree update, then gateway should delete previously created container. Optionally consider this optimization: on `create-new-bucket` if container is already exists, gateway may decide to continue setting policy and tree data without returning an error. This should happen only if gateway knows for sure that this is an new container with no settings nor policies.

dkirillov commented

2024-07-19 06:56:30 +00:00

Member

If error happens during policy setup or tree update, then gateway should delete previously created container.

We should take into account that we don't have session token for removing container in AccessBox

> If error happens during policy setup or tree update, then gateway should delete previously created container. We should take into account that we don't have session token for removing container in AccessBox

alexvanin commented

2024-09-24 09:01:46 +00:00

Author

Owner

We should take into account that we don't have session token for removing container in AccessBox

While this is true, assume that all tokens are present. Authmate and others token generating services usually grant rights for both bucket creation and deletion.

I suggest at the first step try to delete container anyway. This should cover most of cases.

Then we can modify this code furthermore: if container is already exist, then try to re-apply policies. I will create separate issue for this case.

> We should take into account that we don't have session token for removing container in AccessBox While this is true, assume that all tokens are present. Authmate and others token generating services usually grant rights for both bucket creation and deletion. I suggest at the first step try to delete container anyway. This should cover most of cases. Then we can modify this code furthermore: if container is already exist, then try to re-apply policies. I will create separate issue for this case.