Configuration for use by extensions, custom pipelines, or other extensions

[philproctor]

New Feature

Add some container for storing configuration values into the configuration container into both the GlobalConfiguration and into the individual ReRoute configurations. Additionally, the creator methods for reroutes and possibly other configurations (such as service discovery) should have hooks that provide a mechanism for reloading these configurations on configuration change and adding properties to the configured object (such as the ReRoute object)

Motivation for New Feature

Currently the Ocelot configuration has predefined values based on what Ocelot internally uses. This works for official extensions, however it makes it difficult for third parties to extend with configurations that are not already in the standard FileConfiguration. When an option needs to be applied to an individual reroute, using the standard IConfiguration options from ASP.NET require knowing the array index and other information that may not be easily available.

[margaale]

I really like this feature

[philproctor]

@margaale Any ideas as to what that configuration container should look like? That's where I'm a bit unsure as we need some way of providing a JSON Scheme onto FileConfiguration.

My initial thought is it would be a Dictionary<string, Dictionary<string, object>> and the "extension" would receive the Dictionary<string, object> from the key that matches the extension name. So it would be something like this:

"Extensions": {
    "ExtensionName": {
        "Key1": "Value1",
        "Key2": true
    }
}

Then the extension named "ExtensionName" would receive the Dictionary<string, object> that contains "Key1" with the string "Value1" and "Key2" with the boolean "true"

[margaale]

That would be my first choice too, but probably we could Json.Deserialize the configuration into an user defined class

[philproctor]

The ASP.NET configuration used doesn't allow that out of the box without defining the structure up front, that I'm aware of. I think in order to do that we'd have to implement our own way of loading the configuration from disk instead of relying on ASP.NET's

[philproctor]

In OcelotMiddlewareExtensions.cs we have this:

            // make configuration from file system?
            // earlier user needed to add ocelot files in startup configuration stuff, asp.net will map it to this
            var fileConfig = builder.ApplicationServices.GetService<IOptionsMonitor<FileConfiguration>>();

            // now create the config
            var internalConfigCreator = builder.ApplicationServices.GetService<IInternalConfigurationCreator>();
            var internalConfig = await internalConfigCreator.Create(fileConfig.CurrentValue);

As you can see, it's already been noted that config could be made from the filesystem. If we did that instead, we could deserialize into a JObject easily and allow extensions to define their own configuration structured.

However, this comes with at least two costs... Cons to this approach are:

• We would have to implement our own file change monitor. The IOptionsMonitor currently takes care of that for us.
• Current code would break as the previous pattern of loading the config into ASP.NET would no longer work and we would require a config file location in UseOcelot()

[margaale]

I know that part of the code, the optionmonitor was my contribution :-) There's is an administration API where you are able to modify the configuration and save it to the filesystem that we have to take into account too. We can load the configuration as your original idea and then add an extra layer where we transform it to the desired class. I don't want that the third party add-ons have to use the options extension. They would have to use that layer (service) to fetch their configuration. Sorry if I'm not being clear, English is not my first language...

[philproctor]

I'm leaning towards providing the Dictionary with options, at least with the initial implementation. Perhaps we could allow some further customization in an update, but doing it with the Dictionary requires the least amount of disruption with the current configuration system.

The transform layer would be difficult for any configuration that is not flat, we would need to reload the raw configuration. That may be feasible but would require a lot of mangling of the config, the Dictionary implementation is the simplest short-term to at least prove out the concept.

[margaale]

Sure, let's start with the simple solution, we will have time to further refine it. Tell me if i can help you. I'm gonna give it a shota at the caching issue in the meanwhile

[philproctor]

Sounds good, I'll start work on this one soon. I'll probably also pick up #737 as I have found that one would resolve a number of other issues/requests in the backlog.

[TomPallister]

This is interesting, I am not really clear what problem it is solving in my head or what it would look like though!

[gchadid]

hi, this feature would be great, any update?

[raman-m]

Related to

• Extending Route configuration #651
• #651 Merge custom JSON properties across multiple ocelot.X.json configuration files using Newtonsoft's JToken merge functionality #1183

[raman-m]

@philproctor What's up, Phil?

Your feature has been accepted. So, the feature is in development now officially. Congrats! 🎉
Are you still with Ocelot?

[raman-m]

@vantm Welcome! You are assigned!

[raman-m]

Closed by #1843