Dapr List doesn't find my running Daprd + Scheduler processes && Unable to test Dapr Init changes for Scheduler

[cicoyle]

I am trying to test the CLI code locally for Scheduler changes. This has proved to not be as simple as I had hoped for. I am looking for suggestions on ways around my blockers, as this change is required for this release.

Currently, I am running into 2 issues that are preventing my scheduler cli work from being tested.

1. I am unable to get ./dist/darwin_arm64/release/dapr list to find my running daprd + scheduler. I have tried running them inside docker and separately by running the binaries. This is a blocker, as I am unable to test my ./dist/darwin_arm64/release/dapr job schedule --name=cassie --schedule="@hourly" --app-id=sub command bc the cli cant find my running instances

   
   ./dist/darwin_arm64/release/dapr list                                                        
   APP ID                      HTTP PORT  GRPC PORT  APP PORT  COMMAND  AGE  CREATED              DAPRD PID  CLI PID  APP PID  RUN TEMPLATE PATH  APP LOG PATH  DAPRD LOG PATH  RUNTEMPLATENAME  
   cloud-event-bulk-publisher  56688      50001      0                  10d  2024-05-06 17:53.39  83458      83449    0                                                                   

./dist/darwin_arm64/release/dapr job schedule --name=cassie --schedule="@hourly" --app-id=sub ❌ Error scheduling job cassie: couldn't find a running Dapr instance

2. I am unable to test the `./dist/darwin_arm64/release/dapr init` to verify if it will successfully create my scheduler upon a `dapr init`. My understanding is that scheduler should be deployed as default, for users to use as they would like, but will be an explicit opt in feature for reminders. Therefore, I need to be able to test my changes such that I can see if scheduler is created with a `dapr init`. The problem is that scheduler isn't in master in dapr, I have it all locally but can't find a way to test it without an rc of the image bundle.

./dist/darwin_arm64/release/dapr init
⌛ Making the jump to hyperspace... ℹ️ Container images will be pulled from Docker Hub ℹ️ Installing runtime version 1.13.2 ❌ Downloading binaries and setting up components... ❌ docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "./scheduler": stat ./scheduler: no such file or directory: unknown.

# Steps to repro:

Checkout my dapr branch w/ scheduler in it: https://github.com/dapr/dapr/pull/7716
from `cmd/scheduler` run: 
`go build -tags=allcomponents -v` && `./scheduler `

from `cmd/daprd` run: 
`go build -tags=allcomponents -v` && `./daprd --app-id=sub --scheduler-host-address=localhost:50006 --dapr-grpc-port=3501 --metrics-port=9091`

from cli directory: checkout my branch: https://github.com/dapr/cli/pull/1405 (I opened as a draft PR for ease of getting assistance on this)
run `make build`
run `./dist/darwin_arm64/release/dapr list` where it doesn't find my running daprd or scheduler
run `./dist/darwin_arm64/release/dapr job schedule --name=cassie --schedule="@hourly" --app-id=sub` where it still can't find my instances

# Things I've tried:
I tried running both in docker as well with:

docker run --name dapr_scheduler -v /Users/cassie/go/src/github.com/dapr/cmd/scheduler/data-default-dapr-scheduler-server-0:/data-default-dapr-scheduler-server-0 -it diagrid/dapr/scheduler:dev-linux-arm64 ./scheduler

docker run --name dapr -it diagrid/dapr/dapr:dev-linux-arm64 ./daprd --app-id=sub

But `./dist/darwin_arm64/release/dapr list` was still unable to find my instances. Same if I run them in my IDE, the cli cant find the processes

I have tried setting that `--image-registry` flag on the `dapr init` as well, but still face the same issue.

[cicoyle]

Looks like dapr init with scheduler is required for 1.14, but is not the scheduler apis. Will come back to the apis after 1.14, but I still need input on dapr init w/ scheduler

[dapr-bot]

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.

[dapr-bot]

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.

[dapr-bot]

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.

[dapr-bot]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.