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
Validate that cronjob names are 52 characters or less #52733
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:
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
I understand the commands that are listed here.
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> .
[APPROVALNOTIFIER] This PR is APPROVED
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:
You can indicate your approval by writing
Sep 23, 2017
11 of 13 checks passed
need to double-check this doesn't prevent update/delete of existing cronjobs with longer-than-52-char names before picking
@liggitt I just tested updating and deleting existing cronjobs with this patch. The results were:
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.
thanks for checking.
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)
no-op updates (get bytes/put bytes) are used to migrate storage (json->protobuf, v1beta1->v1, etc) during cluster upgrades, and should never fail
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):
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)