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.
