New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the experience when running and debugging ServiceControl instances locally #3528
Conversation
Co-Authored-By: Jo Palac <jpalac@users.noreply.github.com>
Transport name takes precedence
…e take precedence
Audit instance F5 experience
…e same way as monitoring
…Control into F5-experience
Co-Authored-By: Mauro Servienti <1325611+mauroservienti@users.noreply.github.com>
…sthe same across all instances
…st behaviour Fixed approval tests
Added commented out config settings for transport and persisters
… transport manifests tests
Will this also be deployed with subfolders with SCMU? This would allow to 'switch' the storage engine via a config change without requiring other file/folder changes. For example, reverting to the 3.5 would then be a manual config file change, deleting the contents of the DB Path and starting the instance and it would work. From 3.5 to 5 would not work as this requires running the setup but still relatively easy. |
Re-org persistence manifest tests to follow the same structure as the transport manifests tests
The test projects had two reference to the in-memory persistence and learning transport and the behavior was non-deterministic
@ramonsmits This task force will probably run out of time to make these changes (and smoke test them) but that is the direction we are headed. The best use-case of this are the docker images. We currently have one image per transport but this will let us create one with all transports and select a transport at runtime via a human readable environment variable. |
Co-Authored-By: Jo Palac <jpalac@users.noreply.github.com>
This PR alters ServiceControl to load transports and persistences from subfolders at runtime (if they are found). At startup, the installation folder (and all subfolders) are scanned for
transport.manifest
andpersistence.manifest
files. These json files contain the fully qualified type name of the class which is used to configure the transport and persistence options of ServiceControl. They also contain a human readable name for these options.These are all loaded into an in-memory manifest. When the instance reads it's TransportType (and PersistenceType for Audit instances) setting, this is used to locate the manifest and configure ServiceControl. If no manifests are found (or they cannot be loaded) then the original behavior is used, assuming that the TransportType is a fully qualified class name.
The PR also includes a build-time step which ensures that transport and persistence artifacts are placed in subfolders under the instance build folders.
All of this means that developers working on ServiceControl can configure the app.config file in the solution to use a specific transport or persistence and start the instance under the debugger.
No changes were made to packaging, the installer, or the docker images, although all three could benefit from these changes in the future.