[ 
https://issues.apache.org/jira/browse/YUNIKORN-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818872#comment-17818872
 ] 

Craig Condit edited comment on YUNIKORN-1351 at 2/20/24 3:43 PM:
-----------------------------------------------------------------

Some thoughts on the first design doc rev:

1) Everything we define moving forward should have a namespace 
({*}{{yunikorn.apache.org}}{*} for public properties; 
*{{internal.yunikorn.apache.org}}* for internal ones). We should also 
standardize on hyphenated lowercase identifiers for consistency (we currently 
have a mix of camelCase, dot.case and hypen-case identifiers). *However* we 
should not rename existing already-namespaced identifiers, as this will just 
cause further confusion.

2) We need to be careful about the "deprecated" status – we have lots of 
third-party components that use the older forms; it could be a very long time 
(if ever) before these get updated. It would be better to define a "canonical" 
representation (i.e. the one that should be used moving forward).

3) In the case where we have multiple representations moving forward, we should 
define a policy that any of them are acceptable; however if more than one is 
specified, their values *must* be the same. It should be considered invalid 
(for example) to have two different application IDs defined using two different 
labels or annotations.

4) We should NOT complicate matters by changing annotations on namespaces, only 
on pods.

 

As for the some of the values themselves, here is what I would propose as the 
canonical representations:
 * Application ID
 ** Currently in use: applicationId (label), yunikorn.apache.org/app-id 
(annotation)
 ** Proposed canonical representation: *yunikorn.apache.org/app-id (label)*
 ** Why: The namespaced value is good, however application ID is often used as 
a selector.
 * Queue
 ** Currently in use: queue (label), yunikorn.apache.org/queue (annotation)
 ** Proposed canonical representation: *yunikorn.apache.org/queue (label)*
 ** Why: The namespaced value is good, however selecting applications by queue 
is useful.

 


was (Author: ccondit):
Some thoughts on the first design doc rev:

1) Everything we define moving forward should have a namespace 
({*}{{yunikorn.apache.org}}{*} for public properties; 
*{{internal.yunikorn.apache.org}}* for internal ones). We should also 
standardize on hyphenated lowercase identifiers for consistency (we currently 
have a mix of camelCase, dot.case and hypen-case identifiers).

2) We need to be careful about the "deprecated" status – we have lots of 
third-party components that use the older forms; it could be a very long time 
(if ever) before these get updated. It would be better to define a "canonical" 
representation (i.e. the one that should be used moving forward).

3) In the case where we have multiple representations moving forward, we should 
define a policy that any of them are acceptable; however if more than one is 
specified, their values *must* be the same. It should be considered invalid 
(for example) to have two different application IDs defined using two different 
labels or annotations.

4) We should NOT complicate matters by changing annotations on namespaces, only 
on pods.

 

As for the some of the values themselves, here is what I would propose as the 
canonical representations:
 * Application ID
 ** Currently in use: applicationId (label), yunikorn.apache.org/app-id 
(annotation)
 ** Proposed canonical representation: *yunikorn.apache.org/app-id (label)*
 ** Why: The namespaced value is good, however application ID is often used as 
a selector.
 * Queue
 ** Currently in use: queue (label), yunikorn.apache.org/queue (annotation)
 ** Proposed canonical representation: *yunikorn.apache.org/queue (label)*
 ** Why: The namespaced value is good, however selecting applications by queue 
is useful.

 

> 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

Reply via email to