[
https://issues.apache.org/jira/browse/YUNIKORN-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541112#comment-17541112
]
Saad Ur Rahman commented on YUNIKORN-1213:
------------------------------------------
{quote}When we add new values or parts to the config, how are we now going to
handle an update call now? Does the caller need to provide a full object with
all values set? The other option would be that we are going to merge new with
existing config values. Do we assume that all values that are not given in the
configuration get retrieved from the current config and then merged and written
into the file? Do we omit the defaults etc.
{quote}
I have done something like this for Apache Heron (incubating) for the K8s
scheduler and it can get tricky if there are values that need to be retained.
In the case of Heron, there are configurations which need to remain immutable
for it to work (ports, environment variables, etc.). The way I addressed the
issue was to invariably make Heron's settings take priority.
{quote}Are all values that we need to have in the config mutable already or are
there certain values that we do not want to ever make mutable as they require a
restart.
{quote}
This is another critical issue. If there are values which need to be immutable
within the _config_ tree there will need to be individually updated. This will
mean selectively updating parts of the subtree to ensure this.
{quote}The simple change of moving the checksum around in the config is already
backwards incompatible.
{quote}
I completely agree this will break 3rd party code.
{quote}You MUST not rely on the fact that everyone uses our config objects to
generate a REST request. It is only available in go, what if I use java.
{quote}
Sorry, I do not follow, I am still very new to YuniKorn. Is it not the case
that the Yunikorn YAML/JSON _configs_ are standard with expected formats? Once
a REST API request for an update has begun on the _core's_ backend the _config_
is validated, the provided _checksum_ is removed, recalculated, and then
inserted into the _config_ to be used as the update.
{quote}We logged YUNIKORN-455 a long time ago to make the scheduler
configurable that is still open. The mention of two files is already there.
Looking back over jiras I think we have at least 6 or 7 parameters that need to
be configurable. Looking forward I can think of a couple more that will come.
{quote}
Should we consolidate the design discussion to the original thread? That way we
can track all the potential properties that require hot updates as well as any
architectural changes and concerns.
> The interval of the background health checker needs to be configurable
> ----------------------------------------------------------------------
>
> Key: YUNIKORN-1213
> URL: https://issues.apache.org/jira/browse/YUNIKORN-1213
> Project: Apache YuniKorn
> Issue Type: Improvement
> Components: core - scheduler
> Reporter: Weiwei Yang
> Assignee: Saad Ur Rahman
> Priority: Major
> Labels: pull-request-available
>
> YUNIKORN-1107 adds a background running health checker to verify the
> scheduler data correctness in the fixed time interval 30s:
> https://github.com/apache/yunikorn-core/blob/3ba91fb8a41c0fd0dd6243326e583dea5167199f/pkg/scheduler/health_checker.go#L34.
> We need to make this configurable, either let the user set a longer/shorter
> interval, or completely disable it.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
