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

Pass provision credentials to the deprovision playbook even if APB is not bindable #818

Closed
maleck13 opened this issue Mar 6, 2018 · 9 comments · Fixed by #821 or #881
Closed

Pass provision credentials to the deprovision playbook even if APB is not bindable #818

maleck13 opened this issue Mar 6, 2018 · 9 comments · Fixed by #821 or #881
Assignees
Labels
3.10 | release-1.2 Kubernetes 1.10 | Openshift 3.10 | Broker release-1.2 feature

Comments

@maleck13
Copy link
Contributor

maleck13 commented Mar 6, 2018

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.

@vchepeli
Copy link

vchepeli commented Mar 6, 2018

_apb_provision_creds is available when we do binding/unbind phase

asb_encode_binding:
  fields:
    name: "<some-name>"
    resource: "some-resource"
    uri: "<some-url>"

But when we want also same fields available in deprovision phase e.g. _apb_provision_creds.name it says _apb_provision_creds is undefined

@maleck13
Copy link
Contributor Author

maleck13 commented Mar 7, 2018

This can be assigned to me

@dymurray
Copy link
Member

I am still hitting this issue with the canary broker image. I am reopening this issue to track. I can also confirm that folks on the Cloudforms team have tested with canary as well and are unable to access _apb_provision_creds.

@dymurray dymurray reopened this Mar 28, 2018
@dymurray
Copy link
Member

This is actually due to the fact that the broker does not pass these credentials to the broker unless you make bindable True in apb.yml. We should be passing in the provision creds at all times so I am going to change this issue to reflect it.

@dymurray dymurray changed the title pass provision credentials to the deprovision playbook Pass provision credentials to the deprovision playbook even if APB is not bindable Mar 29, 2018
@dymurray
Copy link
Member

I would expect the broker to always run the GetExtractedCredentials function (Or maybe GetBind?) and if it doesn't find credentials, simply pass an empty object for _apb_provision_creds to deprovision.

@maleck13
Copy link
Contributor Author

This seems reasonable to pass an empty value but always pass the arg. 👀

@maleck13
Copy link
Contributor Author

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

@maleck13
Copy link
Contributor Author

Perhaps something like

// EnsureDefaults returns the default set of parameters with default values
func (p Parameters) EnsureDefaults() {
	if _, ok := p[ProvisionCredentialsKey]; !ok {
		p[ProvisionCredentialsKey] = nil
	}
}

@dymurray
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.10 | release-1.2 Kubernetes 1.10 | Openshift 3.10 | Broker release-1.2 feature
Projects
None yet
4 participants