[
https://issues.apache.org/jira/browse/YUNIKORN-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420463#comment-17420463
]
Wilfred Spiegelenburg commented on YUNIKORN-337:
------------------------------------------------
The document does not allow commenting. Please open the document up for
commenting.
I'll leave the main comments here:
* 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
* 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.
* 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.
* {{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.
> 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: issues-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: issues-h...@yunikorn.apache.org
