/area operator
v0.8.0-rc
A component yaml with integer values can be loaded in standalone mode but not if running in kubernetes mode.
Behavior should be same for standalone and kubernetes mode. Either allowing integers or failing with integers.
Standalone is working
Kubernetes throws an error within Operator Service:
E0812 06:11:42.076047 1 reflector.go:153] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to list *v1alpha1.Component: v1alpha1.ComponentList.ListMeta: v1.ListMeta.TypeMeta: Kind: Items: []v1alpha1.Component: v1alpha1.Component.Spec: v1alpha1.ComponentSpec.Type: Metadata: []v1alpha1.MetadataItem: v1alpha1.MetadataItem.Value: ReadString: expects " or n, but found 1, error found in #10 byte of ...|,"value":1}],"type":|..., bigger context ...|msQuery","value":""},{"name":"authStyle","value":1}],"type":"middleware.http.oauth2clientcredentials|...
Deploy this Component to a dapr k8s
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: test
spec:
type: somecomponent
metadata:
- name: integer
value: 1
check the logs of the Operator service/pod
RELEASE NOTE: Fixed Component YAMLs needing quoted values for Kubernetes
I think this is not a issue but a more strict rule ?
It seems the yaml/json parsers are different in standalone and k8s mode.
Hi @skyao I am not sure about the technical reason.
But in that case my ask would be to unify the yaml/json parsers or using the same parsers as k8s does. Otherwise the experience for a developer is not ideal:
Things which are working in 'dev' standalone suddenly throw errors if you go over to k8s mode.
Hi @skyao I am not sure about the technical reason.
But in that case my ask would be to unify the yaml/json parsers or using the same parsers as k8s does. Otherwise the experience for a developer is not ideal:
Things which are working in 'dev' standalone suddenly throw errors if you go over to k8s mode.
I totally agree. In fact I found similar issue like this:
This time, it is about boolean: it should be true/false, not "true"/"false"
@vinayada1 is there any plan? Should we unify the yaml parsers for standalone mode and k8s mode?
@skyao and @h2floh, we should either use the k8s parser in daprd or, better yet, find a way to change the Component schema from map[string]string to map[string]interface{} which would allow the flexibility of the self-hosted parser.
@youngbupark and @msfussell, I put P1 on this. If you believe this is not a P1, we can change.
Yes, this is certainly P1. Consistency between local and K8s and all hosting environments is a key goal of Dapr
Most helpful comment
@youngbupark and @msfussell, I put
P1on this. If you believe this is not aP1, we can change.