Consider adding support for Options pattern about winton.extensions.configuration.consul HOT 9 CLOSED

from winton.extensions.configuration.consul.

Possibly also an overload that just takes Key and Address

from winton.extensions.configuration.consul.

I agree, i was just looking for a way to do that, but it seems the services that depend on the options don't use the IOptions API. hard coding the URI is a big NO for me. maybe i will try to look into creating a PR for it this weekend. It should be trivial to implement.

from winton.extensions.configuration.consul.

I'm curious what the goal is here.

The new patterns in Microsoft.Extensions.Configuration allow configuring several configuration providers such that you can already load settings from a local config file:

      hostBuilder.ConfigureAppConfiguration((hostingContext, config) =>
      {
        var env = hostingContext.HostingEnvironment;

        config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
        config.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

        var consulConfig = new ConsulConfiguration();
        hostingContext.Configuration.Bind(consulConfig);
        if (consulConfig.Validate(hostingContext.HostingEnvironment))
        {
          config.AddConsul(consulConfig.Folder, options =>
          {
            options.ConsulConfigurationOptions = cco => {
              cco.Address = consulConfig.Address;
            };
            options.PollWaitTime = TimeSpan.FromSeconds(consulConfig.Check_Frequency_Seconds);
            options.Parser = new SimpleConfigurationParser();
          });
        }
      });

from winton.extensions.configuration.consul.

@davidalpert the goal was for the consul config provider to read it's own config from the other config providers (i.e. json file). but now that i think about it, it may not be possible. i don't think the configuration providers themselves are able to get configs initialized from other providers in the same context, as it's a chicken and egg problem. unless they can from providers added to the configuration builder before them. not sure..

from winton.extensions.configuration.consul.

@davidalpert as @ckarcz said my original goal was just to be able to pass an Action<IConsulConfigurationSource> delegate to the AddConsul method in the same way that a lot of services do. But as he also pointed out there is a bootstrapping problem, given that this is also a configuration provider and so probably can't inject IOptions via DI. I wrote this down as more of a reminder to myself when I had this thought while doing some work on another library, so I hadn't fully thought it through at that point.

Your code example is interesting and I didn't know it was possible to access the hostingContext.Configuration whilst it was being built. That might open some doors for doing something like the options pattern, I'll have to try some things out.

Overall the goal here is to make it easier for clients to add this configuration provider and I think in a lot of cases people probably just want to configure the Key and the Address and right now that is cumbersome given how the consul address needs to be set.

from winton.extensions.configuration.consul.

We ran into this problem internally as well, wanting to use our cascading configuration providers (without the consul provider) to configure the consul configuration provider.

We originally solved that by creating two bootstrap methods. the first would bootstrap our config providers in sequence without the consul provider. then we would read the consul config options. then we would bootstrap our config providers a second time, this time inserting the consul provider.

It seems that we were not the only ones to encounter this problem. In .NET Core the new generic IHost provider has explicit support for this two phase startup pattern as you have the opportunity to first configure a HostConfiguration (msdn) and then after configure an AppConfiguration (msdn) (which under the hood replaces the host's IConfiguration instance.

This is effectively the same startup pattern recognizing that the Host may need access to some configuration values in order to bootstrap the app (including the app's configuration providers).

from winton.extensions.configuration.consul.

here is a simple sample that uses the default host builder config sources (json files, env variables, and cli args) to configure the configuration builder at the configure application config step (i.e. after host is configured):

public static IHostBuilder CreateHostBuilder(string[] args)
{
    return Host.CreateDefaultBuilder(args)
               .ConfigureAppConfiguration((context, configBuilder) =>
               {
                   var config = configBuilder.Build();

                   if (config.GetValue<bool>("Consul:ConfigSource:Enabled"))
                   {
                       configBuilder.AddConsul($"{context.HostingEnvironment.ApplicationName}/appSettings.json", options =>
                       {
                           options.Optional = true;
                           options.ConsulConfigurationOptions = x => x.Address = config.GetValue<Uri>("Consul:ConfigSource:Address");
                           options.OnLoadException = x => x.Ignore = true;
                       });
                   }
               })
               .ConfigureWebHostDefaults(host => host.UseStartup<Startup>());
}

you can also do something similar in the ConfigureHostConfiguration(xxx) method if you need want/need to configure the host settings via consul. note that i am pretty sure the the host settings are not reloadable. it would only use the consul config values on a restart.

from winton.extensions.configuration.consul.

I think this doesn't quite work as I first thought it would and the comments here provide suitable workarounds for the bootstrapping problem.

from winton.extensions.configuration.consul.