You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by "Kinga Marton (Jira)" <ji...@apache.org> on 2020/10/02 13:41:00 UTC
[jira] [Commented] (YUNIKORN-433) Extend configwatcher expiration
time when a new request comes in
[ https://issues.apache.org/jira/browse/YUNIKORN-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206186#comment-17206186 ]
Kinga Marton commented on YUNIKORN-433:
---------------------------------------
The K8s documentation says the following about the delay([https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap):]
{quote}As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in kubelet.
{quote}
According to this I think we should set the timeout for at least 2 minutes. Even with this change I think we cannot guarantee that the updated configurations will take effect in the scheduler every time.
> Extend configwatcher expiration time when a new request comes in
> ----------------------------------------------------------------
>
> Key: YUNIKORN-433
> URL: https://issues.apache.org/jira/browse/YUNIKORN-433
> Project: Apache YuniKorn
> Issue Type: Bug
> Reporter: Kinga Marton
> Assignee: Kinga Marton
> Priority: Major
>
> When two configuration reloading is triggered closely to each other it might happen that, before the update is available the watcher times out, because it is already running, since it was triggered during the first update/configmap creation. Then the update triggers it again, the expiration time is not modified. Everything is about the timing: if you wait with the update until the first triggered configwatcher times out, then the changes will be synced. Also it works if you are quick enough with the update and the changes takes effect before the expire time.
> For avoiding this kind of issues with the config changes we need to add 2 changes:
> * increase the timeout for the configwatcher
> * restart the configwatcher timer when the configwatcher is triggered and theer is already one running.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org