Tried Argo Workflow template with both timeout and activeDeadlineSeconds and this template also has retryStrategy. In both case, timeout are applied for each run but I want entire template should timeout within mentioned time. How to achieve this? Please comment in case the question is not clear.
kind: WorkflowTemplate
.
.
spec:
templates:
-name: taskA
activeDeadlineSeconds :30
retryStrategy:
limit: 2
.....
In this, all retry in case of timeout runs for 30sec each. But I wanted the entire workflowTemplate to timeout after 30 sec. Not 90sec. Is there any reference for this?
activeDeadlineSeconds can also be used in the Workflow/WorkflowTemplate level, see an example here.
Thanks got it. activeDeadlineSeconds can be used directly under spec: outside templates: level to achieve this.
Related
I have 3 argo workflow steps that I want to schedule always on the same node. Is it possible to limit execution of the 2nd and 3rd steps to the node that executed the 1st step? How can I get the executing node name/label during executing the step? Is this possible? My idea is I could put it into an output variable, then use that with a nodeSelector in the subsequent steps.
What I have currently is that all 3 steps are always scheduled on one designated node using :
spec:
templates:
- name: first-step
nodeSelector:
mycustomlabel: "true"
But the issue is this creates a CPU and disk space bottleneck.
Let's say I have two versions of chart Foo - v1 and v2. I had installed v1 (as revision 1) then upgraded to v2 (revision 2).
Now I'd like to rollback to first revision (helm rollback Foo 1). Is there any way to run job defined in v2 at some point of rollback after v1 resources are restored.
It must perform some actions on v1 resources because backwards incompatible changes made in v2.
I'd assume that pre-rollback hook defined in v2 should do the job. Unfortunetly chart lifecycle documentation is a bit confusing for me.
I tried to use
annotations:
"helm.sh/hook": post-rollback
as suggested in the answers. Unfortunately when I do rollback from v2 to v1 then v1's version of pre/post rollback job is executed. I need to execute job defined in v2 chart.
The following documentation and examples should clear up your confusion -
https://helm.sh/docs/topics/charts_hooks/#the-available-hooks
https://helm.sh/docs/topics/charts_hooks/#writing-a-hook
tldr
Add the following to the job you want to execute.
annotations:
"helm.sh/hook": post-rollback
pre-rollback is executed before any resources are created. Your desire state is to have that job to run on already created resources so you have to use post-rollback hook as described in the documentation:
post-rollback Executes on a rollback request after all resources have been modified
No it's not possible, Helm always uses hooks from target release, in this case from v1.
Here is part of my CronJob spec:
kind: CronJob
spec:
schedule: #{service.schedule}
For a specific environment a cron job is set up, but I never want it to run. Can I write some value into schedule: that will cause it to never run?
I haven't found any documentation for all supported syntax, but I am hoping for something like:
#never or #InABillionYears
#reboot doesn't guarantee that the job will never be run. It will actually be run always when your system is booted/rebooted and it may happen. It will be also run each time when cron daemon is restarted so you need to rely on that "typically it should not happen" on your system...
There are far more certain ways to ensure that a CronJob will never be run:
On Kubernetes level by suspending a job by setting its .spec.suspend field to true
You can easily set it using patch:
kubectl patch cronjobs <job-name> -p '{"spec" : {"suspend" : true }}'
On Cron level. Use a trick based on fact that crontab syntax is not strictly validated and set a date that you can be sure will never happen like 31th of February. Cron will accept that as it doesn't check day of the month in relation to value set in a month field. It just requires that you put valid numbers in both fields (1-31 and 1-12 respectively). You can set it to something like:
* * 31 2 *
which for Cron is perfectly valid value but we know that such a date is impossible and it will never happen.
kind: CronJob
spec:
suspend: true
Why do you need this to be a CronJob in the first place? If you never want it to run, you could specify a simple Job: https://kubernetes.io/docs/concepts/workloads/controllers/job/
I think you can use #reboot,
see: https://en.wikipedia.org/wiki/Cron
#reboot configures a job to run once when the daemon is started. Since cron is typically never restarted, this typically corresponds to the machine being booted.
What is the max size allowed for Environment variable (pod->container->Env) in kubernetes, assuming base ubuntu containers? I am unable to find the relevant documentation. Question might seem stupid, but, I do need the info to make my design robust.
So at bare minimum there is some 1,048,576 byte limitation imposed:
The ConfigMap "too-big" is invalid: []: Too long: must have at most 1048576 characters
which I generated as:
cat > too-big.yml<<FOO
apiVersion: v1
kind: ConfigMap
metadata:
name: too-big
data:
kaboom.txt: |
$(python -c 'print("x" * 1024 * 1024)')
FOO
And when I try that same stunt with a Pod, I'm met with a very similar outcome:
containers:
- image: ubuntu:18.10
env:
- name: TOO_BIG
value: |
$(python -c the same print)
standard_init_linux.go:178: exec user process caused "argument list too long"
So I would guess it's somewhere in between those two numbers: 0 and 1048576
That said, as the practically duplicate question answered, you are very, very likely solving the wrong problem. The very fact that you have to come to a community site to ask such a question means you are brining risk to your project that it will work one way on Linux, another way on docker, another way on kubernetes, and a different way on macOS.
The Kubernetes documentation mentions that a CronJob supports the use case of:
Once at a specified point in time
But, I don't see any examples of how this would be possible. Specifically, I'm looking to kick off a job to run once in N hours.
According to documentation, CronJob uses the common Cron format of schedule:
Here are some examples:
schedule: "1 2-14 * * 0-1,5-6" (first minute of every hour from 2am to 2pm UTC on Sun,Mon,Fri,Sat)
schedule: "*/1 * * * *" (every minute)
CronJobs also have some limitations:
A cron job creates a job object about once per execution time of its
schedule. We say “about” because there are certain circumstances where
two jobs might be created, or no job might be created. We attempt to
make these rare, but do not completely prevent them. Therefore, jobs
should be idempotent.
If startingDeadlineSeconds is set to a large value or left unset (the
default) and if concurrencyPolicy is set to Allow, the jobs will
always run at least once.
Jobs may fail to run if the CronJob controller is not running or
broken for a span of time from before the start time of the CronJob to
start time plus startingDeadlineSeconds, or if the span covers
multiple start times and concurrencyPolicy does not allow concurrency.
For example, suppose a cron job is set to start at exactly 08:30:00
and its startingDeadlineSeconds is set to 10, if the CronJob
controller happens to be down from 08:29:00 to 08:42:00, the job will
not start. Set a longer startingDeadlineSeconds if starting later is
better than not starting at all.
The Cronjob is only responsible for creating Jobs that match its
schedule, and the Job in turn is responsible for the management of the
Pods it represents.
The other important thing is that Kubernetes uses UTC exclusively. Make sure you take that into account when you’re creating your schedule.
To run a job just once, you can use kubectl create -f job.yaml started by at command on the admin machine or on the master node.
echo "kubectl create -f job.yaml" | at midnight
It is just as a regular CronJob object but using a format for the cronjob expression to run at a specific point in time:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: my-cronjob
namespace: kube-system
spec:
schedule: "7 7 7 7 6"
restartPolicy: OnFailure
jobTemplate:
...
for example this will run “At 07:07, Saturday 7th of July 2018.”
Next occurrence will be in 2029 so you have plenty of time to delete the cronJob object. That is, it will create a new job if you don't delete it as far and as I am aware there are no ways to avoid this.