Service binding supporting deployment config

[wtrocki]

What this does

We are adding deploymentConfig support by extra flag.

Why flag instead of showing both?
Deployment config is typically problematic with binding (extra rollouts are needed and we cannot make sure that binding will be valid). We needed to provide extra documentation etc. to support that - adding it by default will cause confusion and problems.
It will also break our existing guides :/

Notes

This change doesn't introduce any multiservice aritecture.
This is going to be done in separate feature branch done by @rkpattnaik780
I have prepared layer for that refactoring but we need to work on top of the changes that Rama has right now.

Verification

[wtrocki@graphapi app-services-cli (support-bind ✗)]$ rhoas cluster bind --deployment-config 
? Select Kafka instance to connect: pete
Namespace not provided. Using wtrocki namespace
? Please select application you want to connect with example
Binding "pete" with "example" app
? Do you want to continue? Yes
Using ServiceBinding Operator to perform binding
✔️ Binding pete with example app succeeded

[wtrocki]

WIP. FYI @rkpattnaik780

[wtrocki]

@craicoverflow just review needed. Verification not possible - SBO operator seems to be broken

[craicoverflow]

Wasn't v0.10.0 announced? Maybe that could resolve it.

[wtrocki]

0.10.0 is actually the version of the cluster that breaks things.
0.10.0 also doesn't seem to compile redhat-developer/service-binding-operator#1022

I have verified this for deployment config. So service binding is created and command works.
but we cannot verify this end to end. I think we should merge this knowing that command works as it should

[craicoverflow]

LGTM

[craicoverflow]

Suggested change

	return localizer.MustLocalizeError("cluster.serviceBinding.operatorMissing", localize.NewEntry("Error", err))
	return localizer.MustLocalizeError("cluster.serviceBinding.operatorMissing", localize.NewEntry("Error", err))

Passing in the err object to localizer wil convert it to a string, and you cannot do any casting/type checking of the error from thereon in. It's recommended to preserve the error object.

[wtrocki]

we discussed that yesteday that we going to map errors specifically for providing more reliable info.
So we should probably:

• Log error that we recognize
• Return error to be printed again with more generic/non i18n content

[craicoverflow]

Yes - in the commands it makes sense to map errors and preserving the error object does not matter too much. However in an SDK scenario (like this one) I think it is important to preserve it because the place it is being used is able act different based on the error type.

[wtrocki]

In this case error will be cryptic - 404 kafka API doesn't exist or missing auth token. Do you suggest to return original error only?

[craicoverflow]

No it can be wrapped like this:

return fmt.Errorf("your reason: %w", err)

%w means wrap the error.

[rkpattnaik780]

The error messages need formatting at the last line.

Also for the latter error message, not sure if it was expected to fail, I could do a bind after it.

[wtrocki]

@rkpattnaik780 That is mostly because of logic - it lets you to select kafka that you do not have on the cluster.
I have left comment to solve that problem - once we move to binding we should read Kafka and Registry connections from cluster and specify their names instead of reading them from backend

[wtrocki]

Blocked by:
redhat-developer/service-binding-operator#1025

My quess is that we going to merge and release it so we can rebase and continue refactoring it for multiservice architecture