Randomize object names to avoid clashes

[tripledes]

Feature: Randomize object names

What happened:

When deploying multiple instances of the same APB on the same namespace, some objects clash and deployment fails.

Having this situation handled by the broker in the same way other objects in Kubernetes/OpenShift are indexed, e.g. rc/<name>-1, rc/<name>-2, ... would improve developer/user experience.

What you expected to happen:

To be able to deploy same APB in the same namespace multiple times.

How to reproduce it:

Try to deploy multiple instances of the PostgreSQL APB.

[djzager]

Thank you for the issue @tripledes, there is a similar BZ https://bugzilla.redhat.com/show_bug.cgi?id=1542235

[tripledes]

@djzager Sounds pretty much the same. I've been looking at the code a bit and was wondering whether this is something that the broker should take care of as I haven't seen any interaction with such objects as those are defined at playbook level. Any thoughts?

[shawn-hurley]

I think we may need to wait for #809 before we can generate names. The names are set right now because the APB cannot keep track of a generated name for deprovision use case. If we can keep track of that state, then the APB can be updated to take advantage of this IMO.

[tripledes]

@shawn-hurley thanks, that confirms my assumptions.

[djzager]

I don't believe that the broker will be able to control how Bundles name objects. I believe this is something that will need to be addressed at the Service Bundle level. There are a couple of ways this can be done now:

1. Make the name of the objects a parameter to the Bundle, as I did in the hello-world-apb
2. Generate the name of the objects based on the _apb_service_instance_id. The only issue I had with doing it this way was that it was ugly (ie. hello-world-1234-5678-9abcd).

Once, #809 is merged, then we could be even more clever and generate names like superb-owl and use that name throughout the instances lifecycle.

[tripledes]

@djzager Thanks, that also clarifies things.

I'm helping with the mssql-apb and I got to the same options you mentioned but before using either of those two, I wanted to see whether this would be a temporary workaround or permanent. I guess we'll take the _apb_service_instance_id direction.

[djzager]

The way this is handled in the hello-world-apb is by having something like:

apb_name: hello-world
name: "{{ apb_name }}-{{ _apb_service_instance_id }}"

then using the name for the k8s/openshift objects created by the hello-world-apb.

In the end, I do not believe that it is the broker's responsibility to worry about the names of objects created by a particular bundle. If an APB (or Service Bundle) developer wants multiple instances of their bundle in a single namespace to be supported, they will need to make the necessary changes. However they elect to support that behavior is up to them. We recommend using the _apb_service_instance_id or generateName when #809 is introduced.

[tripledes]

@djzager regarding responsibilities, agreed, as long as there's a way for developers to generate different object names, it'd be fine. Thanks.

[djzager]

Since we (in this case the broker) is providing a means for uniquely identifying objects being managed by a particular APB (via _apb_service_instance_id) I think this can be closed.