[
https://issues.apache.org/jira/browse/YUNIKORN-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798448#comment-17798448
]
Wilfred Spiegelenburg commented on YUNIKORN-2235:
-------------------------------------------------
Lets take a step back:
* {{/ws/v1/partition/:partition/application/:applicationID}} will return _one_
application and can be linked to the exact same code internally as we use now
to get the application for the queue while skipping the queue check. I see no
issue there.
* Requesting an application directly via the above URL gives you a response if
the application is active. No response if the application is completed or
rejected. If we want to support that we should use seperate URLs for those.
Those can return a list of applications (support for application ID reuse).
* Export {{GetApplication()}} on the partition, and do not add a new unlocked
version, as [~chia7712] said to error prone and easy to introduce bugs.
* Exporting {{GetAppsByState()}} could be needed if we want to allow extra
filtering via a query parameter (see below)
* We have 3 lists of applications in the partition. The Application object
might be the same but the data is not really comparable. Rejected applications
have no valid queue name, cannot have allocations etc and most timestamps are
empty. Completed applications have no allocations or requests and should have
all timestamps set etc.
** applications contains all "active" applications and has applications in
many states: New, Accepted, Running etc. Never Rejected, Completed or Failed as
the application state.
** completedApplications contains all completed applications and has only 3
states: Completed, Failed and Expired
** rejectedApplications contains all rejected (never placed) applications and
2 states: Rejected and Expired
* Expired applications should only exist in the completed and rejected
applications list but we had some issues early on and that is why we do the
cleanup also on the applications list (we might be able to remove that now...)
Expired application are removed from the list at a regular interval.
* We should not mix completed, rejected and running applications in one
response on the REST API. Application IDs can be reused. Mixing the three types
now puts the task of splitting the applications on the client. This can become
really complex for the client to work through.
* Completed applications searches for the same application ID can return
multiple application entries. Same should be true for the rejected
applications. We thus cannot use the
{{/ws/v1/partition/:partition/application/:applicationID}} for those as I do
not think that returning an array of entries makes sense for the endpoint which
is supposed to return a specific application. Always returning a list of
applications is also contrary to expectations when I ask for a specific
application.
Then for the newly introduced URL for listing applications. I was in two minds
for a while on these:
{{/ws/v1/partition/:partition/applications/:state}}
or
{{/ws/v1/partition/:partition/applications?status=:state}}
With the remarks made above I think the best fitting option would be the first
option. The states to support should be {*}active{*}, *completed* and
{*}rejected{*}. Each state maps to a list in the partition and the full list
that is there is returned. The responses are different enough that I think we
cannot use the same URL with a query option. The query option would also
require a "fake" state like active to be supported to allow a simple way of
requesting all active applications in one request.
So for the active state we would see all New, Accepted, Running etc
applications in the system. We could allow a query option for the running
request to narrow it further down as an option. That query option is not
needed, I think, for the rejected or completed applications. Only give me the
New applications for the system:
{{/ws/v1/partition/:partition/applications/active?status=:state}}
> Add new RESTful API for retrieving application
> ----------------------------------------------
>
> Key: YUNIKORN-2235
> URL: https://issues.apache.org/jira/browse/YUNIKORN-2235
> Project: Apache YuniKorn
> Issue Type: New Feature
> Components: core - scheduler
> Reporter: Xie YiFan
> Assignee: Xie YiFan
> Priority: Minor
> Labels: pull-request-available
>
> *Situation:*
> Currently, the path format of retrieving application is
> /ws/v1/partition/\{partitionName}/queue/\{queueName}/application/\{appId}.
> We have to give 3 parameters (partitionName, queueName & appID) to fetch
> application information. But one application can only be submitted to one
> queue and PartitionContext stores all applications. It means that we can
> fetch the target application without queue name.
> *Proposal:*
> As we have discussed in slack, we can add the following 2 RESTful API.
> # /ws/v1/partition/\{partitionName}/applications/\{type}
> aim to list applications IDs via the types: rejected, running and completed
> # /ws/v1/partition/\{partitionName}/application/\{applicationID}
> aim to retrieving one application object directly.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
