Adding annotation to help discovery

[arthurdm]

This PR adds an annotation into bindable resources, allowing tools to quickly discover them and making it easy to create ServiceBinding CRs.

[arthurdm]

CC @sbose78

[sbose78]

Thanks, reading.

[sbose78]

I was thinking we need to have this information at a higher level, example, at the bundle level? Of course, if a bundle doesn't exist for a CRD, then it could be at the CRD level.

[arthurdm]

interesting @sbose78 - do you have some examples of the bundles and how we could annotate them?

[sbose78]

Haven't got around thinking this through yet, thinking out aloud:

• A category in the CSV : we could propose a specific new category called "Developer service" in the pre-defined list of categories ?
• And/Or, have something in the CRD too ( for non-OLM operators )?
• Semi-related: have something in the helm chart's chart.yaml if it provides us a specific kind of service.

And, then we encourage every "developer service" irrespective of where they come from to have binding metadata in it in the form of CSV descriptions and/or CRD annotations.

Usage

odo wil then be able to list only these in odo services list , and so will other tools which have a flow where you

1. deploy a Node app, ( and ..Now your are looking to connect something to it ? )
2. This is where you could query "everything helm or installed operators" which has the metadata "developer service"

[arthurdm]

my concern with placing this in a higher level is that these services may have not been provisioned yet. In other words, you need a KafkaCluster CR in other to bind to it, not just to discover its Kafka CRD. That was the rationale for adding servicebinding/bindable: "true" in the bindable-and-provisioned CR - so it's a list of "what can I bind to right now".

Unless we're saying that we want to list all possible (present and future) bindable services, and odo would do the provisioning as part of odo link?

[sbose78]

we want to list all possible (present and future) bindable services, and odo would do the provisioning as part of odo link?

Yeah, that's what odo does today with service classes.

We should support this at CSV, CRD and the CR level as well - however, the initial step in a lot of tools would be "Show me the subset of developer services available for provisioning" . svcat get classes in service catalog used to do a really good job there.

[arthurdm]

Yeah, that's what odo does today with service classes.

cool, that's what I was missing. I do wonder though, how that will be actually done in terms of implementation.

From what I can tell service catalog was based on open broker, so it has a prescribed way for provisioning. Our service binding spec consciously stayed away from defining how to provision services, so do we have a gap in terms of what odo needs?

For example, we have nothing in the spec equivalent to:

$ svcat provision ups-instance --class user-provided-service --plan default

[sbose78]

Correct, it was based on open broker.

No, we are good, we don't have a gap, we should happily stay away from provisioning :)

Here's how the flow should look like:

1. Filter out relevant services that a developer might want provisioned using the metadata we agree on.

2. Let the tool figure out how to provision it ( not our problem :) )

3. After (2) is done, invoke service binding.

Our effort in this PR is to guide users in discovering the right services which after provisioning, developers would want their apps to bind to.

[arthurdm]

sounds good - thanks for the clarifications @sbose78. I will happily let the tools figure out provisioning. :D

So to summarize the changes we can do in this PR for the different ways to become discoverable:

• add Bindable to the CSV's metadata.annotations.categories (we'll need to open a PR with them) I like your suggestion for this, because it gives a nice human-readable way to filter this in OperatorHub
• add bindable to your Chart.yaml's keyword list (sample for mongodb and postgres)
• add the servicebinding/bindable: "true" annotation to your CRD or any CR (Secret, Service, etc)

looks good?

[sbose78]

Let me get to this, again.

[arthurdm]

@sbose78 - I have simplified the PR based on the suggestions above. ready for review.

[sbose78]

Looks good!

Could you mark this as 'experimental' please? I'm in the process of defining it out side of the context of binding too and things might change and I will ensure this stays in sync.

If there are things being tracked for RC2, let's have this tracked please.

[arthurdm]

thanks @sbose78

Added experimental and opened issue #35 for continuing this in RC2.