Hi Mani

Thank you for starting this. Really nice to see proposals like this to
further improve the efficiency and readability.

As this is going to change the scheduler-interface pretty dramatically, I
think we need to bring this to all dev's attention. Please help to review
the doc and share your thoughts. Doc:
https://docs.google.com/document/d/1qNGz7JgA5ArfFy5gLC_uhCsP-w9ii-pJoV-Fbh01awU/edit
.

Starting from some high-level questions

   1. Is this planned for 1.0.0 release? 1.0.0 will be released sometime in
   Nov or Dec this year.
   2. Have we done PoC to verify the size of this change? I assume we will
   need changes in both repos.
   3. Do we need an umbrella JIRA and a feature branch for this work?
   4. We need to cover the doc changes as well, such as
   http://yunikorn.apache.org/docs/next/design/scheduler_core_design

Apart from that, I have one more ask for this. Today, we have a callback
interface: "ResourceManagerCallback". The shim registers a callback to the
core via:
https://github.com/apache/incubator-yunikorn-k8shim/blob/2507b8b68b1c385e67ac2afcd88626e890d2e268/pkg/shim/scheduler.go#L227.
Is it possible to change this to an event handling model? I have some
thoughts, could we do something like this:
https://play.golang.org/p/Kibbq4QtRUf. This should work for both local vs
gRPC communications (currently we are using the local, aka inner-process
communication mode). The gRPC mode just requires us to implement a
client-side lib to receive gRPC messages from the core, and trigger event
handling based on the messages. This way I think it is clearer than the
current approach. Would this make sense? I have also commented in the
design doc.

Thanks

On Mon, Sep 27, 2021 at 6:59 AM Manikandan R <[email protected]> wrote:

> Hi Everyone,
>
> I would like to bring the discussions going on
> https://issues.apache.org/jira/browse/YUNIKORN-337 to the community due to
> changes in the way shim and core communicate for allocation, application,
> node etc. Please go through the WIP proposal doc specified in JIRA and
> share your thoughts.
>
> Thanks,
> Mani
>

Reply via email to