cli
cli copied to clipboard
dapr
Scaffold a Resiliency CRD with "smart" default policies when dapr init is executed
With the addition of default policies, Dapr should scaffold a default resiliency.yaml that includes "smart default" policies for each target type - apps, actors and components (inbound and outbound) when "dapr init" is executed. This resiliency yaml can live with the scaffolded components.
The scaffolded default policies will be used if there are no user defined policies set for the targets. Default policies can easily be over-written or customized with user-defined named policies.
I would, first, have it as its own command: dapr resiliency init and dapr resilency init -k. Since resiliency is not a stable feature yet, having it on the main init path can cause unintended behavior change.
I would, first, have it as its own command:
dapr resiliency initanddapr resilency init -k. Since resiliency is not a stable feature yet, having it on the main init path can cause unintended behavior change.
I agree that in the main init path it might cause unintended change in behavior. But do we need a separate command just for init which will then rolled back into init main path once resiliency becomes stable?
Can it be something like a subcommand dapr init resiliency or since resiliency is related to configuration should it be part of dapr configurations command. One change to the configurations command would be that instead of a readonly feature it has now, if resiliency is added a write element will also be there.
The main question is will there be any additional functionality provided by the resiliency command? As in in future validations?
My choice would be to make use of existing configurations command and potentially add a sub command to it...
@artursouza @yaron2 thoughts?
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
@yaron2 @halspang @msfussell Based on offline discussions , we are planning to deprecate components path and introduce resources path for subscription , resiliency and components crds based yaml. The configuration crd is going to remain as such as it is per application based.
With that in mind should the scaffolding for resiliency be under the dapr components command or rather a
dapr resources command with subcommands as
-k kubernetes
subscription list subscription crds applied in k8s
components for list of components
resiliency for resiliency
The dapr resources components will mimic what is done by the dapr components command.
Then we can deprecate components command as well.
@mukundansundar - I like the idea of it being a subcommand instead of a top-level like dapr resiliency.
If we're moving towards having a dapr resources I think having it under that makes sense. As far as subcommands for it, I feel like init, list, and validate would be a good set of initial commands. Though we should only support list if we plan on letting the CLI create more than one policy.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.