[
https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin....
]
Jeff Mesnil commented on WFWIP-198:
-----------------------------------
That is a legitimate concern.
My understanding is that Operator are designed to configure and maintain a specific
product (e.g. Prometheus). In that case, the Operator must provide options for the
resources that are actually required by the product.
In EAP case, this is different as the product is more open-ended since the Operator
configure and maintain a user application.
We have to find a balance between exposing all Kubernetes resources/options through the
operator (which would be a disaster from a usability and maintenance point of view) and
preventing legitimate uses cases (eg. having the user application access a shared
persistent volume)
I don't have a good answer to give you except that analysis should be done on a per
feature basis.
First we need to make sure that the Operator is able to do all the things that we
currently support.
Then any new features will have to be analysed to determine if there is a need to expose
underlying Kubernetes options vs using the operator to encapsulate it.
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#wil...
[2]
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pods...
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#stat...
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#serv...
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ingr...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)