What is the reason to create pod without specifiing image / creating container? Please provide a use case when such functionality is necessry.

@bronislav - to me it's not necessary. However if it's not supported, a validation should prevent it not to allow corrupted entities. And if it is supported, it will be good to understand why.
For instance, service with nil selector is supported, though it might not make sense to some users.
see this: #3712

Yes, it should be allowed, and I'm pretty sure it used to work. Could you please post your object schema here or somewhere?

@bgrant0607 what do you mean by object schema? an example json of such pod or something broader?
and btw what meaning a pod has without containers?

cc @itamarh @simon3z

@dchen1107 @thockin I'm fine with banning this for now. The use cases where it would be useful (e.g., reserving resources, staging deployment, prefetching images, ...) aren't currently well supported. When we add the features that could take advantage of this (e.g., pod-level resources, additional of containers during update, container volumes, pod/volume init hooks), then we can make it legal again at that point.

@bgrant0607 in that case, a clear error message coming from REST would be in place when a pod with no containers is recieved by the server :)

I'll look into this.

@bgrant0607 AFAIU we want to return meaningful error if user specifies pod with no containers. Is my understanding correct?

@fgrzadkowski Correct.

We should do it in validateContainers:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/api/validation/validation.go#L533

cc @mfojtik

@bgrant0607, should we document this somewhere (e.g. api/v1betaX/types.go?). Validation is not versioned, so any change would apply to all existing APIs.

Yes, it should be documented, in the field descriptions, such as:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/api/v1beta3/types.go#L566

I'll send a PR for this.

cc @zeari