By default if job misses 100 times it's scheduled successful execution (due to jobs's unexpectedly long run or temporal network error) then cronjob gets stuck and do not schedule new jobs anymore. startingDeadlineSeconds setting ensures that failed job executions are only counted within last 600 seconds and thus not reaching the limit. For cron schedules below 1 minutes one should consider to override default with lower value.

More info:

• kubernetes/kubernetes#39608
• https://cloud.google.com/kubernetes-engine/docs/how-to/cronjobs
• https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

Allow user to supply multiple external files to the cronjob.

Related comment:
#23 (comment)

Move Travis scripts to ci-templates folder:

gcloud-login.sh
gcloud-install-sdk.sh
common.sh
gcloud-push-image.sh

Description

According to kubernetes helm recommendations an application won't get redeployed if only secrets file is changed.

Solution

It is recommended to add these lines to solve the problem:

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/secrets.yaml") . | sha256sum }}
[...]

According to documentation not definition of "resources" is valid and allow to apply different resource management techniques: https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

By enforcing its definition here we restrict users to particular techniques only: https://github.com/commercetools/k8s-charts/blob/master/charts/logentries/values.yaml#L25

We should not requires resources

In the Travis example scripts we have a file gcloud-deploy.sh which is currently able to deploy only one job.

The name of this job is taken from env variable HELM_CHART_TEMPLATE_NAME configured here in travis.yaml.

It would be cool if we can extend the script so it can deploy multiple services or to accept the job name via parameter so we can call it like this:

bash $CI_SCRIPTS/gcloud-deploy.sh "production" job1
bash $CI_SCRIPTS/gcloud-deploy.sh "production" job2

Instead of this:

HELM_CHART_TEMPLATE_NAME=cronjob_1 bash $CI_SCRIPTS/gcloud-deploy.sh "production"
HELM_CHART_TEMPLATE_NAME=cronjob_2 bash $CI_SCRIPTS/gcloud-deploy.sh "production"

Set recommended resource limits for the logentries pod in the logentries chart.

I sent an e-mail to the support of logentries to get a recommendation for the resources of a running logentries container. Let's wait for an answer and accordingly maybe set a default value for the resource limits and requests of the logentries pod.

We had a problem before that was explained in this PR: #32

The PR above should have fixed the problem, but it did not. The problem is still here and it failed us on commit with hash 574985703c044b969a5e8bd3231351a5d8e59e6c. It produces a image tag 5.749857e+07, which is not valid.