[
https://issues.apache.org/jira/browse/YUNIKORN-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784667#comment-17784667
]
刘达 edited comment on YUNIKORN-1902 at 11/10/23 4:49 AM:
--------------------------------------------------------
it is a pity seeing that application crd will be removed, current, we plan to
use it as a sole scheduler in our data platform, and i plan to use it for
scheduling argo workflows, i may modify argo code to use the application crd
for integrating, even more，i think yunikorn could be the best choice for both
ai and bigdata usecases, we spend large time on researching volcano and
yunikorn, and finnaly we choose yunikorn as the scheduler, besides application
crd, i even expect yunikorn implement volcano's podgroup functions, but until i
see this issue, i think we will reconsider this scheduler... by the way, what
is the problem that matters most leading you make such a decision, exept for
maintaining different verions of k8s...
as i know, using only pod's taskGroups annotation and pod information can't
really reflect the application status, so a mechanism is needed, either like
spark operator that build with yunikorn knows diffent kinds of applications, or
and application crd that external controller can manipulate. yunikorn's queue
scheduling is fairly advanced than other schedulers in cloud native (for
examples, default-scheduler, scheduler-plugins), but i just wonder why it is
not popular than others (at least that's what I see), i think the key reason is
that yunikorn is not well intergrated with other polular operators and
frameworks, so i think we should keep the application crd, make it more
powerful, and pushing more projects to use or intergrate with it.
was (Author: JIRAUSER296225):
it is a pity seeing that application crd will be removed, current, we plan to
use it as a sole scheduler in our data platform, and i plan to use it for
scheduling argo workflows, i may modify argo code to use the application crd
for integrating, even more，i think yunikorn could be the best choice for both
ai and bigdata usecases, we spend large time on researching volcano and
yunikorn, and finnaly we choose yunikorn as the scheduler, besides application
crd, i even expect yunikorn implement volcano's podgroup functions, but until i
see this issue, i think we will reconsider this scheduler... by the way, what
is the problem that matters most leading you make such a decision, exept for
maintaining different verions of k8s...
as i know, using only pod's taskGroups annotation and pod information can't
really reflect the application status, so a mechanism is needed, either like
spark operator that build with yunikorn knows diffent kinds of applications, or
and application crd that external controller can manipulate.
> Remove Application CRD
> ----------------------
>
> Key: YUNIKORN-1902
> URL: https://issues.apache.org/jira/browse/YUNIKORN-1902
> Project: Apache YuniKorn
> Issue Type: Improvement
> Components: shim - kubernetes
> Reporter: Wilfred Spiegelenburg
> Assignee: PoAn Yang
> Priority: Major
> Labels: pull-request-available, release-notes
> Fix For: 1.4.0
>
>
> Remove the application CRD as per the discussion on the mailing list
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
