Bulk share re-apply UI for a dataset

[TejasRGitHub]

Is your idea related to a problem? Please describe.
Currently, in data.all, when you go to datasets -> shares , a user can use the "Verify Share Object Health Status" button to start verification of share happening via data.all. This helps to bulk verify all the shares but for all the shares which are failing, each individual share has to be visited and share has to be re-applied for each failing share. This becomes cumbersome for the dataset owner who wants to fix all the shares

Describe the solution you'd like

Add a button on the UI which would re-apply shares for a particular datasets,

UI Changes -

1. Add a button adjacent to the share verify button which will be visible/clickable when you have failed shares for that dataset.
2. Add a column in the shares view list on the dataset to inform user if the share is healthy or unhealthy. If a icon is added, please add a tooltip to inform the user what the icon is representing
3. As the share reapply works on the ECS , create a polling mechanism which will find if the ECS task running to fix the broken shares on a dataset is has completed and what shares have been fixed

Backend Changes

1. graphQL endpoint to re-apply shares for a dataset. GraphQL endpoint will take the dataset URI as the input and re-apply all shares which are in broken state for this dataset.
2. Another graphQL endpoint to poll and get the status of the shares health state.
3. ECS task which will be running on a schedule to re-apply all the broken shares. Creation of this ECS task could be made configurable based on a config in cdk.json like enable_share_repply_ecs_task. Also, instead of having another ECS task the ECS share verifier can be modified to add the logic to re-apply shares ( here work from Add share_reapply task - ON DEMAND for data.all admins #1151 ) can be used

Question for disscusion -

1. Who should be able to reapply shares on a dataset ? Should it be only the dataset owner ? Or should requesters who have access to this dataset have permissions to reapply shares ?
2. Should there a reapply and fix broken shares on an environment level ?

[TejasRGitHub]

Proposed UI changes for Bulk Share Re-apply.

[zsaltys]

The unhealthy filter is useful.. But I think for first iteration to get this out quicker let's start without it.

The showing healthy/unhealthy could also be a separate feature because we don't have this on share UI even.. Though I suspect this UI is reusing the shares UI component? Definitely super useful though. I would do it with two separate issues.

For nowe we could get away with just re-apply share objects.

[anushka-singh]

Agree with Zi on this. Lets have just the re-apply button for now.

[TejasRGitHub]

Hi @zsaltys , @anushka-singh , Thanks for the suggestions and comments.

For now, in order to quickly get this feature out , I am limiting the UI to only the Share Re-apply button.

Here's the mockup for the UI

Frontend Changes

1. Add button into the ShareBoxList component in the dataset view
2. graphQL services file to call backend graphQL process

Backend Changes

1. mutation graphQL endpoint in the s3_dataset_shares/api
2. Connecting this graphQL to the ECS task already present ( share-reapplier task). This graphQL endpoint will call this ECS task by using the Ecs.run_task method ( already present in core/stacks/aws/ecs.py file)
3. Add ECS task ARN and container name in the SSM parameters during the deployment in the container.py file for task - share reapplier - so that it can be accessed while calling the Ecs.run_task method.

Why are we calling the ECS task and not creating a worker queue entry ( with the task object ) ?

Although the standard flow in data.all for graphQL calls is to create a worker queue entry ( SQS Queue ) and then this calls the aws worker lambda which ultimately starts the ECS task, this flow does suffer when there are a lot of share reapplies on the same dataset. The dataset locking mechanism does the job of making sure that each task doesn't override others work. But since there are multiple tasks, the dataset locking mechanism timeouts certain tasks and thus the reapply doesn't happen.

To avoid this, directly calling the ECS task which calls the SharingService.reapply_share service synchronously and waits for each share reapply to get completed.

Questions -

1. Who should be able to reapply shares on a dataset ? Should it be only the dataset owner ? Or should requesters who have access to this dataset have permissions to reapply shares ?

Future Changes / Enhancements -

1. Add a pooling logic which will check and provide status of whether the ECS task has completed or not.
2. Add UI filter to filter on Healthy/ Unhealthy shares at all places where the shares are filtered.
3. Add a column in the share list view and show by some visual graphic if the shares are healthy / unhealthy

[anushka-singh]

@TejasRGitHub Thanks for coming up with the design. I am aligned on the placement of the button on the UI next to verify shares bulk apply.

Questions -

1. Who should be able to reapply shares on a dataset ? Should it be only the dataset owner ? Or should requesters who have access to this dataset have permissions to reapply shares ?

• Reapplying shares should be a privilege exclusive to dataset owners. This is because reapplying shares operates at the dataset level, whereas requesters typically have access to specific shares within a dataset. Granting requesters the ability to reapply shares could lead to unintended consequences and complexities in managing dataset-level permissions.

[zsaltys]

@TejasRGitHub is the new approach calling SharingService.reapply_share will still lock the dataset to make sure nothing else is running?

[TejasRGitHub]

Hi @zsaltys , yes, the locking mechanism is implemented inside the ShareService.reapply_share so it would still work

[noah-paige]

This issue is complete as of #1363 - thank you @TejasRGitHub for your quick help implementing the above!

I will close this issue EOD today unless any additional concerns

[TejasRGitHub]

Hi @noah-paige, Thanks for merging the PR. I am adding few follow-up items for this issue. This GH issue can be closed now

Adding these as follow up issues -

1. Add pooling / webhook similar logic for places where status updates occur ( e.g. stacks, share verification, reapply, etc)  #1377
2. Add UI filter to filter on Healthy/ Unhealthy shares at all places where the shares are filtered. #1378

[noah-paige]

Sounds good - thanks for opening these 2 new issues @TejasRGitHub, closing this one as complete