-
Notifications
You must be signed in to change notification settings - Fork 42
Extension concept for cloud-provider specific operations #208
Comments
@danielfoehrKn Can you assign this to me? |
@danielfoehrKn I would like to confirm the high-level work flow with you before I get started. So, for example the gardenctl aws extension provider would be in it's own github repo "gardenctl-extensions" with all the other cloud related ext providers, building it would produce "gardenctl-ext-provider-aws.so" shared object library file where the interface method forceCleanupInfrastructure(String vpcId) would exist where as we would load that module on runtime and call that method if we are manipulating a shoot on aws and calling gardenctl to request a forceDeleteShoot operation? |
I think we should get together with other gardenctl maintainers to decide wether this is something that should be worked on in the first place, when, and generally how it could look like..
|
regarding stability issue for I used to be investigated on that In my case
However, the issues not occurred all the time. besides, after testing it takes a long time waiting for instance-status pass before use bash
|
PR for #231 @danielfoehrKn
|
Hi @jfortin-sap , as after discussion we opened several sub-tasks to break down this issue, shall we close this central one or you would like to use this issue to track feature implementation? |
I think we can close this issue |
/close |
Gardener has an extensibility concept, allowing cloud-provider specific tasks, to be developed independent of the Gardener core repository.
Similarly, it would be nice if
gardenctl
would offer a concept wheregardenctl
would define an interface with operations that plugins can implement to provide support for a specific cloud-provider.Plugins could be vendored from the
gardener-extension
& added atcompile time
or possibly even registered at runtime.Cloud-provider specific operations could be (not exhaustive list)
forceCleanupInfrastructure(String vpcId)
.This can be helpful
Let's take the operation
cleanupInfrastructure(String vpcId)
as an example:In Gardener, the Shoot infrastructure is created and destroyed by the
provider-extension
- see provider-aws for aws. Each provider can create the infrastructure with any suitable approach e.g for AWS theprovider-aws
uses terraform underneath, the vSphere provider uses thevSphere
API directly via a client SDK.Each provider would then also implement the interface method
forceCleanupInfrastructure(String vpcId)
that forcefully deletes all Shoot created resources + the VPC. The actual implementation is again provider specific. For instance for AWS, it could use the AWS API to check for all relevant resources (Elastic Ips, ec2 instances, ACL, NatGateway, SecuritGroups,...) and delete each single one of them, independent of the resource being created by Gardener or the Shoot owner.Other ideas
Additionally these plugins could be combined with high-level
gardenctl
operations such asforceDeleteShoot
. This operation would thenforceCleanupInfrastructure()
plugin for the target cloud-providerThe text was updated successfully, but these errors were encountered: