Strict parser for config file (with kube 1.16+ dependencies)

[sayboras]

Description

Fixes #1861 and #1602

https://github.com/kubernetes/apimachinery already supports strict parser as per kubernetes/apimachinery@162a2da. However, this is only available in kube 1.16, so I need to update all libraries to latest 1.16 version

Updated on 01-May-2020
As per today, EKS is supporting kube 1.16, so I think it's fair to upgrade the dependencies to 1.16.x, and eventually we can fix underlying validation issues.

Successfully create cluster

 ./eksctl create cluster --cfn-role-arn arn:aws:iam::335829250751:role/eks-deploy-role -f test.yaml
[ℹ]  eksctl version 0.16.0-dev+366d476b.2020-03-02T20:26:40Z
[ℹ]  using region ap-southeast-2
[✔]  using existing VPC (vpc-0a178e4feaf59402a) and subnets (private:[subnet-019189ea518da77dd subnet-091038e3e8fd3f017 subnet-01ebb50bfc820147d] public:[subnet-09d2955928d4bd27c subnet-0a07e6b103738d091 subnet-03c2160f5cef2cdd7])
[!]  custom VPC/subnets will be used; if resulting cluster doesn't function as expected, make sure to review the configuration of VPC/subnets
[ℹ]  using Kubernetes version 1.14
[ℹ]  creating EKS cluster "test-kube-1-16-7-lib" in "ap-southeast-2" region with managed nodes
[ℹ]  1 nodegroup (standard-workers) was included (based on the include/exclude rules)
[ℹ]  will create a CloudFormation stack for cluster itself and 0 nodegroup stack(s)
[ℹ]  will create a CloudFormation stack for cluster itself and 1 managed nodegroup stack(s)
[ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=ap-southeast-2 --cluster=test-kube-1-16-7-lib'
[ℹ]  CloudWatch logging will not be enabled for cluster "test-kube-1-16-7-lib" in "ap-southeast-2"
[ℹ]  you can enable it with 'eksctl utils update-cluster-logging --region=ap-southeast-2 --cluster=test-kube-1-16-7-lib'
[ℹ]  Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "test-kube-1-16-7-lib" in "ap-southeast-2"
[ℹ]  2 sequential tasks: { create cluster control plane "test-kube-1-16-7-lib", create managed nodegroup "standard-workers" }
[ℹ]  building cluster stack "eksctl-test-kube-1-16-7-lib-cluster"
[ℹ]  deploying stack "eksctl-test-kube-1-16-7-lib-cluster"
[ℹ]  building managed nodegroup stack "eksctl-test-kube-1-16-7-lib-nodegroup-standard-workers"
[ℹ]  deploying stack "eksctl-test-kube-1-16-7-lib-nodegroup-standard-workers"
[✔]  all EKS cluster resources for "test-kube-1-16-7-lib" have been created
[✔]  saved kubeconfig as "/home/tammach/.kube/config"

Wrong case in configuration file

./eksctl create cluster -f test_invalid.yaml                                                      
Error: loading config file "test_invalid.yaml": strict decoder error for apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: eksworkshop-eksctl
  region: us-west-2

ManagedNodeGroups:
  - name: eksworkshop-eksctl-ng1
    labels: { role: workers }
    instanceType: m5.large
    desiredCapacity: 3
    minSize: 3
    maxSize: 3
    ssh:
      allow: true
    iam:
      withAddonPolicies:
        imageBuilder: true
        albIngress: true
        autoScaler: true
        appMesh: true
        xRay: true
        cloudWatch: true
        externalDNS: true
: v1alpha5.ClusterConfig.ReadObject: found unknown field: ManagedNodeGroups, error found in #10 byte of ...|odeGroups":[{"desire|..., bigger context ...|{"ManagedNodeGroups":[{"desiredCapacity":3,"iam":{"withAddonPolicies":|...

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the site/content directory)
• Manually tested
• Added labels for change area (e.g. area/nodegroup), target version (e.g. version/0.12.0) and kind (e.g. kind/improvement)
• Make sure the title of the PR is a good description that can go into the release notes

[sayboras]

@martina-if @cPu1 whenever you have time, your input is highly appreciated 🎉

[martina-if]

Hi @sayboras , I think we should not make the config file parser strict yet until we decide how we want to deal with multiple schema versions. If we make the parser strict that will make forward compatibility impossible so I think it's better to close this for now.

[sayboras]

@martina-if I have very limited idea on supporting multiple API versions. Normally, I just go ahead with different loaders :)

Sure, let me close this one for now, I can re-open it once I have better understanding 💯