Joel Baxter
Joel Baxter
We're doing the same thing over and over for each new CR we handle. It's about time to factor this out. This involves: - The status gen check (handleNewCluster etc.)...
handleStatusGen uncritically accepts any already-created cluster CR that KD sees for the first time and treats it as a stable cluster. Instead, we should do some k8s interrogation, to deal...
Nothing specific to say about this right now, but I want to get it on the radar. We should start thinking about ways to express criteria for auto increasing or...
This isn't quite as important as issue #64 (split from issue #54) since it's probably unlikely that notify-processing will be long-running. However the idea is generally the same. It would...
I'm seeing some usecases for this in various discussion. One question is how to model a "stop" and "restart" request through edits to the KDCluster spec. For implementation, we'd need...
We should allow adding, removing, or changing service endpoints on a virtual cluster instance after it has been deployed. This would not involve actually changing what's running inside the container...
Currently an app CR is only cached internally for the duration of a handler. We should instead have an independent cache of app CRs accessible to both the reconciliation handlers...
If the mutating admission controller is not enabled on K8s (cf. issue #2), our webhook will just silently never get called for anything. This breaks some of our admission control...
Currently, if multiple roles are deployed/resized at the same time, we will handle the roles (run startscripts in their members) in some arbitrary order. The app might have a stronger...