atomicapp icon indicating copy to clipboard operation
atomicapp copied to clipboard

Backward compatibility regarding new parameters in Kubernetes 1.2

Open kadel opened this issue 9 years ago • 1 comments

Kubernetes 1.2 added new configuration parameters for liveness and readiness probes: periodSeconds, successThreshold, failureThreshold.

If you define object with any of those parameters for example like this:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - args:
    - /bin/sh
    - -c
    - echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600
    image: gcr.io/google_containers/busybox
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/health
      initialDelaySeconds: 15
      timeoutSeconds: 1
      periodSeconds: 15
    name: liveness

Now if you want to deploy this to using kubectl older then 1.2 it fails on error validating "test.yaml": error validating data: found invalid field periodSeconds for v1.Probe; if you choose to ignore these errors, turn validation off with --validate=false

This is problem for Atomic App as we are currently using kubectl to deploy kubernetes artifacts. When Nulecule artifacts contains one of the new parameters Atomic App fails:

AtomicAppUtilsException: cmd: ['/host/usr/bin/kubectl', 'create', '-f', u'/host/var/lib/atomicapp/10.1.2.1-5000-mlbparks-mlbparks1-7b82edcaa7fb/artifacts/kubernetes/.mlbparks-1-ReplicationController.json', '--namespace=default'] failed: 
error validating "/host/var/lib/atomicapp/10.1.2.1-5000-mlbparks-mlbparks1-7b82edcaa7fb/artifacts/kubernetes/.mlbparks-1-ReplicationController.json": error validating data: [found invalid field successThreshold for v1.Probe, found invalid field periodSeconds for v1.Probe, found invalid field failureThreshold for v1.Probe]; if you choose to ignore these errors, turn validation off with --validate=false

Only solution for this is to add --validate=false to kubectl. This turns client side validations off. Whole object is than pass down to server. Kubernetes api-server validation is apparently less strict and it ignores unknown parameters.

When using api directly this problems doesn't exist. Because it is not going thought kubectl validation.

I don't know how far is @cdrage with new kubernetes provider, it is going to fix this. But until then I propose to add --validate=false to all kubectl crate calls.

kadel avatar Apr 06 '16 12:04 kadel

Hey @kadel

So @dustymabe and I recently had a meeting in regards to pykube (which is what we plan to use for the Kubernetes provider with the Ansible guys.

At the moment it looks like a good route to go in implementing the cli -> api conversion. I've been contributing upstream to the project in order to get it up to par for 1.2, I believe at this moment all new features from 1.2 have been implemented into pykube.

Just going to wait for them to release a new version and then we can add it to atomicapp via pip.

Otherwise, the progress has been going on in https://github.com/projectatomic/atomicapp/pull/658 (to grab the config file) and https://github.com/projectatomic/atomicapp/pull/653

cdrage avatar Apr 06 '16 13:04 cdrage