Instantiate and manage services through Operator

[kadel]

User Story

As a user, I want to create a new instance of my database or another service managed by operators So that I can use it (link it) with my application

Acceptance Criteria

• odo should create a new instance of an operator in my project using odo service create command (Instantiate an operator backed service using yaml file #2723)
• odo service list should list all created services (odo should list services created from operator #2790)
• odo service list -o json should list all created services in JSON format (JSON output for operator backed services in the cluster #2791)
• odo service delete <service-name> should delete operator backed services (odo should be able to delete operator backed services #2792)
• odo link <CR-name>/<service-name> should link the component under pwd to the specified service name. (Support link command for devfile #2920)
• odo unlink <CR-name>/<service-name> should unlink the component under pwd from specified service name. ("odo unlink" to unlink a devfile component from an Operator backed service #3563)

Links

• Part 2 of this epic: Instantiate and manage services through Operator, part 2 #4591
• Feature Request: Instantiating operators using CRDs #2462
• Feature Request: List & Provision Services from the in-cluster installed operators (Dev Catalog) #2161

/area service-operators
/area service

[kadel]

/assign @dharmit @girishramnani

[girishramnani]

a high level thought process around this was -

• to allow creating different CRDs present under same operator we could have the cli which looks like this
  odo service create <<CRD_NAME>> --operator <<operator>>
  e.g. odo service create KafkaTopic --operator strimzi-operator

• we can use the unstructured kubernetes client to instantiate the CRD . some reference on that here https://www.oreilly.com/library/view/programming-kubernetes/9781492047094/ch04.html

• the openAPIV3Schema which is present in the CRD definition will be used to validate parameters provided by the user are actually part of the CRD. This openAPIV3Schema currently is optional but it will be necessary for later versions as mentioned here https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#pruning-versus-preserving-unknown-fields

so a user can provide values while creating the CRD e.g.
odo service create KafkaTopic --operator strimzi-operator --replicas 1 and we can use the CRD as shown here https://strimzi.io/docs/latest/#con-custom-resources-example-str to validate that replicas is a valid argument.

[kadel]

• to allow creating different CRDs present under same operator we could have the cli which looks like this
  odo service create <<CRD_NAME>> --operator <<operator>>
  e.g. odo service create KafkaTopic --operator strimzi-operator

I would prefer the other way around. The operator's name is basically the service name. So the command should be odo service create <operator> with optional --crd flag that would be required only if Operator provides more than one API/CRD (OpenShift webconsole calls this "Provided APIs")

odo service create mongodb-enterprise.v1.2.4   --crd MongoDB

[dharmit]

to allow creating different CRDs present under same operator we could have the cli which looks like this
odo service create <<CRD_NAME>> --operator <>
e.g. odo service create KafkaTopic --operator strimzi-operator

This makes sense and I'm not suggesting that it's a wrong idea, but to keep things in sync with how we do it right now with services and plans (Service Catalog), I'd prefer odo service create <operator> --crd <crd-name>.

[dharmit]

@kadel @girishramnani last two points talk about odo service describe command. But we don't have that command in the workflow right now. Do we mean odo service list -o json?

[girishramnani]

we decided to do describe after the instantiation was done as that instantiation was a more "critical" piece.

[dharmit]

It's not about when to do it. I understand that it's not essential right now. I'm pointing to there being no odo service describe in the first place.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[dharmit]

/lifecycle frozen

[girishramnani]

We have completed all ACs this epic hence closing