[jboss-jira] [JBoss JIRA] (WFWIP-198) Operator long-term strategy

[Ondrej Chaloupka (Jira)]

    [ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785151#comment-13785151 ] 

Ondrej Chaloupka edited comment on WFWIP-198 at 9/17/19 4:15 AM:
-----------------------------------------------------------------

[~mchoma] I would add a bit more from technical perspective of transaction recovery and my position on this.

The transaction recovery needs to be handled by a code integrated with Kubernetes. As the Red Hat strategy is to utilize operators to configure and run the Red Hat products I consider operator being the right choice here. Of course there could be created a hand made controller (or operator) just for transaction handling. This would mean necessity of configuration of first application (either with template or with a operator ) and immediately adds a second operator which would need to be configured to manage transactions. I consider that error prone.
For me as many other things in software engineering there are plenty points of view and each of them has some trade off. The decision here is to have a compound solution that should be easy to get and running. And this corresponds with the operator mission - don't bother the users with complex kKubernetes setup and give them a single easy to use component to deploy their stuff.
I would say yes the operator maps the Kubernetes model to the flat one and it's desired.

One example. If I omit the Operator runtime capabilities and I limit the point on the configuration then one question - what is the right way for WildFly deployment on Kubernetes? Will you choose the deploymentconfig, replicaset or statefulset? Do you know what are the benefits for each of them in respect of WildFly? If you know and you care then, ok, operator is not for you and it's hard to convince you that it is. If you don't care, you don't have time to care, you don't know then in my opinion the operator is good way to go.


was (Author: ochaloup):
[~mchoma] I would add a bit more from technical perspective of transaction recovery and my position on this.

The transaction recovery needs to be handled by a code integrated with Kubernetes. As the Red Hat strategy is to utilize operators to configure and run the Red Hat products I consider operator being the right choice here. Of course there could be created a hand made controller (or operator) just for transaction handling. This would mean necessity of configuration of first application (either with template or with a operator ) and immediately adds a second operator which would need to be configured to manage transactions. I consider that error prone.
For me as many other things in software engineering there are plenty points of view and each of them has some trade off. The decision here is to have a compound solution that should be easy to get and running. And this corresponds with the operator mission - don't bother the users with complex kKubernetes setup and give them a single easy to use component to deploy their stuff.
I would say yes the operator maps the Kubernetes model to the flat one and it's desired.

One example. If I omit the Operator runtime capabilities and I limit the point on the configuration then one question - what is the right way for WildFly deployment on Kubernetes? Will you choose the deploymentconfig, replicaset or statefulset? Do you know what are the benefits for each of them in respect of WildFly? I you know and you care then, ok, operator is not for you and it's hard to convince you that it is. If you don't care, you don't have time to care, you don't know then in my opinion the operator is good way to go.

> Operator long-term strategy
> ---------------------------
>
>                 Key: WFWIP-198
>                 URL: https://issues.jboss.org/browse/WFWIP-198
>             Project: WildFly WIP
>          Issue Type: Bug
>          Components: OpenShift
>            Reporter: Martin Choma
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> Facts:
> # Operator creates and manges internaly several kubernetes objects; StatefulSet, Pod, Service, Routes. By rough estimation these kubernetes objects expose approximately 50 options[2]. Operator now expose approximately 10 options [1].
> # EAP7-1192 is currently designed in way operator is integral part of solution. You can not turn off operator to EAP7-1192 properly work.
> # User cant touch internal Kubernetes objects. Operator manages them and can overwrite changes anytime.
> So given these facts question is what is long-term strategy with Operator?
> # Operator will provide all options of internal objects. Everything I am able to configure directly with Kubernetes objects I will be able to configure with Operator
> # Operator will expose just most useful options. If user wants to make something special he has to "turn off" operator and to be on his own. (Loosing transaction support provided by EAP7-1192)
> # Operator will expose just most useful options. If user wants to make something special he can and Operator won't overwritten his changes. (I dont know if it is feasible?)
> [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#wildflyserverspec
> [2]
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#podspec-v1-core
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#statefulsetspec-v1beta1-apps
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#servicespec-v1-core
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ingressspec-v1beta1-networking-k8s-io



--
This message was sent by Atlassian Jira
(v7.13.5#713005)