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

Martin Choma (Jira) issues at jboss.org
Thu Sep 12 02:24:00 EDT 2019


     [ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFWIP-198:
-------------------------------
    Description: 
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

  was:
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?

1) 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
2) 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)
3) 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



> 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)


More information about the jboss-jira mailing list