Rename the run `--components-path` flag to a name for suitable for loading many resource types

[msfussell]

Describe the proposal

When the CLI came out there were only components, now we have 2 more, subscriptions and reliability spec so we need to change the naming accordingly to reflect that this path is used to load multiple types of resources. We can still keep --components-path and slowly deprecate this.

I suggest --resources-path or --spec-resources-path given that we refer to these as specs in the docs. Also see https://github.com/dapr/cli/issues/950 as a related issue.

Release Note

RELEASE NOTE:

[mukundansundar]

I agree with this change. It would make sense to rename the flag with the addition of resiliency. Also following the deprecation policy in dapr, the --components-path will need to be deprecated first aliased as some other appropriate flag name and later removed 2 releases later.

[msfussell]

I do not think the name should contain resiliency, since there are also subscription resource types and I expect there will be more resource types in the future. Part of this is that we need to agree on a good name for these resources (staying away from CRDs which is a K8s term).

[hueifeng]

I suggest --resources-path or --spec-resources-path given that we refer to these as specs in the docs.

We use --spec-resources-path is more appropriate? I will assign this issue.

[hueifeng]

/assign

[mukundansundar]

@artursouza @yaron2 @msfussell Should this be changed in daprd binary flags as well? As dapr CLI just passes on the value to the daprd executable. From daprd -help

-components-path string
    	Path for components directory. If empty, components will not be loaded. Self-hosted mode only

In this case I also prefer the --resources-path instead of spec-resources-path.

[yaron2]

@artursouza @yaron2 @msfussell Should this be changed in daprd binary flags as well? As dapr CLI just passes on the value to the daprd executable. From daprd -help

-components-path string
    	Path for components directory. If empty, components will not be loaded. Self-hosted mode only

In this case I also prefer the --resources-path instead of spec-resources-path.

Yes this should be a daprd flag as well.

[msfussell]

Agree this should be a daprd flag

[mukundansundar]

Moving to 1.10 as there are still some unresolved questions that need decision on the associated pr

[pravinpushkar]

Renaming comnponents-path to resources-path will affect many other repos like quickstarts, sdk examples. same with if we are planning to change the directory name to resources instead of components. thoughts @mukundansundar @yaron2 @msfussell

[mukundansundar]

Renaming comnponents-path to resources-path will affect many other repos like quickstarts, sdk examples.

same with if we are planning to change the directory name to resources instead of components.

thoughts @mukundansundar @yaron2 @msfussell

For the arguments... We can support both for now and mark the components path arg as deprecated.

For the directory we can do the same (init both dirs with same content) and we can add in docs and release notes that resources should be used instead of components?

At a later point following either deprecation policy or longer (since components path and components dir has been there for a long time) we can remove components path support completely.

Thoughts?

[pravinpushkar]

@mukundansundar I agree with the approach. Here is how we can proceed -

1. Accept the current PR - - introduce the resources-path flag [done]. - Introduce a deprecation warning for components-path flag. [should be done in this PR]

2. Create a tracking issue to deprecate it. - dapr init will create a resources directory along with components directory and all default logic will point to this. I think it is not necessary for the above PR or dapr compose implementation. Thoughts ?

EDIT:- on thinking again from dapr compose perspective we can create the resources directory as well with this PR itself. Which can be useful in dapr compose

[mukundansundar]

@mukundansundar I agree with the approach. Here is how we can proceed -

1. Accept the current PR -
   • introduce the resources-path flag [done].
   • Introduce a deprecation warning for components-path flag. [should be done in this PR]

LGTM

2. Create a tracking issue to deprecate it.
   • dapr init will create a resources directory along with components directory and all default logic will point to this. I think it is not necessary for the above PR or dapr compose implementation. Thoughts ?

EDIT:- on thinking again from dapr compose perspective we can create the resources directory as well with this PR itself. Which can be useful in dapr compose

For this, having the resources directory flag will make the dapr run command a bit more consistent. That is why I thought it as a pre-req. But agree that it is not a blocker for starting the implementation of the epic #1123