Closed MV10 closed 2 years ago
ReubenBond
commented
4 years ago @MV10 something like this sounds good to me. @jason-bragg mentioned the desire for this kind of thing recently. I don't believe it can totally replace the programmatic way of configuring a silo (eg, because of the need for third-party providers which have their own configuration).
It's not something I'm likely to find cycles to implement myself, but it may be a good candidate for a PR or two
ghost
commented
2 years ago We are marking this issue as stale due to the lack of activity in the past six months. If there is no further activity within two weeks, this issue will be closed. You can always create a new issue based on the guidelines provided in our pinned announcement.
ghost
commented
2 years ago This issue has been marked stale for the past 30 and is being closed due to lack of activity.
I'm wondering if the Orleans team would be interested in defining standardized configuration syntax for silo and client startup. .NET's newer Microsoft.Extensions.Configuration.* (MEC) packages have done some pretty amazing things with regard to app configuration support, which is now even easier to use with the rising popularity of Generic Host and the automatic config-load process that comes with a call to
CreateDefaultBuilder. I'm sure plenty of projects roll their own, but I think standardization would be beneficial.Almost two years ago, I did a fair amount of work on Serilog's configuration package (both old Framework XML and Core MEC config), and virtually rewrote the SQL sink package. Serilog can prepare most of the huge package-based ecosystem from config, which makes the product super easy to learn and use, and has obvious deployment and maintenance benefits. Like Orleans, it can also be configured entirely through code, but generally you can offload 99% of that to config, to be pulled in with just one NuGet package ref, plus whatever MEC sources you want to support (environment vars, command line, old-school INI files, even things like Azure Key Vault).
Serilog's config package can populate arbitrarily complex add-ons through a highly flexible reflection-based system, although I don't think Orleans needs to go that far (it doesn't have nearly the huge array of packages to support). I suspect for Orleans it would be sufficient to ensure all config adheres to the .NET strongly-typed options pattern, although I'm not broadly familiar enough with Orleans to know if that implies breaking changes.
One major pain point in the Serilog world is trying to maintain support for legacy .NET Framework's static XML config system alongside the new MEC system (I was not happy to see MS commit to letting .NET Framework drift along in perpetuity). You basically wind up with two completely separate code bases trying to do the same thing in different ways. It isn't fun to deal with. Basically just a heads-up if this idea is of interest.
Code-wise, I'm envisioning something as simple as
builder.UseOrleansConfiguration()which pulls config from the builder host context (internally, registering a series of service config delegates), also allowing optional in-code additions and overrides (e.g.UseOrleansConfiguration((ctx, siloBuilder))), which is the same general pattern that works well for Serilog. Client apps would get something similar, ideally with multi-client support.MEC has many possible config sources, of course, but everyone seems to relate well to appconfig.json formatting for the purposes of discussion and documentation.