That would go against the grain of our requirements to have a single source of truth for topics and their subscribers/publishers
What we're hoping to do is augment dapr so that we can declare events bindings completely, creating any resources needed by the specific bindings along the way and describe usage and ownership of those events/topics completely in kubernetes manifests. This could be enough information to implement some kind of pruning logic. I want to know if this is compatible with the goals of the dapr project and if we can open a feature request describing this and potentially do the work.
@yaron2 , on issue/1116, I agree with "connector" and "trigger" architecture recommendation, but there could be use-cases where you want to extend Dapr for very general purpose like API extensions, or library logic like encrypt/decrypt. Concept of cloud "functions" connects more to me for those kind of extensions something like
v1.0/functions/somelibfunc . We left a comment here https://github.com/dapr/dapr/issues/1116#issuecomment-606019270. Whenever time permits please look at the comment and share your thoughts. We would like to contribute back this work if we have clear specs and design.
@khous thanks, will take a look.
@yaron2 Hi, I have an issue with metadata passing via grpc dapr client.
var metadata = new Dictionary<string, string>(); metadata.Add("test_key", "test_value"); var anyReply = await client.InvokeMethodAsync<HelloRequest, HelloReply>("testGrpcDapr", "SayHello", msg, metadata);When I get hit this call with OnInvoke handler there are no any metadata.
@yaron2, Hi, is it an known bug or I do something wrong?
@/all 0.6.0 is released: https://twitter.com/daprdev/status/1245777403885924352
@yaron2 I upgraded my dapr actors app to 0.6.0 and also updated the helm chart to version 0.3.0. However, I'm seeing authentication errors occurring in my daprd containers. I haven't encountered this one before. Any thoughts on how to fix?
There's a warning/error early on about loading config, and then the last item below is the authentication issue.
2020-04-02T20:03:41.438015387Z time="2020-04-02T20:03:41.437871574Z" level=info msg="starting Dapr Runtime -- version 0.6.0 -- commit e99f712-dirty" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime type=log ver=0.6.0
2020-04-02T20:03:41.438142398Z time="2020-04-02T20:03:41.438073792Z" level=info msg="log level set to: info" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime type=log ver=0.6.0
2020-04-02T20:03:41.438474129Z time="2020-04-02T20:03:41.438419524Z" level=info msg="metrics server started on :9090/" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.metrics type=log ver=0.6.0
2020-04-02T20:03:46.59394449Z time="2020-04-02T20:03:46.593809978Z" level=warning msg="error loading configuration: %!s(<nil>)" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime type=log ver=0.6.0
2020-04-02T20:03:46.593959891Z time="2020-04-02T20:03:46.593853882Z" level=info msg="loading default configuration" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime type=log ver=0.6.0
2020-04-02T20:03:46.593964392Z time="2020-04-02T20:03:46.593901586Z" level=info msg="kubernetes mode configured" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime type=log ver=0.6.0
2020-04-02T20:03:46.594029698Z time="2020-04-02T20:03:46.593959591Z" level=info msg="dapr id: grib-actors" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime type=log ver=0.6.0
2020-04-02T20:03:46.594034998Z time="2020-04-02T20:03:46.593997795Z" level=info msg="mTLS enabled. creating sidecar authenticator" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime type=log ver=0.6.0
2020-04-02T20:03:46.59426882Z time="2020-04-02T20:03:46.594153109Z" level=info msg="trust anchors and cert chain extracted successfully" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime.security type=log ver=0.6.0
2020-04-02T20:03:46.59427572Z time="2020-04-02T20:03:46.594174111Z" level=info msg="authenticator created" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime type=log ver=0.6.0
2020-04-02T20:03:51.606054899Z time="2020-04-02T20:03:51.60551565Z" level=warning msg="failed to load components: rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: x509: certificate is valid for sentry, not cluster.local\"" app_id=grib-actors instance=grib-actors-59d6c8c58b-rwlm7 scope=dapr.runtime type=log ver=0.6.0This was working with 0.5 this morning. I upgraded because I redeployed a test app and daprd automatically grabbed 0.6.0 (which caused other issues). Thanks for any help or ideas!!
I can see from the last error that the
0.5.0 control plane is in use
Btw we merged a PR today that removes our use of
:latest, so for the next release you will not get it unless you upgrade explicitly
@amanbha @yaron2 if you have the possibility, please see if there is any more info/examples I could add to #907 to move this going/forward. The transactional request option could be one part (to my understanding used by the actor setting, and not supported by all stores), would be great to support this scenario without introducing special store components (due to impl)
Hi @yaron2 I'm thinking on creating a json based secret store component based on what the .NET Secret Manager does. Enabling a Dev to work on localhost with a simple json file, to hold the app secrets, in another folder (perhaps in the user's profile) avoiding to setup a cloud vault or any other service to start working. We should disable loading this component in k8s mode. Do any of you think it makes sense? If so I´ll write the proposal and push the WIP code I have. On the other should we extend the secrets API to be able to retrieve all secrets with one call and improve performance and avoid cloud service throttling?
@cmendible if you don't specify an app port, Dapr will not wait for your app to become available. It will just load
@yaron2 the app is an asp.net core app if I do not specify the port how will dapr know to call the endpoints?The app needs to read secrets with the using the provider before ASP.NET Core has open the port....
@cmendible I think it makes sense but I'd like to get @rynowak for his opinion here
@reesh-a if you mean to call actors from node.js, no, but you could look at our API reference in the docs repo to see how to invoke an actor. if you mean to write actors using Javascript, we currently support Java, C# and Python is WIP.
So far I'm only getting it from
kubectl logs -f -c daprd ...
msg="starting Dapr Runtime -- version 0.6.0 -- commit e99f712-dirty"
I'm also using microk8s.
