-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug(apply): unable to apply K8s CRD using recipe #186
Comments
Following yaml when applied via Recipe code should result in error: apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: mayastorpools.openebs.io
spec:
group: openebs.io
versions:
- name: v1alpha1
served: true
storage: true
subresources:
status: {}
schema:
openAPIV3Schema:
type: object
properties:
apiVersion:
type: string
kind:
type: string
metadata:
type: object
spec:
description: Specification of the mayastor pool.
type: object
required:
- node
- disks
properties:
node:
description: Name of the k8s node where the storage pool is located.
type: string
disks:
description: Disk devices (paths or URIs) that should be used for the pool.
type: array
items:
type: string
status:
description: Status part updated by the pool controller.
type: object
properties:
state:
description: Pool state.
type: string
reason:
description: Reason for the pool state value if applicable.
type: string
disks:
description: Disk device URIs that are actually used for the pool.
type: array
items:
type: string
capacity:
description: Capacity of the pool in bytes.
type: integer
format: int64
minimum: 0
used:
description: How many bytes are used in the pool.
type: integer
format: int64
minimum: 0
additionalPrinterColumns:
- name: Node
type: string
description: Node where the storage pool is located
jsonPath: .spec.node
- name: State
type: string
description: State of the storage pool
jsonPath: .status.state
- name: Age
type: date
jsonPath: .metadata.creationTimestamp
scope: Namespaced
names:
kind: MayastorPool
listKind: MayastorPoolList
plural: mayastorpools
singular: mayastorpool
shortNames: ["msp"] |
Errors while unmarshaling yaml string to unstructured & CRD typeError: Failed to unmarshal: : error converting YAML to JSON: yaml: line 7: found character that cannot start any token
Remedy: remove tab spacing for 4 single spaces
NOTE: This had to be done throughout either manually or via some tool Error: Failed to convert to CRD type: cannot convert int64 to float64
Note: There is no information on the line or field that is leading to this error
Note: YAML string to unstructured was done via github.com/ghodss/yaml
Note: ghodss/yaml lib does not take into account unstructured datatypes supported by K8s lib
e.g. K8s supports int64 instead of int
- If unstructured makes use of 0 then it is considered as int
- int is an invalid type as per k8s lib
- Right way is to typecast above to int64(0) Errors applying (create & update) unstructured instances to k8s clusterIn this case, string boolean was used instead of bool & hence below error "versions": []interface{}{
map[string]interface{}{
"name": "v1alpha1",
"served": "true", // error
"storage": true, // ok
},
}, --- FAIL: TestCRDApply (1.03s)
crd_int_test.go:171: Error while testing: CustomResourceDefinition in version "v1"
cannot be handled as a CustomResourceDefinition: v1.CustomResourceDefinition.Spec:
v1.CustomResourceDefinitionSpec.Versions: []v1.CustomResourceDefinitionVersion:
v1.CustomResourceDefinitionVersion.Served: ReadBool: expect t or f, but found ",
error found in #10 byte of ...|"served":"true","sto|..., bigger context
...|"}},"type":"object"}},"type":"object"}},"served":"true","storage":true,"subresources":{"status":
{}}}|...: %!s(*types.ApplyResult=<nil>)
FAIL Conclusion
|
AmitKumarDas
pushed a commit
to AmitKumarDas/d-operators
that referenced
this issue
Jan 1, 2021
This commit makes exhaustive changes to handle CRD instances. CRD instances make use of unstructured types instead of typed instances. Both CRD versions i.e. v1beta1 & v1 are supported. Unstructured instances have proved to be generic & testable versus the typed counterparts especially for CRD schemas that can differ from each other. In other words, CRD schemas have a majority schemaless section that is well handled via unstructured type. This commit also includes a number of integration test cases to avoid bug injections if any. This closes mayadata-io#186 partially. A better approach will be to use latest version of d-operators with clients that make use of unstructured instances directly instead of yaml strings that get converted to go structures. This commit is also a breaking change, since some of the structures have been modified. Clients that are already making use of this structure need to be modified accordingly. Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
AmitKumarDas
pushed a commit
to AmitKumarDas/d-operators
that referenced
this issue
Jan 4, 2021
This commit makes exhaustive changes to handle CRD instances. CRD instances make use of unstructured types instead of typed instances. Both CRD versions i.e. v1beta1 & v1 are supported. Unstructured instances have proved to be generic & testable versus the typed counterparts especially for CRD schemas that can differ from each other. In other words, CRD schemas have a majority schemaless section that is well handled via unstructured type. This commit also includes a number of integration test cases to avoid bug injections if any. This closes mayadata-io#186 partially. A better approach will be to use latest version of d-operators with clients that make use of unstructured instances directly instead of yaml strings that get converted to go structures. This commit is also a breaking change, since some of the structures have been modified. Clients that are already making use of this structure need to be modified accordingly. Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
AmitKumarDas
pushed a commit
that referenced
this issue
Jan 4, 2021
This commit makes exhaustive changes to handle CRD instances. CRD instances make use of unstructured types instead of typed instances. Both CRD versions i.e. v1beta1 & v1 are supported. Unstructured instances have proved to be generic & testable versus the typed counterparts especially for CRD schemas that can differ from each other. In other words, CRD schemas have a majority schemaless section that is well handled via unstructured type. This commit also includes a number of integration test cases to avoid bug injections if any. This closes #186 partially. A better approach will be to use latest version of d-operators with clients that make use of unstructured instances directly instead of yaml strings that get converted to go structures. This commit is also a breaking change, since some of the structures have been modified. Clients that are already making use of this structure need to be modified accordingly. Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Unable to deploy CRDs by using recipe concept. I applied the following
mayastor-recipe.txt to deploy mayastor and faced the following error.
Go type
ifthe resource is CustomResourceDefination due to this conversion from int64 to float64 is failing.
Expected Behavior
Current Behavior
Possible Solution
converting into concrete type.
Steps To Reproduce
(Or)
The text was updated successfully, but these errors were encountered: