Dapr: Component yaml can not be loaded in k8s if one value is integer and not string

Created on 12 Aug 2020  路  7Comments  路  Source: dapr/dapr

In what area(s)?

/area operator

What version of Dapr?

v0.8.0-rc

Expected Behavior

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.

Actual Behavior

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|...

Steps to Reproduce the Problem

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

RELEASE NOTE: Fixed Component YAMLs needing quoted values for Kubernetes

P1 kinbug platforkubernetes

Most helpful comment

@youngbupark and @msfussell, I put P1 on this. If you believe this is not a P1, we can change.

All 7 comments

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:

2108

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

vinayada1 picture vinayada1  路  4Comments

linuxbsdfreak picture linuxbsdfreak  路  5Comments

yaron2 picture yaron2  路  6Comments

skmaingi picture skmaingi  路  4Comments

jasoncarreira picture jasoncarreira  路  3Comments