Skip to content
This repository has been archived by the owner on Jan 19, 2018. It is now read-only.

Backward compatibility regarding new parameters in Kubernetes 1.2 #674

Open
kadel opened this issue Apr 6, 2016 · 1 comment
Open

Backward compatibility regarding new parameters in Kubernetes 1.2 #674

kadel opened this issue Apr 6, 2016 · 1 comment

Comments

@kadel
Copy link
Collaborator

kadel commented Apr 6, 2016

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.

@cdrage
Copy link
Member

cdrage commented Apr 6, 2016

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 #658 (to grab the config file) and #653

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants