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
Pass provision credentials to the deprovision playbook even if APB is not bindable #818
Comments
|
But when we want also same fields available in deprovision phase e.g. |
|
This can be assigned to me |
|
I am still hitting this issue with the |
|
This is actually due to the fact that the broker does not pass these credentials to the broker unless you make |
|
I would expect the broker to always run the |
|
This seems reasonable to pass an empty value but always pass the arg. 👀 |
|
Although it does raise the question of whether this should be the case for all arguments. As in we will always pass a certain set of arguments even if there is no value for them |
|
Perhaps something like |
|
https://github.com/dymurray/depro-creds-apb Made a functioning example of using a configmap to pass this data between provision/deprovision as a workaround. |
Feature:
Not sure if this is a feature or a bug, but putting it under feature at the moment.
As part of a provision or binding, we create certain resources within the application (think a realm and user in keycloak for example)
We have a usecase that developers may not want to provision a new instance of a service like keycloak every time. So we allow developers to specify using an existing keycloak as part of the provision. In this case the playbook will not create new pods etc but instead just create the new realm and user and drop the details into the credentials.
When deprovisioning, we need to access these credentials so that we can tear down the resources we created within the service as in this case the original keycloak server will remain running.
Solution
Pass through the any extracted credentials created at provision time to the deprovision action.
I happy to provide a PR for this.
The text was updated successfully, but these errors were encountered: