Well, if we talk about the specific lifecycles associated to traits in custom
resources, I think we don't need to add new services, as it's the role of the
operator to update CRs and related kubernetes objects to reflect the
configuration set by the user. We need to abstract the code associated to the
traits from the main state machine, but we can define internal modules for
that, we don't need to split the operator into physical distinct services. It
adds complexity.
E.g. if instead of creating a Deployment, the operator needs to create a
CronJob, that is just internal logic that we just need to modularize
(interceptors?) to make it more maintainable. Same if we need to expose a
service.
A different thing is when a trait requires something at infrastructure level.
E.g. if I have a integration `from("kafka:topic").to("log:msg")` and I want to
shutdown the integration when there are no new messages in the `topic`, maybe
I'd activate a distinct "watchdog" service to handle it.
The "maven-builder", that is now embedded in the operator is another service
that will be externalized, although I don't know if there'll be a `s2i-build`
trait or it will be a general cluster configuration.
The "graal-builder" is something we should think to create outside the
operator, enabled by a trait.
In my view, the operator should continue to handle the state machine, creating,
destroying and interacting with external services to perform some actions in
order to move the state forward. Traits are one of the sources the operator
will use to decide if a external service should be started or not.
[ Full content available at: https://github.com/apache/camel-k/issues/115 ]
This message was relayed via gitbox.apache.org for [email protected]
