-
Notifications
You must be signed in to change notification settings - Fork 560
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
services: key services by server id; auto start cli service flags (#6425
) * services: key services by server id; auto start cli service flags Before this, services provided as CLI flag values were not automatically started, so user module code needed to explicitly start them (or implicitly start them via a service binding), which is somewhat surprising and boilerplatey since there's not really any cases where a user wouldn't want the host service to already be running. This is debatable though. Now, the CLI calls start on host services provided as flag args. In order for this to work, there was also a change needed in the internal services implementation to key services by the ServerID rather than ClientID. The difference is that now the state of a service is shared across a whole session, which includes the CLI and all modules it invokes (directly or transitively). Otherwise even if the CLI auto starts the service it will still not be running when the module code uses it. That change is also fairly debatable, not a very clear cut best answer here. Previously, every module could start an identical service and get their own instance of it. But now modules in a session starting an identical service will get a shared instance of it. Both behaviors are logical and possibly desired in different use cases. I think the main argument for changing to key by ServerID is that it makes it possible for services to be shared across a session, but still leaves open the possibilty for them to not be shared by having users include some "module-specific" key in the service's definition that causes it to not be de-duped. This is as opposed to the previous use of ClientID that made it impossible for services to be shared. One other possible solution here would be to only key host services (i.e. the one started by the CLI here) by the server ID, but use ClientID and retain the previous behavior for other services. That feels a bit too complicated (both to explain and to implement) to be worth it, but is probably possible if it ends up making more sense. Signed-off-by: Erik Sipsma <erik@dagger.io> * update service unit test to account for client->server id Signed-off-by: Erik Sipsma <erik@dagger.io> --------- Signed-off-by: Erik Sipsma <erik@dagger.io>
- Loading branch information
Showing
5 changed files
with
89 additions
and
32 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters