kubernetes: kubectl validation fails when creating a non-v1 object in a v1 list
In other words, you can’t create/replace/delete/apply deployments with kubectl if they’re in a list.
Works as expected:
$ cat nginx-rc.yaml
apiVersion: v1
kind: List
items:
- apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 1
template:
metadata:
labels:
name: nginx
spec:
containers:
- name: nginx
image: nginx
$ kubectl create -f nginx-rc.yaml
replicationcontroller "nginx" created
Does not work as expected:
$ cat nginx-dpl.yaml
apiVersion: v1
kind: List
items:
- apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 1
template:
metadata:
labels:
name: nginx
spec:
containers:
- name: nginx
image: nginx
$ kubectl create -f nginx-dpl.yaml
error validating "nginx-dpl.yaml": error validating data: couldn't find type: v1beta1.Deployment; if you choose to ignore these errors, turn validation off with --validate=false
$ kubectl create -f nginx-dpl.yaml --validate=false
deployment "nginx" created
This is a high priority issue for us, since it means we can’t (easily) use apply (or any kubectl command) with lists of JSON objects since we’ve moved all our replication controllers over to deployment objects, which is hampering the UX of our config efforts.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 26 (22 by maintainers)
Commits related to this issue
- Kubectl support for validating nested objects with different ApiGroups #24089 — committed to pwittrock/kubernetes by pwittrock 8 years ago
We need Lists to work - I think they’re fundamental to stuff going forward (like templates, which are a variant of lists)
On Tue, Apr 19, 2016 at 10:58 PM, TonyAdo notifications@github.com wrote:
A v1 list can contain any object under the sun. If validation is assuming a v1 object contains only v1 objects then it’s broken. The Items under a list should be considered
any
in swagger - if we have other objects in the future that can contain opaque objects we’re going to need to ensure swagger validation properly identifies sub objects. Special casing List isn’t enough (since there’s PodList, ServiceList, etc which are valid for piping from export -> create).