[spike] Decide on how to package and deploy the pipeline manifests

[codificat]

At the time of this writing, the pipeline manifests for the CNBi feature implemented via the Meteor operator are added in the operator's repo under the hack/ directory and deployed via the Makefile.

The pipelines should eventually be properly packaged and deployed.

Options:

• Use the helm-charts repository as the source for all pipeline manifests, and deploy them via:
  • helm
  • KfDef
  • ArgoCD
• Have the operator deploy the manifests itself
• Keep the manifests in the operator repo, deploy them via:
  • KfDef
  • ArgoCD

[codificat]

/sig devsecops /kind feature /priority important-longterm

[sesheta]

@codificat: The label(s) sig/devsecops, kind/feature, priority/important-longterm cannot be applied, because the repository doesn't have them.

In response to [this](https://github.com/thoth-station/opendatahub-cnbi/issues/10#issuecomment-1246553816): >/sig devsecops >/kind feature >/priority important-longterm Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[codificat]

Trying again: /sig devsecops /kind feature /priority important-longterm

[codificat]

/wg cnbi

[VannTen]

* Have the operator deploy the manifests itself

Many k8s operators appears to do that, but in my opinion they should not. The Roles needed for installing and running are not the same.

* Use the [helm-charts repository](https://github.com/thoth-station/helm-charts/) as the source for all pipeline manifests, and deploy them via:
* Keep the manifests in the [operator repo](https://github.com/AICoE/meteor-operator), deploy them via:

Is is a good resume to say that those two options bog down to bundle the pipelines with the operator, or separately ? If that's the case, I think the decision depends on whether we see the operator as extendable or not. => Does each Pipeline constitutes a plugin to make the operator able to handle a particular CR type (PackageList/GitRepo/whatever) ? Or do we have a bounded set of types (and hence of handlers).

Note that we could combine the two.

[VannTen]

Note from the meeting yesterday: might have some troubles using KfDef since it's using kustomize which is less powerful (if simpler) than something like helm (=> array merging in yaml)

[harshad16]

Based on the previous discussions in CNBI meetings. The consensus of having the pipelines with cnbi operator was picked up. with #29 and #108 this would be implemented.

[codificat]

/reopen pending the merge of https://github.com/thoth-station/meteor-operator/pull/108

[sesheta]

@codificat: Reopened this issue.

In response to [this](https://github.com/thoth-station/opendatahub-cnbi/issues/10#issuecomment-1310410398): >/reopen >pending the merge of https://github.com/thoth-station/meteor-operator/pull/108 Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[harshad16]

Removed the revised-size as the issue is yet to be marked done.