[
https://issues.apache.org/jira/browse/YUNIKORN-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818928#comment-17818928
]
Craig Condit edited comment on YUNIKORN-1351 at 2/20/24 5:50 PM:
-----------------------------------------------------------------
IMO we need to find a balance between "rename everything" and "be as consistent
as possible". Renaming everything to match a standard is going to leave us
several legacy identifiers and is going to cause a lot of user confusion.
Removing these identifiers completely is really not practical as they are a
de-facto standard right now. Having two names (one namespaced and the other
not) doesn't cause much confusion - the namespaced identifier is clearly the
correct one. However, if we have multiple namespaced identifiers, it's unclear
which is the correct one to use.
So for example, Application ID being represented by 'applicationId' and
'yunikorn.apache.org/app-id' is fine (the namespaced version is clearly the
preferred one), but having both
'yunikorn.apache.org/schedulingPolicyParameters' and
'yunikorn.apache.org/scheduling-policy-parameters' would be going too far,
especially since the older version is baked into documentation and external
tooling. I think in the case where an existing *namespaced* ID exists, we
should use it, even if we would prefer slightly different naming conventions.
However, if we do not already have a namespaced version, we might as well use a
preferred syntax when creating the namespaced version.
was (Author: ccondit):
IMO we need to find a balance between "rename everything" and "be as consistent
as possible". Renaming everything to match a standard is going to leave us
several legacy identifiers and is going to cause a lot of user confusion.
Removing these identifiers completely is really not practical as they are a
de-facto standard right now. Having two names (one namespaced and the other
not) doesn't cause much confusion - the namespaced identifier is clearly the
correct one. However, if we have multiple namespaced identifiers, it's unclear
which is the correct one to use.
So for example, Application ID being represented by 'applicationId' and
'yunikorn.apache.org/app-id' is fine (the namespaced version is clearly the
preferred one), but having both
'yunikorn.apache.org/schedulingPolicyParameters' and
'yunikorn.apache.org/scheduling-policy-parameters' would be going to far,
especially since the older version is baked into documentation and external
tooling. I think in the case where an existing *namespaced* ID exists, we
should use it, even if we would prefer slightly different naming conventions.
However, if we do not already have a namespaced version, we might as well use a
preferred syntax when creating the namespaced version.
> 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: [email protected]
For additional commands, e-mail: [email protected]
