Refactor underlying code for "odo service" commands

[dharmit]

Currently odo service supports two service backends:

1. Service Catalog
2. Operator Hub

Because of the numerous if..else blocks and short term thinking we did on this during v2 release, we've accumulated code that's:

1. not easy to read
2. difficult to debug
3. buggy (list of bugs)
4. difficult to add features without adding more if..else blocks

Besides that, we might plan to add support for other service backends future. Thus, making the code easy to add more pending features w.r.t Operator Hub integration (#2613), and easy to plug that extra backend (if we decide to) is of utmost importance.

Acceptance Criteria / Related Issues / Dependent Issues

• "odo service list" doesn't display services started from Service Catalog #3098
• Operator Hub outputs can be more user friendly than what they are right now #3197
• Unit tests for Operator Hub integration #3605
• Pods are terminated and new pods started on initial odo link and every subsequent odo push #3803
• Example in odo service create -h doesn't work #4172
• odo link fails with devfile component #4233

/kind code-refactoring
/area service
/area service-operators

[dharmit]

Scope of work for refactoring odo service create:

1. We will decide between using Operator Hub or Service Catalog backend by looking at the arguments passed.

   # below command will assume Operator Hub backend because of a forward slash
   $ odo service create etcdoperator.v0.9.4/EtcdCluster
   
   # below command will assume Service Catalog backend because there's no forward slash
   $ odo service create dh-postgresql-apb --plan dev -p postgresql_user=luke -p postgresql_password=secret -p postgresql_database=my_data -p postgresql_version=9.6 -w

2. We need an interface that would have methods to create a service.
3. I will be modifying the struct ServiceCreateOptions to use this interface. https://github.com/openshift/odo/blob/5544b25ec083506393090faad5b4205126e4f675/pkg/odo/cli/service/create.go#L61-L62 Fields specific to Service Catalog and Operator Hub will be moved to their respective structs and these types will implement the interface we create for odo service create. In its simplest form, all the code from Comlpete, Validate and Run functions will be moved to methods of the same name implemented by the two structs.
4. As for the integration tests, the ones written currently should pass without any major modification.
5. As for the unit tests, more of those will be added in this refactor.

Other odo service commands to follow the suite. Separate interfaces will be created for them. I will try to keep smaller interface with lesser/specific methods so that we can plug in odo link support for Helm without much issues.

For odo link, I will put off refactoring till #4281 is addressed because with that going in, we will be having to deal with only devfile components. More importantly, I think it will be done long before I reach the point of refactoring odo link.

[faysou]

@dharmit I'm looking forward to be able to add a postgres db with odo for local development in CRC. It seems no service is available when using CRC, except ones added through an operator, but this makes things harder, I've been spending a few hours on adding one of the postgres operators available and making it work in odo but still didn't manage to.

It would be easier to have access to the Catalog templates from a user perspective (from a dev perspective I see you have been following this issue and the solution seems not obvious).

Alternatively is there some tutorial somewhere on how to develop locally without odo ?
Following this tutorial, I could make it work with oc but not with odo.
https://github.com/redhat-developer/s2i-dotnetcore-persistent-ex
Edit: I actually just managed to make odo work in the context of the tutorial above by combining the odo way and adding a database and secrets using oc instead of odo, so I mixed the odo and oc way, this still allows me to get benefits of local development with odo.

Thanks a lot for your work.

[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

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[prietyc123]

Acceptance criteria has not been met.

/reopen
/lifecycle frozen

[openshift-ci]

@prietyc123: Reopened this issue.

In response to this:

Acceptance criteria has not been met.

/reopen
/lifecycle frozen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dharmit]

Acceptance criteria has not been met.

/reopen
/lifecycle frozen

@prietyc123 This issue was opened as a part of "refactoring" the odo code right after v2 was released. But the time we had taken to "refactor" things didn't go well.

After that, it was decided that we would refactor the code when opening PRs for features/bugs, but won't dedicatedly work on refactoring things. If you look at #4465, it refactors a lot of code of odo service commands so that we use Go interfaces instead of if..else mess we were stuck with.

I'm removing the lifecycle frozen from this issue, but I'd urge you to close it, as we're not going to work dedicatedly on refactoring things.

/remove-lifecycle frozen
/triage unresolved

[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