-
Notifications
You must be signed in to change notification settings - Fork 520
Tye seems to start an adjacent Dapr placement service #1175
Comments
The original PRs that led to the by-default creation of the placement service are #763 and #767. It appears that the current "on by default" behavior was done, at least in part, to avoid having to try to detect a running placement service (and its port). However, this may have been due to the requirement of |
So I tinkered with not starting a placement server by default. If you've done a standard In the end, I'm not convinced having Tye manage the placement service, even when opt-in, provides a lot of value. I'm therefore inclined to remove that altogether and just allow the user to optionally specify an alternative placement port. If the user doesn't have either the placement service and/or its state store, they can always use Tye's container configuration to create one or both, and point the Dapr extension to the (fixed) port of the binding. (I could see that improved by allowing the Dapr extension configuration be able to refer to the binding of the placement server container, to avoid dealing with fixed ports but, again, I'm not sure whether that's something typical users will do.) Going this route will also make #1177 moot. |
I tend to agree with you @philliphoff, not sure trying to manage the placement service makes sense. If we could detect it is not running and tell the user to do a dapr init, that might be a reasonable alternative. |
I don't fully recall but I think my change was motivated by the fact that there would be an error if the Dapr placement container was already running on that default port 6050. At the time Tye was trying to always create the Dapr placement container itself on that used port. The behaviour I was after was exactly what you intend here I think. Which is that it works by default when Dapr is installed. Which is more likely the case when you want to use the Dapr extension in Tye. In my example the default config should be something like extensions:
- name: dapr
exclude-placement-container: true
placement-port: 6050 We didn't remove the capacity of Tye to spin up a Dapr placement container at the time though. Which is what is discussed here. I don't have a strong opinion there but I do agree that if that is the case it needs to be communicated to the user effectively so they can do the BTW I couldn't do enough investigation but when we use the Dapr extension, viewing the captured traces in Zipkin telemetry (via Tye dashboard) was broken at the time. I wasn't sure if it had anything to do with using the existing placement container or not. Might be worth a check if we are completely removing the Tye managed placement container. |
I think that's fair and, in #1191, I've added a check that will fail with a "you need to run |
Tye seems to start an adjacent placement service and set of services outside of a core Dapr run, or what Dapr list sees. This breaks the docs and interop.
Tye is explicitly creating an additional placement service, this may be something from the past that is no longer needed because daprd was used originally – Justin would know
The text was updated successfully, but these errors were encountered: