[ 
https://issues.apache.org/jira/browse/YUNIKORN-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114141#comment-17114141
 ] 

Adam Antal commented on YUNIKORN-117:
-------------------------------------

I made some progress. The current status is to handle too many event emitted by 
the core to kubernetes each time at tryAllocate.
If we would just simply flush everything we could have these kind of {{kubectl 
describe}} outputs:
{noformat}
Events:
  Type     Reason                              Age                       From   
   Message
  ----     ------                              ----                      ----   
   -------
  Normal   Scheduling                          5m11s                     
yunikorn  default/task0 is queued and waiting for allocation
  Warning  FailedScheduling                    5m11s (x24 over 5m11s)    
yunikorn  [Predicate NodeUnknownCondition failed]
  Normal   Pending resources would not fit in  12s (x136548 over 4m47s)  
yunikorn
{noformat}
This should be avoided.

> Create event cache for queue and application events
> ---------------------------------------------------
>
>                 Key: YUNIKORN-117
>                 URL: https://issues.apache.org/jira/browse/YUNIKORN-117
>             Project: Apache YuniKorn
>          Issue Type: Sub-task
>          Components: core - cache, core - scheduler
>            Reporter: Adam Antal
>            Assignee: Adam Antal
>            Priority: Critical
>              Labels: pull-request-available
>
> Create a simple preliminary implementation of the event cache of YUNIKORN-42.
> We have the following limited scope for this task:
> - implement it as a separate process from the scheduler (similar to 
> {{PartitionManager}})
> - only deal with queues and applications (the pods and nodes can be added 
> later)
> - only store the apps last visited time from the scheduler
> - clean up those objects that haven't been visited in the last 24h
> Other cache implementations can be also considered.
> As a starting point, channels are a safe choice to have async communication 
> with the scheduler without expecting bigger performance loss.



--
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

Reply via email to