[
https://issues.apache.org/jira/browse/YUNIKORN-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420758#comment-17420758
]
Manikandan R commented on YUNIKORN-337:
---------------------------------------
{quote}
* Can we remove the "Update" from interface description. We can just use
{{AllocationRequest}} instead of {{UpdateAllocationRequest}} or
{{AllocationUpdateRequest}}
* Since we split the messages for both request and response into the separate
pieces the type information that we have in the variable name like
{{newAllocations}} can be simplified
{\quote}
Taken care
{quote}
There has to be a possibility to fold the ReloadConfiguration into a RM message
or the other option is to fold this into the UpdateConfiguration message. We
currently have two separate messages for an update of the config depending on
where it originates. We should use one message that is bidirectional.
{\quote}
I will think through on this merge. At a high level, here are my thoughts:
Both use cases has different context and need. One call is from shim and
another one from core with different parameters. Even if we merge the message,
I am not sure how the code would like because both shim and core would play
both roles - caller and receiver based on the context.
{quote}
The ActionFromScheduler is not implemented at the moment. We need to look at
this more in sync with the resource manager message. Triggering that action
with the RESYNC value comes down to a full restart and recovery of YuniKorn as
a whole. I do not see how to reliably decide in the core that this needs to
happen. I also do not think we should be adding this to every single response.
If we generate a message like that it has to be a sync message not something
that can be processed async.
{\quote}
Then, can we take up this later in a separate jira if needed? If yes, Can we
clean up this from interface? Also, I will clean up the doc as well.
{quote}
ReSyncSchedulerCache as a plugin call has been an issue for a while.
YUNIKORN-462 was logged to reassess the need. That needs to be mentioned in the
new documents.
{\quote}
True. We had some discussions in the past in that jira. Will need to revisit
the same and take it up accordingly.
{quote}
One last thing: looking at the node message there is a lot of overlap between
the two messages for a new or updated node.
{\quote}
Taken care
> interface message complexity
> ----------------------------
>
> Key: YUNIKORN-337
> URL: https://issues.apache.org/jira/browse/YUNIKORN-337
> Project: Apache YuniKorn
> Issue Type: Improvement
> Components: scheduler-interface
> Reporter: Wilfred Spiegelenburg
> Assignee: Wilfred Spiegelenburg
> Priority: Critical
>
> The current interface allows us to only send one message between a shim and
> the core. This provides us with a really simple way of interactions
> definition.
> The complexity is however hidden in the message itself. Every message serves
> multiple purposes and when the message is received the core and shim need to
> unpack it and process each part separately and for certain parts in a real
> specific order.
> Because the message serves a number of purposes it has a large overhead. This
> might not show up in the code directly as the heavy lifting is done in the
> generated code. It will show up in the amount of data as a message, even if
> it does not have all fields, still needs to be encoded in a way that it
> unpacks correctly on the other side.
> The trade off between having one message with a simple interface or multiple
> more focussed messages with a slightly more complex interface needs to be
> assessed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
