Pod spec not able to process certain fields of CRDs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| juju |
High
|
Yang Kelvin Liu |
Bug Description
When creating a CRD through the kubernetes resources of the pod spec, an error is encountered when fields other than name, storage and served are present under "versions".
For example, with this CRD yaml file :
-----
apiVersion: apiextensions.
kind: CustomResourceD
metadata:
name: certificates.
labels:
serving.
knative.
spec:
group: networking.
versions:
- name: v1alpha1
served: true
storage: true
subresources:
status: {}
schema:
type: object
# this is a work around so we don't need to flush out the
# schema for each version at this time
#
# see issue: https:/
additiona
- name: Ready
type: string
jsonPath: ".status.
- name: Reason
type: string
jsonPath: ".status.
names:
kind: Certificate
plural: certificates
singular: certificate
categories:
- knative-internal
- networking
shortNames:
- kcert
scope: Namespaced
----
and with the kubernetes resources defined as :
k8s_resources={
]
}
}
Then The following error occurs:
creating or updating custom resource definitions: ensuring custom resource definition "certificates.
At first I thought it might be a problem specifically with the additionalPrint
controller-0: 20:45:47 ERROR juju.worker.
So I removed then the sections subresources, schema and additionalPrint
To compare the result, I was able to apply the original CRD file directly with kubectl without any issue. This points to a bug in how juju handles the CRD.
Let me know if any additional information is needed.
Ian Booth (wallyworld) wrote : | #1 |
Changed in juju: | |
milestone: | none → 2.9-rc4 |
importance: | Undecided → High |
status: | New → Triaged |
Ian Booth (wallyworld) wrote : | #2 |
I can confirm that using the non-beta v1 k8s API does allow a pod spec with this CRD to be deployed. Since there's only one version entry, you can easily adjust the CRD to conform to the beta1 syntax to get things working with juju 2.8
customResourc
- name: certificates.
spec:
scope: Namespaced
group: networking.
names:
kind: Certificate
plural: certificates
singular: certificate
- knative-internal
- networking
- kcert
versions:
- name: v1alpha1
served: true
schema:
# this is a work around so we don't need to flush out the
# schema for each version at this time
#
# see issue: https:/
- name: Ready
- name: Reason
Hi Ian, thanks for the quick update.
In the previous comment, you say that changing the version fixes the behavior. I tried changing the version name to either v1 or v1beta1 and I am still hitting the issue. The block you pasted still uses "v1alpha1". Which value did you mean to set it to?
Ian Booth (wallyworld) wrote : | #4 |
Sorry, I meant I had to change the juju code to use the updated k8s SDK APIs. The CRD as posted was from the bug description - I just added it to a pod spec to test that updating the SDK APIs juju uses allows the newer CRD format to be used.
Changed in juju: | |
assignee: | nobody → Yang Kelvin Liu (kelvin.liu) |
Changed in juju: | |
status: | Triaged → In Progress |
Changed in juju: | |
milestone: | 2.9-rc4 → 2.8.8 |
Yang Kelvin Liu (kelvin.liu) wrote : | #5 |
https:/
Changed in juju: | |
status: | In Progress → Fix Committed |
Changed in juju: | |
status: | Fix Committed → Fix Released |
Looks like you are hitting this bug
https:/ /github. com/kubernetes/ kubernetes/ issues/ 82443
Juju currently still uses "k8s.io/ apiextensions- apiserver/ pkg/apis/ apiextensions/ v1beta1"
Seems in k8s 1.16 v1 became available.
The above k8s bug does have a work around on how to structure the CRD until Juju can be updated.