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

[ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.... ] 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. -- This message was sent by Atlassian Jira (v7.13.5#713005)