Validate that cronjob names are 52 characters or less

[julia-stripe]

What this PR does / why we need it:

Right now when you create a cronjob with a name longer than 52 characters, creation will succeed but the cronjob controller will create Job objects with names longer than 63 characters. Jobs cannot have names longer than 63 characters, so the cronjob will never be able to run any jobs.

Which issue this PR fixes : Fixes #50850

Special notes for your reviewer:

Release note:

Validate that cronjob names are 52 characters or less

[k8s-ci-robot]

Hi @julia-stripe. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[julia-stripe]

cc @soltysh

[soltysh]

/ok-to-test
/assign

[soltysh]

Replace that maybe with DNS1035LabelMaxLength-11 from k8s.io/apimachinery/pkg/util/validation package.

[soltysh]

'must be no more than 52 characters' - to keep it consistent with other error messages

[julia-stripe]

@soltysh thanks, made those changes! take another look?

[julia-stripe]

/retest

[soltysh]

/lgtm

[soltysh]

@julia-stripe thank you!

[julia-stripe]

It changed because I forgot to run go fmt before

[julia-stripe]

/retest

[soltysh]

/lgtm

[soltysh]

Eric mind approving this one, this is hardening the cronjob name validation, but that's better than failing to create a job.

/assign @erictune

[dims]

/assign @thockin

[thockin]

Blech. Does this mean we can never ever change the naming format that it uses for pod names? We have this same pattern for deployments and replicasets, should we formalize this derivative-name pattern?

…

On Wed, Sep 20, 2017 at 3:43 AM, Davanum Srinivas ***@***.***> wrote: /assign @thockin <https://github.com/thockin> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#52733 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVO9VxIAD_h44pj6YyVBFroB-ROCUks5skOxIgaJpZM4PcmLA> .

[thockin]

Job creates Pods which have further suffixes, right? And Pod names also are limited in size.

[julia-stripe]

Pod names' size limits are 255 characters, like most Kubernetes resources. As far as I can tell only job names have a size limit of 63 characters (because job names get copied in to a label, which have a lower size limit than Kubernetes resource names).

[dims]

@thockin go or no-go for 1.8 please - #52733

[dims]

@julia-stripe @soltysh @thockin @erictune - ok to move this out of 1.8?

[thockin]

I'll OK this for now, but I'd like to revisit this topic as part of 1.9. Can I count on you @julia-stripe to bring up back up?

@erictune @kow3ns

[thockin]

/approve

[k8s-merge-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: julia-stripe, soltysh, thockin

Associated issue: 50850

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

• pkg/apis/OWNERS [thockin]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[abgworrall]

This missed the final ffwd for release-1.8, so will need to be cherrypicked in afterwards. It will not be in the release-candidate for 1.8; ping me on slack now if that is a problem ...

[liggitt]

Does this prevent updating an existing cronjob? That can block addition/removal of finalizers during deletion

[k8s-merge-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-merge-robot]

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here..

[abgworrall]

Just to followup - this was merged into master, but not into release-1.8. You'll need to cherrypick it into 1.8; it'll get approved, as it was just bad timing that meant it missed the 1.8 boat.

[liggitt]

Just to followup - this was merged into master, but not into release-1.8. You'll need to cherrypick it into 1.8; it'll get approved, as it was just bad timing that meant it missed the 1.8 boat.

need to double-check this doesn't prevent update/delete of existing cronjobs with longer-than-52-char names before picking

[julia-stripe]

@liggitt I just tested updating and deleting existing cronjobs with this patch. The results were:

• Deleting the cronjob succeeds. (cronjob "100000000010000000001000000000100000000010000000001000000000" deleted)
• Updating the cronjob fails (The CronJob "100000000010000000001000000000100000000010000000001000000000" is invalid: metadata.name: Invalid value: "100000000010000000001000000000100000000010000000001000000000": must be no more than 52 characters)

My view is that it's okay that cronjob updates fail (and in fact preferable). If I have an invalid cronjob in my cluster, I'd prefer to be notified when updating it that it's invalid than continue having a job that I don't know is broken. Previously we had cronjobs in our cluster that were not running because of this issue and we didn't know about it which was a pretty scary state to be in.

[liggitt]

thanks for checking.

Deleting the cronjob succeeds.

if updating fails, it is likely that deleting with a foreground propagation policy would fail as well (this adds a finalizer to the object, which requires doing an update)

Updating the cronjob fails

no-op updates (get bytes/put bytes) are used to migrate storage (json->protobuf, v1beta1->v1, etc) during cluster upgrades, and should never fail

[julia-stripe]

no-op updates (get bytes/put bytes) are used to migrate storage (json->protobuf, v1beta1->v1, etc) during cluster upgrades, and should never fail

Makes sense. How do you recommend dealing with this?

[liggitt]

Validation-wise, I'd recommend just validating the shorter name restriction on creation (names are immutable once created, so this would keep new bad data from entering the system, while allowing migrating/deleting old bad data):

1. make a ValidateCronJobUpdate (we really should have had this already)

   func ValidateCronJobUpdate(job, oldJob *batch.CronJob) field.ErrorList {
   	allErrs := apivalidation.ValidateObjectMetaUpdate(&job.ObjectMeta, &oldJob.ObjectMeta,     field.NewPath("metadata"))
   	allErrs = append(allErrs, ValidateCronJobSpec(&job.Spec, field.NewPath("spec"))...)
   	return allErrs
   }

2. change cronJobStrategy#ValidateUpdate to call ValidateCronJobUpdate instead

longer-term, we should work to make failing cronjobs more visible. there are lots of potential reasons cronjobs could fail, not just invalid names, so we need to surface this sort of case much more visibly (better error status on the cronjob object, events in namespace, etc)

[liggitt]

cc @soltysh for visibility on failing cronjobs

[liggitt]

Validation-wise, I'd recommend just validating the shorter name restriction on creation

FYI, opened #52967 to do this. If this is picked into 1.8, I think that should be as well

[jpbetz]

@liggitt Is this ready to be cherry picked to 1.8? Or do we need to wait on #52967?

[liggitt]

if this is picked to 1.8, #52967 should be as well