Instantiate an operator backed service using yaml file

[dharmit]

User Story

As a user I want to edit the example (alm-example) used to spin up an operator backed service. This is required because:

• alm-examples used by odo to spin up an operator backed service are not always 100% functional in that, they contain template data which can't actually spin up a service.
• I'd like to change certain parameters in the CR before spinning up an actual service

Acceptance Criteria

• odo must add a flag (eg: --dry-run) which would show the example that will eventually be used to spin up the service. (Print yaml definition of CR when asked for dry-run #2810)

• user should be able to provide a yaml file similar to aforementioned example that can then be used to spin up the service.

  This will be similar to oc create -f example.yaml

Links

• Feature Request: List & Provision Services from the in-cluster installed operators (Dev Catalog) #2161
• Related issue: Instantiate and manage services through Operator #2613 (first point: odo should create a new instance of an operator in my project using odo service create command)

/kind user-story

[kadel]

What will be the command?
Are you thinking about something like odo service create -f etcd.yaml ? Or some other approach?

[dharmit]

#2810 addresses the first part of this issue's acceptance criteria.

[dharmit]

@kadel I'm thinking of making user specify the operator name and crd name as is the case right now, and specify file name after that. Something like:

$ odo service create etcdoperator.v0.9.4 --crd EtcdCluster -f etcd.yaml

This long command will help us do some validation so that a user doesn't erroneously or purposefully try to create something else by doing odo service create -f etcd.yaml. They could create something else if we don't keep any validation because we're simply passing the unstructured data to the APIs.

What do you think about this approach?

[kadel]

Not sure about that. The commands above looks way too long and complicated :-( It is also full of duplicate values, everything that is specified is also in the yaml file :-(

We can still do some validation even without forcing users to provide duplicated parameters.

Would it be possible to simply parse the yaml file, get Kind and check if it matches one of the CRDs provided by already installed operators?

[dharmit]

Yes. That sounds doable. Agree with your points about long and complicated. Let's go with it.

Just one clarification however. The odo service create command will accept a path to some yaml file only when experimental mode is enabled.