Why do we have to use virt-operator ?

[ola...@gmail.com]

Hi,

I'm new to kubevirt, I've read most of the codes of each component then came up with this question: why do we have to use virt-operator? Is it just for simplicity?

As far as I know, virt-operator's responsibility is to help administrator deploy all the needed components, all we need is to create a KubeVirt resource object, then the operator will do the rest for us.

Operator creates each component's yaml file using the content hard-coded in the code, so it looks like the only benefit using this operator is that it creates some yaml file and then applies them.

So would it be better to provide some yaml files that have already contain the config for each kubevirt components?  For example: deployment.yaml, daemonset.yaml and service.yaml, etc, then provide user a shell to apply all these yaml  and all components are installed.

That's why I don't think it's useful to use an operator...

There might be some other functions virt-operator has I haven't known, if someone sees this question please tell me...

[Roman Mohr]

Hi,

In some scenarios not having the operator may indeed be good enough  or even better.

However we think that overall it gives a better experience:

1) (zero-downtime) updates: In some cases it may be good enough to just apply a set of new yamls to have a seamless and well working update of componentes, but often it is not (new apis get added, existing apis get changed, webhooks get added or removed, some components rely on other components having a specific version to seamless upgrade, ...). virt-operator will also clean up artifacts from old installations which are no longer needed (something which kubectl apply can't do).
2) testing: If the operator allows customizations to the installation, they are tested and know to work.
3) Other day-2 operations like automatic CA and certificate operations which are needed to keep the installation secure and healthy, which is again much better testable if we know how kubevirt can and will be installed (this could as well be an extra component or controller and not an overall operator, but then you again need something to properly work in the context of (1)).
4) Dynamic support for various features: Prometheus Operator, OpenShift, CDI, ...

The obvious downside is that it is not so easy to customize the kubevirt installation. We hope to remove this con mostly by introducing soon extra customization fields for very-often used customizations like tolerances, affinities and so forth.

I hope that helps clarifying this a little.

Best Regards,

Roman

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/270a1828-a8cd-4953-96e2-184ec51bcaaao%40googlegroups.com.

[ola...@gmail.com]

Thanks bro ! This is very clear. :)

在 2020年7月24日星期五 UTC+8下午5:01:38，Roman Mohr写道：

To unsubscribe from this group and stop receiving emails from it, send an email to kubevi...@googlegroups.com.

[Roman Mohr]

Hi Daniel (adding kubevirt-dev again),

On Wed, Aug 5, 2020 at 11:37 AM Daniel Qu <quju...@gmail.com> wrote:

Hi, I meet the downside of the operator recently, I notice that there was a PR for Kubevirt helm chart, but it's a very early version in 2017 and has been closed. I have been thinking to create a new PR, but not sure that we really need it, how about you guys's opinion?

We are working on two things right now:

 * Allow patching our components in arbitrary ways [1]
 * For general placement of our components provide a nice placement api [2] (this api is designed for more than just kubevirt/kubevirt but it will be available on kubevirt/kubevirt too at the end)

Could you check them and see if they would meet your requirements? If not, it would be great if you just post on the PRs and take part in the discussion.

Best Regards,

Roman 

[1] https://github.com/kubevirt/kubevirt/pull/3612
[2] https://github.com/kubevirt/hyperconverged-cluster-operator/pull/718
 

在 2020年7月24日星期五 UTC+8下午5:01:38，Roman Mohr写道：

Hi,

To unsubscribe from this group and stop receiving emails from it, send an email to kubevi...@googlegroups.com.

[Daniel Qu]

Great!

I'll be there~

在 2020年8月5日星期三 UTC+8下午5:42:29，Roman Mohr写道：