Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Limit pod name to 63 characters, and shorten randomly generated string #143
This PR has two small changes. Hope that it's alright that they're both in one PR. They're closely related.
The first fixes a bug where the plugin fails to use a pod if the pod's name is over 63 characters. I believe this is due to the fact that the JNLP container has a max hostname of 64 bytes (including the null terminator).
As as a result, when
The second change makes the random string appended to the end of the pod name more like Kubernetes' string generation. With this PR, only 5 characters are appended (or replaced if it exceeds the max length) to the end of the string.
@austinmoore-: I think that here lies an issue that I missed in my original review. The PodTemplate that we generate using the pipeline is added to the
So I am considering reverting just that part of the commit to how it used to be.
@iocanel: Hey, sorry you're seeing problems with the PR. I'm happy to help fix these issues. I haven't had time to dive into code looking for you've said yet but wanted to get some clarification from things off the top of my head.
I frequently launch jobs with the same name, but a different label. Also, if left unspecified the name "kubernetes" is chosen by default. As long as the label is unique it works. In what ways are you seeing the names conflict?
Also, what specific part of the commit are you thinking of reverting? Some context might help me understand these problems.
No worries. It was a step to the right direction, with just some minor details that needed to be addressed.
Instantiating the template is usually done via node that uses a label, so no issues there. But when we are nesting podTemplates or use the
Anyway, I pushed a fix into the master which I think resolves the issue: bf245fe