villebro commented on issue #31408:
URL: https://github.com/apache/superset/issues/31408#issuecomment-2596198735
@Synarcs you raised a good point about the having separate statuses for the
different components. I agree that it will be clearer if we can split out the
individual components into separate CRs, even if we have a single monolith at
the top. So let's say we have the following hierarchy:
```
Superset
SupersetWebWorker
Deployment
ReplicaSet
Pod
SupersetAsyncWorker
Deployment
ReplicaSet
Pod
SupersetAsyncScheduler
Deployment
ReplicaSet
Pod
Ingress/Gateway
Service
ConfigMap
...
```
This would make it possible to do `kubectl describe superset my-superset` to
see the status at high level, but then drill down into the individual workers
by doing `kubectl describe supersetwebworker my-superset` etc, where a more
detailed status could be seen. This aligns with how `Deployment` branches out
into a single `ReplicaSet`, which initially may seem like unnecessary overhead,
but makes sense once you consider what they represent.
Therefore, we'd still have a single monolithic CRD for Superset, but we'd
introduce separate CRDs and controllers for the various worker types and
reconcile then in separate reconciliation loops. So the `Superset`
controller/reconciler would create `SupersetWebWorker`, and that one would then
in turn create the actual `Deployment` etc. While most admins would just use
the `Superset` CRD, this way you'd also have the option of spawning a
`SupersetWebWorker` without a top level `Superset` CR if you really want to.
If you agree with this approach I'll update the proposal to reflect this
structure.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
