[
https://issues.apache.org/jira/browse/YUNIKORN-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193952#comment-17193952
]
Wilfred Spiegelenburg commented on YUNIKORN-359:
------------------------------------------------
I read through the document and my preference is for format #2.
The REST URL is really clear and follows the logical flow.
With option #1 I feel it is a bit of a strange start of the URL.
Collection names should be plural shouldn't they? like: _queues_,
_applications_ and _partitions_
I miss the config endpoint in the definition. I don't think we can do without
that endpoint. Not sure if we just need to mention that.
The proposal has {{GET}}, {{DELETE}}, {{PATCH or PUT}} and {{POST}} defined for
most objects. I do think we should start by defining and implementing just the
{{GET}} functionality. If and when we decide that we need to add that
functionality we can do that separately. Adding them in this design will give
the wrong impression that they will or could come.
This is the reason why I think we need to just define {{GET}}. Updating,
creating and deleting is not applicable for most, if not all, of the objects:
- applications are created through the shims, the core can not do that directly
Without the corresponding shim application it will not work. Updates (move) or
Deletes (kill) could be possible in the future.
- nodes are physical things and registered by the shim in the core, no delete
should ever be triggered from the core.
- partition is directly linked to the shim registration so we may not update or
delete ever.
- with queue updates or changes the issue is a bit more complex and that is why
we have a config endpoint at the moment (see above). We have seen lots of pain
points with individual queue changes in YARN through an API.
> Support for "queue" query param filter
> --------------------------------------
>
> Key: YUNIKORN-359
> URL: https://issues.apache.org/jira/browse/YUNIKORN-359
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Reporter: Manikandan R
> Assignee: Manikandan R
> Priority: Major
>
> Support "queue" query param filter to the following handlers:
>
> 1. /ws/v1/queues
> Return only queue info whose name exactly matches with "queue" query param
> 2. /ws/v1/nodes
> As of now, Each Node Info has all allocations made on that Node. With this
> change, it returns only Node info of Nodes whose allocation queue name
> exactly matches with "queue" query param. In effect, filter happens on
> allocations.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
