Fh 4242 generic bind to allow 3scale and others

[maleck13]

First pass at using the binding api plus pod presets (no doubt failing build right now). This is the first part of two. The second part will be adding in support for 3scale and removing the pod presets from code and into the bind unbind playbooks.

Goes along with https://github.com/feedhenry/keycloak-apb/pull/14

I wanted to get eyes on it earlier rather than later.

The idea behind these changes is unifying us as using the bind API to do the work when we want to enable an integration.

Currently the ui for the bind api does not support parameters. In the future we may move the binding code out of the server all together and into the UI and cli depending on what makes sense.

[maleck13]

@philbrookes I have added creating pod presets in here as the alpha version in SC seems to be changing. I thought it might be a good idea to add the pod preset to the bind apb, however that can cause a timing issue: The apb hasn't launched or created the pod preset, and so we don't really know when to redeploy the deployment. We can change the behaviour to say "ok redeploy your service now" but I think allowing it to be auto redeployed once the change is ready is useful. I don't think the apb should be doing anything with the deployment config of the service, so, in my mind, that rules out the apb re deploying. Another option would be watch from mcp for when the pod preset gets created and redeploy the service then.

[maleck13]

Currently this breaks the App API Key integration

[maleck13]

@philbrookes API Key integration issue solved. However this does now break cross namespace integrations. I think this is ok currently as not a main feature of the POC and something we wanted to revisit anyway. I think we should be using the bind and provision apb actions to allow for cross namespace bindings.

Short example: sync in namespace A keycloak in namespace B There is a service instance in namespace B Need to provision to namespace A without creating a new keycloak (ie give it the details of the one in namespace B) That will give us a service instance in each namespace but only one actual service next we call bind, it takes a secret name to look up it looks up the secret and gets the credentials that were created during the provision and does the binding for either namespace against the same keycloak.

More to discuss but I think this is a better option.