[
https://issues.apache.org/jira/browse/YUNIKORN-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176465#comment-17176465
]
Manikandan R commented on YUNIKORN-359:
---------------------------------------
Thanks [~sunilg] [~wwei] for sharing your thoughts.
{quote}We need to ensure a query param called *partition* is available in the
REST query. And consider that while fetching queues.
{quote}
I created https://issues.apache.org/jira/browse/YUNIKORN-360 mainly from same
perspective - Almost all handlers traverse the partitions in loop (though some
handler doesn't add up all partition attribute values properly, simple
replacing previous partition values. for ex, /ws/v1/queues and refer
handlers#getQueueInfo) , so having "partition" query param adds a value.
{quote}If user is not specifying any partition in the query (like today), we
need to choose first/default partition. Now i think we loop all partition which
is not correct. We need to fix this as well.
{quote}
>From general intuition perspective, exposing any optional query param and in
>case users don't pass any value, expected results should be across this param.
>For ex, In case of non-empty "partition", search should be with in that
>"partition" context. Otherwise, it should be across (in this case, across all
>partitions). So, am not sure assuming "default/first" would be an intuitive
>thing to do.
Also, this handler could be renamed to /ws/v1/partitions as this handler is all
about partition info. Queue Info is just one attribute among many other
attributes.
{quote}However i will still prefer to have the information as each partition
blob than summing up across partitions. User or client can do this if needed
from the usecase perspective.
{quote}
If we look at attributes being generated in {{handlers#getClusterJSON}}, it is
nothing but an attribute of a partition. Would it makes sense to move this
attributes as well to above mentioned API? When we read endpoint as "clusters",
as a user, would expectation be something about overall summary/picture of a
cluster rather than partition wise info? Here, we are having 1 cluster, no
concept of multiple clusters.
{quote}We need to ensure that we can give array of partition information here.
And we are doing the same here already. This seems ok to me.
{quote}
I doubt this, can double check. While traversing each partition,
{{var clustersInfo []dao.ClusterDAOInfo}} is initialising and overriding
previous partition results every time.
Please share your thoughts.
> 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]
