Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lynn Orrell
    @lynn-orrell
    Yeah, you would definitely need to be careful with pruning as you could inadvertently delete a topic that, for example, non-dapr apps were using.
    Kyle Housley
    @khous
    I'm not considering topics that are also consumed outside of dapr applications at the moment
    That would go against the grain of our requirements to have a single source of truth for topics and their subscribers/publishers
    Lynn Orrell
    @lynn-orrell
    I think that will be the trick though… How will you know? Other than putting some form of governance in place...
    Kyle Housley
    @khous
    We control our own system, so it's within reach to manage topics in one way
    Lynn Orrell
    @lynn-orrell
    Ok, so yeah, with your own governance in place you could make it work
    Kyle Housley
    @khous
    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.
    Lynn Orrell
    @lynn-orrell
    @yaron2 is going to have to weigh in on whether or not this falls within the goals of dapr and, if so, exactly where it should fit. It definitely doesn’t hurt to open an issue on github for the proposal / discussion.
    Kyle Housley
    @khous
    sure, I'll whip something up
    Lynn Orrell
    @lynn-orrell
    Great! Thanks!
    Pulkit Mehra
    @pulkitmehra
    @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.
    Kyle Housley
    @khous
    @lynn-orrell @yaron2
    dapr/dapr#1360
    Yaron Schneider
    @yaron2
    @pulkitmehra we will look at it and respond, thanks a lot for putting this together. please also feel free to weigh in on the next Dapr community call.
    @khous thanks, will take a look.
    GennadiiSvichinskyi
    @GennadiiSvichinskyi

    @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?

    Yaron Schneider
    @yaron2
    @GennadiiSvichinskyi metadata in gRPC is used in the context of the app providing call metadata to Dapr, and on the receiving side Dapr passing call metadata to the receiver. Any data that you want to send to the other side needs to be in the request body.
    Kyle Housley
    @khous
    congrats!
    David Hoerster
    @DavidHoerster

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

    This 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!!

    Yaron Schneider
    @yaron2
    @DavidHoerster Did you uninstall 0.5.0 before you installed 0.6.0?
    I can see from the last error that the 0.5.0 control plane is in use
    David Hoerster
    @DavidHoerster
    @yaron2 I updated the Helm chart to use 0.3.0 (I'm using Flux's HelmRelease CRD to manage my helm charts in my cluster). I updated my helm chart for Dapr to go from 0.2.2 to 0.3.0. Should I remove the 0.2.2 chart and install the 0.3.0 instead?
    Yaron Schneider
    @yaron2
    @DavidHoerster updating the chart is not enough. do helm uninstall dapr -n dapr-system and then helm repo update and helm install dapr dapr/dapr --namespace dapr-system
    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
    David Hoerster
    @DavidHoerster
    @yaron2 Thank you! I'll uninstall and reinstall. And that's good to know about the image tag. Thanks again!
    Per Ökvist
    @perokvist
    is there a story for dapr and knative ? or is this just sample use cases the might be coming ?
    Per Ökvist
    @perokvist
    @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)
    Kyle Housley
    @khous
    @yaron2 I have a quick question about event bindings. If I publish to an event topic, and I have n different subscribers to that topic, will all subscribers receive the event? Does this perhaps depend on the binding being used?
    Carlos Mendible
    @cmendible
    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?
    Carlos Mendible
    @cmendible

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

    Yaron Schneider
    @yaron2
    @perokvist When Knative supports sidecars there might be a nice story there. We'll be adding a section to our Wiki about Dapr and Knative
    Yaron Schneider
    @yaron2
    @khous It depends on the binding. If its a queue for example, you'll have semantics of dequeuing a message meaning one consumer will get it.
    @cmendible I think it makes sense but I'd like to get @rynowak for his opinion here
    Kyle Housley
    @khous
    thanks Yaron, I was afraid of that :D
    reesh-a
    @reesh-a
    Is there a sample impl of dapr actors in nodejs?
    Yaron Schneider
    @yaron2
    @khous as its a binding, it inherits the behavior of the external system. For pub/sub, its a different story. if your recipients are your own code, than pub/sub is a better fit
    @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.
    reesh-a
    @reesh-a
    Got it! thanks.
    chess-equality
    @chess-equality
    Hello, just updated to v0.6.0, how to check the version installed? Thanks.
    Per Ökvist
    @perokvist
    "dapr --version"
    chess-equality
    @chess-equality
    @perokvist Thanks, but I meant in Helm Dapr
    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.
    Per Ökvist
    @perokvist
    sorry, didn't read the context...
    madhugilla
    @madhugilla
    (₹56
    tclasen
    @tclasen
    Does DAPR currently have a good method of storing and retrieving an append-only list?
    tclasen
    @tclasen
    Or is there an ability to get multiple items from a state store using wildcards like redis supports?
    Yaron Schneider
    @yaron2
    @tclasen there's an issue tracking this feature request here dapr/dapr#1339
    tclasen
    @tclasen
    I could easily implement this in the DAPR component for redis. Is there a requirement that all component types support the same features? As in, would I have to implement it for each type of state store?