-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the custom "name" parameter from cluster resources. #1474
Conversation
d52ebb8
to
9820b08
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -62,11 +62,12 @@ func NewClusterResource(kubeconfigWriterImage string, r *PipelineResource) (*Clu | |||
clusterResource := ClusterResource{ | |||
Type: r.Spec.Type, | |||
KubeconfigWriterImage: kubeconfigWriterImage, | |||
Name: r.Name, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand this correctly, this uses the resource name as cluster name. Unfortunately this is not OK - which is the reason the name parameter was added - because the resource name must be a DNS valid name, while the cluster name may be not a valid DNS one e.g. my_cluster is a valid cluster name, but not a valid resource name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah thanks for the explanation. Can you explain why the cluster name matters in your case?
Leaving the name parameter would be fine I think as long as we write to the /workspace/resource-name path instead of the /workspace/cluster-name-param path.
I can't actually see the use case for cluster name though - it's only used inside the .kubeconfig AFAICT, and can be literally anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, indeed it doesn't seem to matter at all, sorry about my bad review :(
I tested if the cluster name is used at all when connecting to a OpenShift cluster on IBM Cloud - and it is not - see the cluster name set to foobar
|
The name of the cluster is actually not used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this.
Since this is done in a backward compatible way, it should be fine to merge it in v0.9.0
/lgtm
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bobcatfish The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
🏎️ |
This is redundant with the Name that Tasks already declare on Resources. The name is used both to name the cluster in the kubeconfig and to set the path for the kubeconfig. Using a name on the resource itself means Tasks can't know where to expect this file.
/lgtm |
This was deprecated in tektoncd#1474 which was released in 0.9.0. It can safely be deleted in the next release.
This was deprecated in tektoncd#1474 which was released in 0.9.0. It can safely be deleted in the next release.
This was deprecated in #1474 which was released in 0.9.0. It can safely be deleted in the next release.
Changes
This is redundant with the Name that Tasks already declare on Resources.
The name is used both to name the cluster in the kubeconfig and to set the
path for the kubeconfig. Using a name on the resource itself means Tasks can't
know where to expect this file.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes