[
https://issues.apache.org/jira/browse/YUNIKORN-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818924#comment-17818924
]
Yu-Lin Chen edited comment on YUNIKORN-1351 at 2/20/24 5:51 PM:
----------------------------------------------------------------
Hi [~ccondit],
Dose "define canonical representation" mean we'll allow old/new identifier to
coexist, and nothing will be deprecated?
{quote}1) ...... However we should not rename existing already-namespaced
identifiers, as this will just cause further confusion.
{quote}
IMO, if we decide to go with canonical representations, I believe that applying
canonical representation to everything is more consistent and causes less
confusion. Including existing already-namespaced identifiers.
For example, below existing annotations can create a new renamed canonical
presentation:
- yunikorn.apache.org/{color:#0747a6}scheduling-policy-parameters{color}
(New)(Canonical)
- yunikorn.apache.org/schedulingPolicyParameters (Old)
- {color:#0747a6}internal.{color}yunikorn.apache.org/placeholder
(New)(Canonical)
- yunikorn.apache.org/placeholder (Old)
{quote}4) We should NOT complicate matters by changing annotations on
namespaces, only on pods.
{quote}
Just checked those Not-On-Pod annotations.
* yunikorn.apache.org/namespace.quota (Set on namespace)
* yunikorn.apache.org/parentqueue (Set on namespace)
* yunikorn.apache.org/allow-preemption (Can be set on PriorityClass)
* yunikorn.apache.org/namespace.enableYunikorn (Set on namespace)
* yunikorn.apache.org/namespace.generateAppId (Set on namespace)
IMO, if we decide to go with canonical representation. Like I just mentioned.
I believe that applying canonical representation to everything is more
consistent and causes less confusion.
But the change is huge. Does the confusion you mentioined mean "too many equal
identifier coexist"?
If so, I'm neutral about applying 'canonical representations' to everything.
Looking forward to others feedback.
was (Author: yu-lin chen):
Hi [~ccondit],
Dose "define canonical representation" mean we'll allow old/new identifier to
coexist, and nothing will be deprecated?
{quote}1) ...... However we should not rename existing already-namespaced
identifiers, as this will just cause further confusion.
{quote}
IMO, if we decide to go with canonical representations, I believe that applying
cononical representation to everything is more consistent and causes less
confusion. Including existing already-namespaced identifiers.
For example, below existing annotations can create a new renamed cannonocal
presentation:
- yunikorn.apache.org/{color:#0747a6}scheduling-policy-parameters{color}
(New)(Canonical)
- yunikorn.apache.org/schedulingPolicyParameters (Old)
- {color:#0747a6}internal.{color}yunikorn.apache.org/placeholder
(New)(Canonical)
- yunikorn.apache.org/placeholder (Old)
{quote}4) We should NOT complicate matters by changing annotations on
namespaces, only on pods.
{quote}
Just checked those Not-On-Pod annotations.
* yunikorn.apache.org/namespace.quota (Set on namespace)
* yunikorn.apache.org/parentqueue (Set on namespace)
* yunikorn.apache.org/allow-preemption (Can be set on PriorityClass)
* yunikorn.apache.org/namespace.enableYunikorn (Set on namespace)
* yunikorn.apache.org/namespace.generateAppId (Set on namespace)
IMO, if we decide to go with cononical representation. Like I just mentioned.
I believe that applying cononical representation to everything is more
consistent and causes less confusion.
But the change is huge. Does the confusion you mentioined mean "too many equal
identifier coexist"?
If so, I'm neutral about applying 'canonical representations' to everything.
Looking forward to others feedback.
> Define policy for when to use annotations vs. labels
> ----------------------------------------------------
>
> Key: YUNIKORN-1351
> URL: https://issues.apache.org/jira/browse/YUNIKORN-1351
> Project: Apache YuniKorn
> Issue Type: Improvement
> Components: shim - kubernetes
> Reporter: Wilfred Spiegelenburg
> Assignee: Yu-Lin Chen
> Priority: Major
> Labels: newbie, pull-request-available
> Attachments: [Design Doc] Define Usage of Labels and Annotations in
> YuniKorn.pdf
>
>
> Currently, we have very inconsistent use of labels vs. annotations in
> YuniKorn. Additionally, some values are namespaced under yunikorn.apache.org
> while some are not. We will likely need to keep legacy values around for
> backwards compatibility but we should define a strategy for defining
> canonical representations of this metadata as well as a developer-oriented
> pollcy around when to use labels vs. annotations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@yunikorn.apache.org
For additional commands, e-mail: issues-h...@yunikorn.apache.org
