search

kubernetes-sigs / kube-scheduler-simulator

The simulator for the Kubernetes scheduler
Apache License 2.0
795 stars 135 forks source link

Separate syncer from simulator server #394

Closed saza-ku closed 18 hours ago

saza-ku commented 1 week ago

syncer is now running as a goroutine in the process of the simulator-server container. But we could separate it as another container, as we did to the debuggable scheduler (https://github.com/kubernetes-sigs/kube-scheduler-simulator/issues/318).

This would make the codes tidy and easy to develop.

/area simulator

sanposhiho commented 1 week ago

-1 I do not want to increase the num of containers unnecessarily. Should we create a container for every single feature in the simulator? Obviously No.

The debuggable scheduler had the clear motivation to split, while I don't see any here.

sanposhiho commented 5 days ago

Can you add more context (if any) like your company needs to split it for some usecases etc? If ↓ is the only motivation, I'm gonna close this issue.

This would make the codes tidy and easy to develop.

ordovicia commented 18 hours ago

Thank you for your comment, and I apologize for the delayed response 🙏 @saza-ku and I discussed in person. I am a coworker of his.

Because syncer only needs to connect to a KWOK cluster, its code and setting could be decoupled from the simulator core. We anticipate syncer and the simulator core can be developed independently, avoiding situations where the simulator would be hard to develop due to its dependency on syncer, or where the simulator's configuration would become more complex.

Additionally, we are planning to propose a replay feature, which records events on a real cluster, stores them in files, and then replays the events on a simulator cluster. Similar to syncer, replay feature can also be developed independently. If this feature were to be coupled with the simulator core, it could negatively impact the development of the simulator.

The issue of increasing number of container images could be mitigated by including syncer command within simulator-backend. Image users can switch entrypoint to use syncer. Furthermore, since syncer is an optional feature, it might be acceptable that syncer container image is not managed within this repository.

With that said, these are still theoretical discussions, and I understand and respect your opinion. Please feel free to close this issue if you prefer 😄

sanposhiho commented 18 hours ago

At the moment, I don't feel the need of the decoupling, and we can re-consider it when we actually find it necessary.

/close

k8s-ci-robot commented 18 hours ago

@sanposhiho: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/kube-scheduler-simulator/issues/394#issuecomment-2497257376): >- The simulator's development is not that active, and also we cut a release when we want (don't have a fixed release schedule). I don't see any need for the syncer and the simulator core to be developed separately. >- The simulator's config doesn't grow that much and rather it's simpler to have one config for everything > >At the moment, I don't feel the need of the decoupling, and we can re-consider it when we actually find it necessary. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.