Operate as a config server

[thompson-tomo]

Similar to spring boot, Aspire should be able to operate as a centralised configuration server for all micro services.

To achieve this a few milestones will need to be delivered mainly:

• Definition of config sets schema which is obtained from the configuration layer. Needs to define for keys aspects such as min/max length, data type, validation rules etc
• Configuration Provider API (Rest &/or gRPC). Allows for fetching of config with atleast 2 param's (App, environment) required & an optional Filter. The filter limits the settings which are returned and is applied starting from the start of the key.
• implementation of a Microsoft.Extensions.Configuration.Aspire package which consumes the api and loads config into the micrpservices
• internal API implemented to provide the ability to set values of properties and needed for UI
• Dashboard is extended to facilitate setting of configuration values via UI
• API provided to push configuration sets into the server so they can be configured

[davidfowl]

The idea is great but the team isn't equipped to build a configuration server. I think we'd much rather integrate with an existing system (consul, eureka, redis, etcd etc.), or maybe the config server is a small rest/grpc API over an existing storage system.

Definition of config sets schema which is obtained from the configuration layer. Needs to define for keys aspects such as min/max length, data type, validation rules etc

We think this would be built into Microsoft.Extensions.Configuration and Microsoft.Extensions.Options, not into aspire.

Configuration Provider API (Rest &/or gRPC). Allows for fetching of config with atleast 2 param's (App, environment) required & an optional Filter. The filter limits the settings which are returned and is applied starting from the start of the key.

This is a reasonable idea if we had a configuration server protocol, it would support read and writes to configuration (push changes).

Anyways, good idea, I'm putting it in the backlog for future consideration, this isn't something we're going to be tackling in the short term.

[thompson-tomo]

Agree, it is not the highest priority items but could be useful. Also Agree discussion would be needed about storage platform and this shouldn't be an aspire as the lead data storage layer and would be better suited in a separate package ie Microsoft.Extension.ConfigStore with a reference implementation provided which stores content as a JSON file and the community integrates alternatives like we do with ConfigurationProviders.