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

Allow for resource deletion #615

Closed
brokad opened this issue Feb 6, 2023 · 4 comments
Closed

Allow for resource deletion #615

brokad opened this issue Feb 6, 2023 · 4 comments
Assignees
Labels
Contribution Wanted The community is welcome to collaborate on this issue S-Accepted This will be worked on T-Improvement Improvement or addition to existing features

Comments

@brokad
Copy link
Collaborator

brokad commented Feb 6, 2023

Currently there is no way to delete a resource attached to a deployment (such as a database that was provisioned from an annotation to the shuttle_service::main function). We'd like to expose such functionality so that resources attached to services can be removed imperatively from the CLI with a command such as cargo shuttle resource delete {resource-name}.

For this we need a change to provisioner to write the deletion logic and expose the methjod through gRPC, then a change to deployer to write the deletion logic (calling provisioner) and checking for the sanity of the operation (is a running service using it?) and expose the API through handlers, and then finally a change to cargo-shuttle which exposes the command to the CLI.

@brokad brokad added T-Improvement Improvement or addition to existing features Contribution Wanted The community is welcome to collaborate on this issue labels Feb 6, 2023
@MrCoolTheCucumber
Copy link
Contributor

Hey, I think I can try to tackle this! I have an initial question though:

resources attached to services can be removed imperatively from the CLI with a command such as cargo shuttle resource delete {resource-name}

Looking at the schema in deployer/migrations/... it doesn't seem like resources currently have names? Is this something that will need to be added? Or will the resource name be some sort of "composed" name based on other information such as for example "{service_name}-{resource_type}"? (Though I guess that would only work if its assumed that only one of each resourse type can exist)

@brokad
Copy link
Collaborator Author

brokad commented Mar 2, 2023

For this we need a change to provisioner to write the deletion logic and expose the methjod through gRPC, then a change to deployer to write the deletion logic (calling provisioner) and checking for the sanity of the operation (is a running service using it?) and expose the API through handlers, and then finally a change to cargo-shuttle which exposes the command to the CLI.

For whoever is stumbling upon this, #622 implemented the required provisioner changes, but left out the needed deployer and client-side changes.

@kierendavies
Copy link
Contributor

@MrCoolTheCucumber Is it cool with you if I take the remaining work here? Do you have any info or WIP to share before I do?

@MrCoolTheCucumber
Copy link
Contributor

@MrCoolTheCucumber Is it cool with you if I take the remaining work here? Do you have any info or WIP to share before I do?

Yeah of course you can! I started writing the handler but found it hard figuring out how exactly to call the RPC method within the handler. I dont think I have the changes stashed anymore though unfortunately.

@jonaro00 jonaro00 added the S-Accepted This will be worked on label Aug 17, 2023
@jonaro00 jonaro00 closed this as completed Nov 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Contribution Wanted The community is welcome to collaborate on this issue S-Accepted This will be worked on T-Improvement Improvement or addition to existing features
Projects
None yet
Development

No branches or pull requests

4 participants