-
Notifications
You must be signed in to change notification settings - Fork 54
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
Validate the generated job names will be dns 1035 compliant #284
Validate the generated job names will be dns 1035 compliant #284
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danielvegamyhre 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 |
cbd9860
to
e0e9a54
Compare
/retest |
cc @kannon92 am I correct this is considered a breaking change? |
Yea I think making validation more strict would be considered a breaking change. OTOH I think having validation to catch errors is a much better UX than failing in reconcile and having someone edit the yaml. So I don’t think this is being a breaking change should hold it. I was bringing up that in k/k this would be a difficult change to push through. Usually you would want to guarantee that this wouldn’t break any existing users who may have relied on this (prob unlikely). I’d like to hear what @ahg-g thinks of changes like this. |
@@ -101,6 +101,12 @@ func (js *JobSet) ValidateCreate() (admission.Warnings, error) { | |||
if int64(parallelism)*int64(rjob.Replicas) > math.MaxInt32 { | |||
allErrs = append(allErrs, fmt.Errorf("the product of replicas and parallelism must not exceed %d for replicatedJob '%s'", math.MaxInt32, rjob.Name)) | |||
} | |||
// Check that the generated job names for this replicated job will be DNS 1035 compliant. | |||
// Use job index 0 as the test example. |
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.
I find this comment concerning. I guess you are just validating a single job (as all others will fail since replica won't change the dns issue. But the comment test example
and testJobName
make it seem like this is leftover remnants of testing.
Maybe we can use rjob.Replicas - 1
or something like that. At least we pick the worst case to fail. I wonder if it would ever be possible that -0 case would pass but -(replicas - 1) would fail. I imagine that replicas-1 passing would mean that everything else should pass.
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.
Good point! The length of the job name with the largest job index will be >= the longest job name in the replicatedJob. I updated the test to use that instead of job index 0, since there are certain cases where job index 0 length is less than 63 chars but job index replicas-1
is not.
@@ -101,6 +101,12 @@ func (js *JobSet) ValidateCreate() (admission.Warnings, error) { | |||
if int64(parallelism)*int64(rjob.Replicas) > math.MaxInt32 { | |||
allErrs = append(allErrs, fmt.Errorf("the product of replicas and parallelism must not exceed %d for replicatedJob '%s'", math.MaxInt32, rjob.Name)) | |||
} | |||
// Check that the generated job names for this replicated job will be DNS 1035 compliant. | |||
// Use job index 0 as the test example. | |||
testJobName := fmt.Sprintf("%s-%s-%d", js.Name, rjob.Name, 0) |
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.
can we have a shared func between the webhook and the controller for name generation just so when changes are made, they get reflected in both places.
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.
Ok in order to avoid an import/dependency cycle, I had to create a shared util function. However, it didn't seem to fit into any of our existing util pacakges (util/test, util/cert, util/collections) so I made a new one: pkg/util/names
. I tried to add GenSubdomain()
into it as well, but it results in an import cycle as well, and unlike GenJobName
there's no easy fix, so I left it out.
Let me know if you have any thoughts on this.
e0e9a54
to
efb7a4d
Compare
I think this looks good to me but I'll leave lgtm for @ahg-g |
17d667f
to
4d164e0
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.
One comment https://github.com/kubernetes-sigs/jobset/pull/284/files#r1313274666
/lgtm
/hold
if you want to ignore the comment
/lgtm |
Fixes #283