Added IOptions extension methods

Summary
Introduces two new extension methods for IOptions and IOptionsMonitor interfaces named SafeGetValue.
Motivation
In .NET, apart from IOptions interface that provides a configuration value as it was during startup binding, there are two other interfaces, IOptionsSnapshot (that inherits from IOption) and IOptionsMonitor interfaces provides access to updated settings; the former is set as a scoped dependency, while the latter is a singleton dependency that provides a configuration value that gets updated in time.
If the option settings bind was defined during Startup to include validation of the bounded object by calling the method ValidateDataAnnotations, the three interfaces will throw a OptionsValidationException when the configuration does not correspond to the defined constraints. This means that, if the configuration changes at runtime to values that do not satisfy the defined condition, accessing the getter method IOptionsSnapshot.Value or IOptionsMonitor.CurrentValue will throw the exception in the service, causing abrupt interruption of execution.
More information can be found here.
Implementation
The two extension methods simply wrap the call to the getter methods IOptionsSnapshot.Value or IOptionsMonitor.CurrentValue in a try ... catch clause, handling the aforementioned exception only. If the call to the getter methods succeeds, the configuration will be returned, otherwise the method will return a null value.
Reasoning
Other extensions were considered:

A method that would return the validation error was considered, but the signature of the method has not been deemed sufficiently integrable with the coding style of the project and in .NET in general (more on that in the notes below), and the error details would be easily loggable by passing the ILogger instance into the method, or by handling the exception manually in the code.
Other IOptions interfaces were considered to provide a more elaborate way of getting the settings, for instance returning the initial configuration set in the service at Startup, but this would have incremented the amount of opinionated code about how to handle edge cases that would have been better implemented directly in the client code to respond to the particular needs.

Examples
Currently, to handle the validation error of a change in configuration at runtime, the OptionsValidationException would have to be handled.
Be Configuration the class into which the configuration is bound, and Executor a class that receives an instance of IOptions<Configuration> in the constructor, in the hypothetic ExecuteAction method that needs an option from Confiiguration it can be written:
public void ExecuteAction()
{
    try
    {
        string optionValue = m_optionsMonitor.CurrentValue.OptionValue;
        /* Execution of the action using optionValue */
    }
    catch (OptionsValidationException ex)
    {
        m_logger.LogError(/* logging exception */);
        throw;
    }
}

With these new extension methods, the handling of the exception will be automatic:
public void ExecuteAction()
{
    // for IOptions and IOptionsSnapshot interface
    string? optionValue = m_options.SafeGetValue();

    // for IOptionsMonitor interface
    string? optionValue = m_optionsMonitor.SafeGetCurrentValue();

    // with Logger, with m_logger being an instance of the ILogger<Executor>
    string? optionValue = m_optionsMonitor.SafeGetCurrentValue(m_logger)?.OptionValue;

    /* Execution of the action using optionValue, although in this case the null check would be necessary */
    if (optionValue != null)
    {
        /* Execution Method */
    }

    // Imagining that the Configuration class is bundled with a series of constant values representing
    // default values, the null check can be avoided:
    string? optionValue = m_optionsMonitor.SafeGetCurrentValue(m_logger)?.OptionValue ?? ConfigurationDefaults.OptionValue;
}

Notes
About the other signatures for extension methods considered, there were these two:

bool TryGetValue<T>(IOptions<T> options, out T? settings): this signature would not have added more information than the current methods, that forces the client code to check for nullability anyway.
(T?, IEnumerable<string>?) GetValue<T>(IOptions<T> options): this signature would have added error information through a "monad-like" return type, but was not deemed easily integrable within the coding style context.

Final Considerations
These extension methods can be used to get configuration entries without catching an exception, but whenever it makes more sense to manually catch the exception or let the service fail as soon as it recognises that the configuration is incorrect, the user should rely on that mechanism.
The second purpose of these extension methods is to highlight to the user the fact that the getter methods of the IOptions interfaces throw a particular exception of type OptionsValidationException that should be handled if called directly.

Thanks for the examples, however they don't demonstrate further handling of configuration absence. Try writing a complete snippet that tries to get a value, fails and takes recovery action. I suspect the difference between the two approaches will be less noticeable.

Can you provide usage examples with and without these extensions? If the application is misconfigured, silently falling back to safe defaults is not necessarily the best approach, it might be in fact better to explode and rely on monitoring to catch and mitigate that condition.

I agree, these extension methods would introduce a way of handling errors as null value automatically, and by giving an option to do so document in a specific way what could happen if the option interface getter method is called without proper handling, they are not meant to substitute an exception handling done in place
I added some documentation over the method, we can tweak it to suggest which handling method would be best in the client code.

Thanks for the examples, however they don't demonstrate further handling of configuration absence. Try writing a complete snippet that tries to get a value, fails and takes recovery action. I suspect the difference between the two approaches will be less noticeable.

Added more examples, and you're right: the handling of the nullable could lead to the exact amount of code, and worse, it can obscure the error rather than let it crash the application, and by thus notify us to handle the case.
But for configuration that has default values, like the example in the snippet of code, the extension method could be a more concise solution.
In my opinion, these methods could provide a better documentation and warning about how to get configuration natively. What I mean is that, for example, if one investigates which accessor grants access to the configuration and they notice that there is a method that starts with Safe, they will tend to investigate more on the matter, discovering that the accessor may throw an exception in case of configuration update.

I would argue that the service should fail if the configuration is incorrect because otherwise it really hard to find out that your configuration change is not used (and some default applies).
It essentially hides the serious error and changes the behavior of the app to the one you don't expect. SOS/ECS or ClusterExlorer would show you the newly applied configuration by service would be running using default value that could lead to all kinds of problems.
Imagine you applying configuration override to take a service out of rotation (or put it into rotation) and making error in the configuration. Instead of knowing right away that something would is wrong, the service would switch to the default value obscuring the error and either all versions would be serving traffic or all of them (both cases are bad).
The same goes for the refactoring hidden behind the configuration flag, you think you've enabled it but made an error, and the service defaults to not using the new code. If the developer misses that incorrect decision could be done about refactoring functionality.
Using default if the configuration is faulty also means that integration testing (ClioudTest) would be unable to detect configuration errors since in most cases it checks that the service is running and healthy, we don't look into logs for it. So this would increase the cases when faulty configurations could be merged unnoticed and deployed to production environments.
In all scenarios that I could think of hiding configuration errors is a bad idea and I think we should not encourage this behavior.

I would argue that the service should fail if the configuration is incorrect because otherwise it really hard to find out that your configuration change is not used (and some default applies). It essentially hides the serious error and changes the behavior of the app to the one you don't expect. SOS/ECS or ClusterExlorer would show you the newly applied configuration by service would be running using default value that could lead to all kinds of problems.
Imagine you applying configuration override to take a service out of rotation (or put it into rotation) and making error in the configuration. Instead of knowing right away that something would is wrong, the service would switch to the default value obscuring the error and either all versions would be serving traffic or all of them (both cases are bad).
The same goes for the refactoring hidden behind the configuration flag, you think you've enabled it but made an error, and the service defaults to not using the new code. If the developer misses that incorrect decision could be done about refactoring functionality.
Using default if the configuration is faulty also means that integration testing (ClioudTest) would be unable to detect configuration errors since in most cases it checks that the service is running and healthy, we don't look into logs for it. So this would increase the cases when faulty configurations could be merged unnoticed and deployed to production environments.
In all scenarios that I could think of hiding configuration errors is a bad idea and I think we should not encourage this behaviour.

At deployment time, I agree that a service should crash/fail to start due to incorrect configuration. However, when it comes to runtime configuration of a live service, forcing a service to break is a terrible idea as this leads to customer impact.
The choice is between:

Having only deployment time config and breaking on config failures or
Allowing for human errors in run-time configuration (emergency overrides) and failing gracefully.
In the latter model, the fallback behaviour should be reported in metrics so that alerts are fired to the service owners to address.

I would argue that the service should fail if the configuration is incorrect because otherwise it really hard to find out that your configuration change is not used (and some default applies). It essentially hides the serious error and changes the behavior of the app to the one you don't expect. SOS/ECS or ClusterExlorer would show you the newly applied configuration by service would be running using default value that could lead to all kinds of problems.
Imagine you applying configuration override to take a service out of rotation (or put it into rotation) and making error in the configuration. Instead of knowing right away that something would is wrong, the service would switch to the default value obscuring the error and either all versions would be serving traffic or all of them (both cases are bad).
The same goes for the refactoring hidden behind the configuration flag, you think you've enabled it but made an error, and the service defaults to not using the new code. If the developer misses that incorrect decision could be done about refactoring functionality.
Using default if the configuration is faulty also means that integration testing (ClioudTest) would be unable to detect configuration errors since in most cases it checks that the service is running and healthy, we don't look into logs for it. So this would increase the cases when faulty configurations could be merged unnoticed and deployed to production environments.
In all scenarios that I could think of hiding configuration errors is a bad idea and I think we should not encourage this behaviour.

I see your point, and I agree that these extension methods should be seldom used, but in case the service is critically important and should work even in case of invalid configuration parsed, they could be a good way of handling human mistakes in a centralised way. I would imagine, for instance, that the operator that changes a configuration at runtime should pay attention to the application logs, and provide a unified tag for searching the error logs could be of help.
I would have added a compilation warning associated with these extension methods, but the only one I could find is the ObsoleteAttribute, that fails to express semantically what the warning would be. I would gladly accept suggestions on this.
Another purpose of the methods would be didactical, they should pose the adequate attention to the fact that the IOptionsMonitor and IOptionsSnapshot accessor could throw an exception that should be correctly handled.

I would argue that the service should fail if the configuration is incorrect because otherwise it really hard to find out that your configuration change is not used (and some default applies). It essentially hides the serious error and changes the behavior of the app to the one you don't expect. SOS/ECS or ClusterExlorer would show you the newly applied configuration by service would be running using default value that could lead to all kinds of problems.
Imagine you applying configuration override to take a service out of rotation (or put it into rotation) and making error in the configuration. Instead of knowing right away that something would is wrong, the service would switch to the default value obscuring the error and either all versions would be serving traffic or all of them (both cases are bad).
The same goes for the refactoring hidden behind the configuration flag, you think you've enabled it but made an error, and the service defaults to not using the new code. If the developer misses that incorrect decision could be done about refactoring functionality.
Using default if the configuration is faulty also means that integration testing (ClioudTest) would be unable to detect configuration errors since in most cases it checks that the service is running and healthy, we don't look into logs for it. So this would increase the cases when faulty configurations could be merged unnoticed and deployed to production environments.
In all scenarios that I could think of hiding configuration errors is a bad idea and I think we should not encourage this behaviour.

At deployment time, I agree that a service should crash/fail to start due to incorrect configuration. However, when it comes to runtime configuration of a live service, forcing a service to break is a bad idea as this leads to more profound customer impact. The choice is between:

Having only deployment time config and breaking on config failures or
Allowing for human errors in run-time configuration (emergency overrides) and failing gracefully in the event of human error.
In the latter model, the fallback behaviour should be reported in metrics so that alerts are fired to the service owners to address.

I would argue we are providing not a way to fail gracefully, but to hide an error.
You've listed two ways of configuration updates. At deployment time and in run time.
For deployment time configuration error it looks like we agree that it's a bad idea to hide configuration errors.
For runtime configuration error I think there are better and more precise ways of guarding against those by enforcing that settings override should be applied not for all instances of the service and rollout gradually instead when first service failure would stop configuration update instead of logs that would be just ignored and everybody would be fooled that configuration applied. Especially since most of the override done by OCE or Shield and not by the person who created the service and knows what logs to look for. The point of having multiple instances of small services is to be resilient to those kinds of failures.
Even better options (but harder to implement) in creating a way for the service to provide validation rules to the settings override system so they could be verified before applying.
My worry with this approach is that it's not selective enough, it would hide any configuration error and make everyone think that you are using new configuration. It essentially makes useless all the tools we have now to check for configuration (like SOS page or ClusterExplorer) because they won't be reliable anymore.
As soon as those methods will become available everybody would start using them, because they look safer, and it would push Omex down the rabbit hole of the defensive programming that we struggled so much to get away from.
Also, I would like to point out that having a service that runs with an incorrect configuration is usually a much bigger problem than a service that failed because failed service does nothing when a service with an incorrect configuration can do harm like writing into the wrong storage or doing incorrect request to other service showing false response to a customer that could be hard or impossible to fix afterward.

I would argue that the service should fail if the configuration is incorrect because otherwise it really hard to find out that your configuration change is not used (and some default applies). It essentially hides the serious error and changes the behavior of the app to the one you don't expect. SOS/ECS or ClusterExlorer would show you the newly applied configuration by service would be running using default value that could lead to all kinds of problems.
Imagine you applying configuration override to take a service out of rotation (or put it into rotation) and making error in the configuration. Instead of knowing right away that something would is wrong, the service would switch to the default value obscuring the error and either all versions would be serving traffic or all of them (both cases are bad).
The same goes for the refactoring hidden behind the configuration flag, you think you've enabled it but made an error, and the service defaults to not using the new code. If the developer misses that incorrect decision could be done about refactoring functionality.
Using default if the configuration is faulty also means that integration testing (ClioudTest) would be unable to detect configuration errors since in most cases it checks that the service is running and healthy, we don't look into logs for it. So this would increase the cases when faulty configurations could be merged unnoticed and deployed to production environments.
In all scenarios that I could think of hiding configuration errors is a bad idea and I think we should not encourage this behaviour.

I see your point, and I agree that these extension methods should be seldom used, but in case the service is critically important and should work even in case of invalid configuration parsed, they could be a good way of handling human mistakes in a centralised way. I would imagine, for instance, that the operator that changes a configuration at runtime should pay attention to the application logs, and provide a unified tag for searching the error logs could be of help.
I would have added a compilation warning associated with these extension methods, but the only one I could find is the ObsoleteAttribute, that fails to express semantically what the warning would be. I would gladly accept suggestions on this.
Another purpose of the methods would be didactical, they should pose the adequate attention to the fact that the IOptionsMonitor and IOptionsSnapshot accessor could throw an exception that should be correctly handled.

My view on this is that if service is critical:

We should not have a single instance of it.
We should not apply configuration changes to all instances of the service at once. (That I believe already in guidelines and even might be enforced by SOS)
Also, as I've pointed out in reply to Keith having crucial service running in with incorrect configuration (and lying to all tools that it runs on other configuration) is even more dangerous.

Besides that, methods in this PR does not provide any distinction between critical and non-critical services, so since using them looks safer everybody would use them and all configuration becomes unreliable.
About the operator checking for logs errors during applying settings override. To me, it looks like a very optimistic scenario. It's a bad idea to hope that people follow the steps that are not enforced. Especially since most of the overrides  are done by people on-call or Shilelds that know nothing about the internals of this particular service and what methods are used to get the settings.
If we would work on enforcing this procedure, I think, there are much better practices to enforce, for example, gradual configuration rollout with fallback in case of failure or the ability for the service to provide validation rules to the override tool.
Also, added methods allow not passing the logger or using NullLogger and in combination with constant log loss by our log aggregator could result in undetectable misconfiguration (both in runtime and deploy time). And if there is a possibility for that it will happen eventually.
Omex's previous way of getting configuration provided customers with the same choice of getting configuration value or getting it safely. As a result, all of the configuration requests were done using safe methods (and PR's were blocked because people not using safe ones with default values in case of failure). As a result, it caused multiple issues when the configuration used was different from the one everybody expected and made the code more convoluted obscuring the main logic.
This made sense before when everything was a single service and failing in one part could break totally unrelated things, but with smaller that each has their own area of responsibility we should not fall back to the same bad practices. It was intentional design behind not giving people tools to default back to the bad practices, creating discrepancies between reported and used configuration and obscure logic.
About compilation warnings, the way to do that is by creating code analyzers that ship with the package and could provide warnings, info messages, or even code fixes on incorrect code usage, but that's much more work. The benefit is that you can do that not only for your code, create analyzers about incorrect usages of standard classes. This repo might be a good sample for that https://github.com/xunit/xunit.analyzers

I would argue that the service should fail if the configuration is incorrect because otherwise it really hard to find out that your configuration change is not used (and some default applies). It essentially hides the serious error and changes the behavior of the app to the one you don't expect. SOS/ECS or ClusterExlorer would show you the newly applied configuration by service would be running using default value that could lead to all kinds of problems.
Imagine you applying configuration override to take a service out of rotation (or put it into rotation) and making error in the configuration. Instead of knowing right away that something would is wrong, the service would switch to the default value obscuring the error and either all versions would be serving traffic or all of them (both cases are bad).
The same goes for the refactoring hidden behind the configuration flag, you think you've enabled it but made an error, and the service defaults to not using the new code. If the developer misses that incorrect decision could be done about refactoring functionality.
Using default if the configuration is faulty also means that integration testing (ClioudTest) would be unable to detect configuration errors since in most cases it checks that the service is running and healthy, we don't look into logs for it. So this would increase the cases when faulty configurations could be merged unnoticed and deployed to production environments.
In all scenarios that I could think of hiding configuration errors is a bad idea and I think we should not encourage this behaviour.

I see your point, and I agree that these extension methods should be seldom used, but in case the service is critically important and should work even in case of invalid configuration parsed, they could be a good way of handling human mistakes in a centralised way. I would imagine, for instance, that the operator that changes a configuration at runtime should pay attention to the application logs, and provide a unified tag for searching the error logs could be of help.
I would have added a compilation warning associated with these extension methods, but the only one I could find is the ObsoleteAttribute, that fails to express semantically what the warning would be. I would gladly accept suggestions on this.
Another purpose of the methods would be didactical, they should pose the adequate attention to the fact that the IOptionsMonitor and IOptionsSnapshot accessor could throw an exception that should be correctly handled.

My view on this is that if service is critical:

We should not have a single instance of it.
We should not apply configuration changes to all instances of the service at once. (That I believe already in guidelines and even might be enforced by SOS)

Also, as I've pointed out in reply to Keith having crucial service running with incorrect configuration (and lying to all tools that it runs on other configuration) is even more dangerous.
Besides that, methods in this PR does not provide any distinction between critical and non-critical services, so since using them looks safer everybody would use them and all configuration becomes unreliable.
About the operator checking for logs errors during applying settings override. To me, it looks like a very optimistic scenario. It's a bad idea to hope that people follow the steps that are not enforced. Especially since most of the overrides are done by people on-call or Shilelds that know nothing about the internals of this particular service and what methods are used to get the settings. If we would work on enforcing this procedure, I think, there are much better practices to enforce, for example, gradual configuration rollout with fallback in case of failure or the ability for the service to provide validation rules to the override tool. Also, added methods allow not passing the logger or using NullLogger and in combination with constant log loss by our log aggregator could result in undetectable misconfiguration (both in runtime and deploy time). And if there is a possibility for that it will happen eventually.
Omex's previous way of getting configuration provided customers with the same choice of getting configuration value or getting it safely. As a result, all of the configuration requests were done using safe methods (and PR's were blocked because people not using safe ones with default values in case of failure). As a result, it caused multiple issues when the configuration used was different from the one everybody expected and made the code more convoluted obscuring the main logic. This made sense before when everything was a single service and failing in one part could break totally unrelated things, but with smaller that each has their own area of responsibility we should not fall back to the same bad practices. It was intentional design behind not giving people tools to default back to the bad practices, creating discrepancies between reported and used configuration and obscure logic.
About compilation warnings, the way to do that is by creating code analyzers that ship with the package and could provide warnings, info messages, or even code fixes on incorrect code usage, but that's much more work. The benefit is that you can do that not only for your code, create analyzers about incorrect usages of standard classes. This repo might be a good sample for that https://github.com/xunit/xunit.analyzers
About attracting attention to the fact that Options could throw, I think it would instead push people to the bad practice since as practice shows it's easier for people to use "safe" method and don't thinking too much about it than accept the fact that the service should fail if it configured incorrectly.

I will add some more thoughts about some of the points you raised:

It is true that, semantically speaking, these methods give a wrong idea of safely getting configuration for a service, while instead they are actually handling the exception internally, logging it, and return null, but:
a. The logger can be made a mandatory parameter in input.
b. The method currently returns a nullable object that will have to be handled accordingly; although this could result in an increase of defensive programming, or to simply overlook the null object in projects that do not have nullability check enabled, the alternative would simply be uglier in case a fallback value is indeed available, having that the exception would have to be manually handled.
It is true that the person on Shield for a particular team can be unaware of the logging mechanism implemented for this kind of error, but by centralising the handling of the exception, further action can be performed to, for instance, trigger the creation of a ticket to report faulty configuration with details.

To avoid inspiring semantic misconceptions regarding these methods, I propose the following changes to their implementation:

Change the signature of the methods and/or their description to express the specific case in which they should be used.
Make the logger instance mandatory.
Allow for a mandatory definition of a fallback value, or a function that gets the value from a valid configuration instance; this should provide a clearer idea of which cases the method should be used for, and would return a non-null instance, solving the problem of projects with nullable check still not enabled.

As an alternative, a good idea to document the behaviour of the existing getter methods would be to ask for the inclusion of the OptionsValidationException in the methods documentation, as it is currently absent, but this would not trigger an error or a warning, as far as I am aware, if the method is called without proper exception handling.

I would argue that the service should fail if the configuration is incorrect because otherwise it really hard to find out that your configuration change is not used (and some default applies). It essentially hides the serious error and changes the behavior of the app to the one you don't expect. SOS/ECS or ClusterExlorer would show you the newly applied configuration by service would be running using default value that could lead to all kinds of problems.
Imagine you applying configuration override to take a service out of rotation (or put it into rotation) and making error in the configuration. Instead of knowing right away that something would is wrong, the service would switch to the default value obscuring the error and either all versions would be serving traffic or all of them (both cases are bad).
The same goes for the refactoring hidden behind the configuration flag, you think you've enabled it but made an error, and the service defaults to not using the new code. If the developer misses that incorrect decision could be done about refactoring functionality.
Using default if the configuration is faulty also means that integration testing (ClioudTest) would be unable to detect configuration errors since in most cases it checks that the service is running and healthy, we don't look into logs for it. So this would increase the cases when faulty configurations could be merged unnoticed and deployed to production environments.
In all scenarios that I could think of hiding configuration errors is a bad idea and I think we should not encourage this behaviour.

I see your point, and I agree that these extension methods should be seldom used, but in case the service is critically important and should work even in case of invalid configuration parsed, they could be a good way of handling human mistakes in a centralised way. I would imagine, for instance, that the operator that changes a configuration at runtime should pay attention to the application logs, and provide a unified tag for searching the error logs could be of help.
I would have added a compilation warning associated with these extension methods, but the only one I could find is the ObsoleteAttribute, that fails to express semantically what the warning would be. I would gladly accept suggestions on this.
Another purpose of the methods would be didactical, they should pose the adequate attention to the fact that the IOptionsMonitor and IOptionsSnapshot accessor could throw an exception that should be correctly handled.

My view on this is that if service is critical:

We should not have a single instance of it.
We should not apply configuration changes to all instances of the service at once. (That I believe already in guidelines and even might be enforced by SOS)

Also, as I've pointed out in reply to Keith having crucial service running with incorrect configuration (and lying to all tools that it runs on other configuration) is even more dangerous.
Besides that, methods in this PR does not provide any distinction between critical and non-critical services, so since using them looks safer everybody would use them and all configuration becomes unreliable.
About the operator checking for logs errors during applying settings override. To me, it looks like a very optimistic scenario. It's a bad idea to hope that people follow the steps that are not enforced. Especially since most of the overrides are done by people on-call or Shilelds that know nothing about the internals of this particular service and what methods are used to get the settings. If we would work on enforcing this procedure, I think, there are much better practices to enforce, for example, gradual configuration rollout with fallback in case of failure or the ability for the service to provide validation rules to the override tool. Also, added methods allow not passing the logger or using NullLogger and in combination with constant log loss by our log aggregator could result in undetectable misconfiguration (both in runtime and deploy time). And if there is a possibility for that it will happen eventually.
Omex's previous way of getting configuration provided customers with the same choice of getting configuration value or getting it safely. As a result, all of the configuration requests were done using safe methods (and PR's were blocked because people not using safe ones with default values in case of failure). As a result, it caused multiple issues when the configuration used was different from the one everybody expected and made the code more convoluted obscuring the main logic. This made sense before when everything was a single service and failing in one part could break totally unrelated things, but with smaller that each has their own area of responsibility we should not fall back to the same bad practices. It was intentional design behind not giving people tools to default back to the bad practices, creating discrepancies between reported and used configuration and obscure logic.
About compilation warnings, the way to do that is by creating code analyzers that ship with the package and could provide warnings, info messages, or even code fixes on incorrect code usage, but that's much more work. The benefit is that you can do that not only for your code, create analyzers about incorrect usages of standard classes. This repo might be a good sample for that https://github.com/xunit/xunit.analyzers
About attracting attention to the fact that Options could throw, I think it would instead push people to the bad practice since as practice shows it's easier for people to use "safe" method and don't thinking too much about it than accept the fact that the service should fail if it configured incorrectly.

I will add some more thoughts about some of the points you raised:

It is true that, semantically speaking, these methods give a wrong idea of safely getting configuration for a service, while instead they are actually handling the exception internally, logging it, and return null, but:

The logger can be made a mandatory parameter in input.
The method currently returns a nullable object that will have to be handled accordingly; although this could result in an increase of defensive programming, or to simply overlook the null object in projects that do not have nullability check enabled, the alternative would simply be uglier in case a fallback value is indeed available, having that the exception would have to be manually handled.

It is true that the person on Shield for a particular team can be unaware of the logging mechanism implemented for this kind of error, but by centralising the handling of the exception, further action can be performed to, for instance, trigger the creation of a ticket to report faulty configuration with details.

To avoid inspiring semantic misconceptions regarding these methods, I propose the following changes to their implementation:

Change the signature of the methods and/or their description to express the specific case in which they should be used.
Make the logger instance mandatory.
Allow for a mandatory definition of a fallback value, or a function that gets the value from a valid configuration instance; this should provide a clearer idea of which cases the method should be used for, and would return a non-null instance, solving the problem of projects with nullable check still not enabled.

As an alternative, a good idea to document the behaviour of the existing getter methods would be to ask for the inclusion of the OptionsValidationException in the methods documentation, as it is currently absent, but this would not trigger an error or a warning, as far as I am aware, if the method is called without proper exception handling.

About the point that you've added:
1.1 Making a logger mandatory is an improvement but does not guarantee that logs will be reported. Our log aggregator constantly loses significant about of logs (Artem can tell more about it) and we had multiple cases of logger disabled during misconfiguration or using incorrect logger.
1.2 My point is that ideally there should not be fallback for configuration errors, so by hiding ugliness of exception catching we are making it harder for users to understand that they are doing something wrong. If you absolutely insist that configuration value should be optional it could be done by providing default value in the Option class itself (it won't protect from parsing error, but SOS service should be doing that).
2. As I've pointed out before if we will put an effort into automating detection of such exception it would be much better to spend those resources on not allowing applying overrides to all instances in a single change or adding better validation. Ticket creating is too slow mechanism for reacting to misconfiguration problems (especially when it depends on log parsing that could be missing), since couple seconds of running service with incorrect settings could lead to unrecoverable data corruption. Failing a service is much more reliable in this case.
The steps that you've suggested in API changes are nice but having an API pushes library users in the wrong direction.
Adding a warning to the existing option methods could be done using Roslyn Analyzer, but my main point is that there are no reasonable actions for service when the configuration is incorrect, it should only fail.
It is similar to how each object creation can throw out of memory exception, but we are not wrapping each allocation with try/catch because we can't do anything meaningful to resolve the issue. Same here, a service that received incorrect configuration can't and should not try to fix itself (especially in a way that will create an impression that config change applied), running with misconfiguration is dangerous. We should just fail the service until the proper configuration is provided.

I would argue that the service should fail if the configuration is incorrect because otherwise it really hard to find out that your configuration change is not used (and some default applies). It essentially hides the serious error and changes the behavior of the app to the one you don't expect. SOS/ECS or ClusterExlorer would show you the newly applied configuration by service would be running using default value that could lead to all kinds of problems.
Imagine you applying configuration override to take a service out of rotation (or put it into rotation) and making error in the configuration. Instead of knowing right away that something would is wrong, the service would switch to the default value obscuring the error and either all versions would be serving traffic or all of them (both cases are bad).
The same goes for the refactoring hidden behind the configuration flag, you think you've enabled it but made an error, and the service defaults to not using the new code. If the developer misses that incorrect decision could be done about refactoring functionality.
Using default if the configuration is faulty also means that integration testing (ClioudTest) would be unable to detect configuration errors since in most cases it checks that the service is running and healthy, we don't look into logs for it. So this would increase the cases when faulty configurations could be merged unnoticed and deployed to production environments.
In all scenarios that I could think of hiding configuration errors is a bad idea and I think we should not encourage this behaviour.

I see your point, and I agree that these extension methods should be seldom used, but in case the service is critically important and should work even in case of invalid configuration parsed, they could be a good way of handling human mistakes in a centralised way. I would imagine, for instance, that the operator that changes a configuration at runtime should pay attention to the application logs, and provide a unified tag for searching the error logs could be of help.
I would have added a compilation warning associated with these extension methods, but the only one I could find is the ObsoleteAttribute, that fails to express semantically what the warning would be. I would gladly accept suggestions on this.
Another purpose of the methods would be didactical, they should pose the adequate attention to the fact that the IOptionsMonitor and IOptionsSnapshot accessor could throw an exception that should be correctly handled.

My view on this is that if service is critical:

We should not have a single instance of it.
We should not apply configuration changes to all instances of the service at once. (That I believe already in guidelines and even might be enforced by SOS)

Also, as I've pointed out in reply to Keith having crucial service running with incorrect configuration (and lying to all tools that it runs on other configuration) is even more dangerous.
Besides that, methods in this PR does not provide any distinction between critical and non-critical services, so since using them looks safer everybody would use them and all configuration becomes unreliable.
About the operator checking for logs errors during applying settings override. To me, it looks like a very optimistic scenario. It's a bad idea to hope that people follow the steps that are not enforced. Especially since most of the overrides are done by people on-call or Shilelds that know nothing about the internals of this particular service and what methods are used to get the settings. If we would work on enforcing this procedure, I think, there are much better practices to enforce, for example, gradual configuration rollout with fallback in case of failure or the ability for the service to provide validation rules to the override tool. Also, added methods allow not passing the logger or using NullLogger and in combination with constant log loss by our log aggregator could result in undetectable misconfiguration (both in runtime and deploy time). And if there is a possibility for that it will happen eventually.
Omex's previous way of getting configuration provided customers with the same choice of getting configuration value or getting it safely. As a result, all of the configuration requests were done using safe methods (and PR's were blocked because people not using safe ones with default values in case of failure). As a result, it caused multiple issues when the configuration used was different from the one everybody expected and made the code more convoluted obscuring the main logic. This made sense before when everything was a single service and failing in one part could break totally unrelated things, but with smaller that each has their own area of responsibility we should not fall back to the same bad practices. It was intentional design behind not giving people tools to default back to the bad practices, creating discrepancies between reported and used configuration and obscure logic.
About compilation warnings, the way to do that is by creating code analyzers that ship with the package and could provide warnings, info messages, or even code fixes on incorrect code usage, but that's much more work. The benefit is that you can do that not only for your code, create analyzers about incorrect usages of standard classes. This repo might be a good sample for that https://github.com/xunit/xunit.analyzers
About attracting attention to the fact that Options could throw, I think it would instead push people to the bad practice since as practice shows it's easier for people to use "safe" method and don't thinking too much about it than accept the fact that the service should fail if it configured incorrectly.

I will add some more thoughts about some of the points you raised:

It is true that, semantically speaking, these methods give a wrong idea of safely getting configuration for a service, while instead they are actually handling the exception internally, logging it, and return null, but:

The logger can be made a mandatory parameter in input.
The method currently returns a nullable object that will have to be handled accordingly; although this could result in an increase of defensive programming, or to simply overlook the null object in projects that do not have nullability check enabled, the alternative would simply be uglier in case a fallback value is indeed available, having that the exception would have to be manually handled.

It is true that the person on Shield for a particular team can be unaware of the logging mechanism implemented for this kind of error, but by centralising the handling of the exception, further action can be performed to, for instance, trigger the creation of a ticket to report faulty configuration with details.

To avoid inspiring semantic misconceptions regarding these methods, I propose the following changes to their implementation:

Change the signature of the methods and/or their description to express the specific case in which they should be used.
Make the logger instance mandatory.
Allow for a mandatory definition of a fallback value, or a function that gets the value from a valid configuration instance; this should provide a clearer idea of which cases the method should be used for, and would return a non-null instance, solving the problem of projects with nullable check still not enabled.

As an alternative, a good idea to document the behaviour of the existing getter methods would be to ask for the inclusion of the OptionsValidationException in the methods documentation, as it is currently absent, but this would not trigger an error or a warning, as far as I am aware, if the method is called without proper exception handling.

About the point that you've added: 1.1 Making a logger mandatory is an improvement but does not guarantee that logs will be reported. Our log aggregator constantly loses significant about of logs (Artem can tell more about it) and we had multiple cases of logger disabled during misconfiguration or using incorrect logger. 1.2 My point is that ideally there should not be fallback for configuration errors, so by hiding ugliness of exception catching we are making it harder for users to understand that they are doing something wrong. If you absolutely insist that configuration value should be optional it could be done by providing default value in the Option class itself (it won't protect from parsing error, but SOS service should be doing that). 2. As I've pointed out before if we will put an effort into automating detection of such exception it would be much better to spend those resources on not allowing applying overrides to all instances in a single change or adding better validation. Ticket creating is too slow mechanism for reacting to misconfiguration problems (especially when it depends on log parsing that could be missing), since couple seconds of running service with incorrect settings could lead to unrecoverable data corruption. Failing a service is much more reliable in this case.
The steps that you've suggested in API changes are nice but having an API pushes library users in the wrong direction. Adding a warning to the existing option methods could be done using Roslyn Analyzer, but my main point is that there are no reasonable actions for service when the configuration is incorrect, it should only fail. It is similar to how each object creation can throw out of memory exception, but we are not wrapping each allocation with try/catch because we can't do anything meaningful to resolve the issue. Same here, a service that received incorrect configuration can't and should not try to fix itself (especially in a way that will create an impression that config change applied), running with misconfiguration is dangerous. We should just fail the service until the proper configuration is provided.

I understand your point of view, and I understand that the problem is not actually the implementation itself, but rather how to treat a service with invalid configuration, and by that which API to provide to the developer consuming it. The options are the following:

Let the service fail, so do not do anything when the Value or CurrentValue getters are called by the IOptionses interfaces.

Pro: it gives immediate feedback on the failed service, avoiding unwanted behaviours due to incorrect configuration.
Con: the client's user experience would suffer, having that the service would actually not work.

Provide fallback manually (i.e. catching the exception manually in the project code).

Pro: it gives more control to the developer; the client's user experience would not suffer, if the fallback is provided correctly.
Cons: the fallback could be implemented in a way that will cause the service to eventually fail or behave unexpectedly; no centralised way of handling the configuration validation errors, that may easily result in hiding the error completely.

Provide fallback through API methods.

Pro: the client's user experience would not suffer.
Cons: again, the fallback (in this case, the null handling) could be done wrong, or not at all (e.g., in projects that do not have null checking enabled); potentially hiding the error indefinitely; causing the application to potentially work unexpectedly.

I can understand the problem you are highlighting, but I am unsure about how to avoid blocking the execution of the service. We should put in place the following:

Add validation to configuration overrides in SOS.
Implement a behaviour for microservices installed as multiple services by which only an instance of those service handles the configuration change, potentially failing, while allowing the other instances to work normally in the meantime.

But as far as my knowledge goes, I don't think any of this is actually currently implemented, and I cannot estimate how much time it would require.
In the meantime, providing a well-documented API could force the developers consuming it to be aware of the problem and provide fallback themselves, for instance by falling back to the configuration parsed at startup using IOptions interface, while creating error tickets, even though they are not currently instantaneous.
To resume, possible API alternatives to the ones implemented here could be:

Changing the API to allow users to define the fallback value directly as I mentioned before by a lambda, thus solving the problem with projects with nullability disabled, and improving documentation.
Another interface inheriting from IOptionsMonitor providing a getter with the last valid configuration, that would have to be implemented thread-safely. I didn't want to implement that because it would be a serious deviation from the standard, rather than an extension of it.
Documenting strategies to handle configuration validation errors using the Option patter, asking the team handling the Microsoft.Extensions.Options maintainer to add documentation about the exception thrown by the configuration value getters.

I would argue that the service should fail if the configuration is incorrect because otherwise it really hard to find out that your configuration change is not used (and some default applies). It essentially hides the serious error and changes the behavior of the app to the one you don't expect. SOS/ECS or ClusterExlorer would show you the newly applied configuration by service would be running using default value that could lead to all kinds of problems.
Imagine you applying configuration override to take a service out of rotation (or put it into rotation) and making error in the configuration. Instead of knowing right away that something would is wrong, the service would switch to the default value obscuring the error and either all versions would be serving traffic or all of them (both cases are bad).
The same goes for the refactoring hidden behind the configuration flag, you think you've enabled it but made an error, and the service defaults to not using the new code. If the developer misses that incorrect decision could be done about refactoring functionality.
Using default if the configuration is faulty also means that integration testing (ClioudTest) would be unable to detect configuration errors since in most cases it checks that the service is running and healthy, we don't look into logs for it. So this would increase the cases when faulty configurations could be merged unnoticed and deployed to production environments.
In all scenarios that I could think of hiding configuration errors is a bad idea and I think we should not encourage this behaviour.

I see your point, and I agree that these extension methods should be seldom used, but in case the service is critically important and should work even in case of invalid configuration parsed, they could be a good way of handling human mistakes in a centralised way. I would imagine, for instance, that the operator that changes a configuration at runtime should pay attention to the application logs, and provide a unified tag for searching the error logs could be of help.
I would have added a compilation warning associated with these extension methods, but the only one I could find is the ObsoleteAttribute, that fails to express semantically what the warning would be. I would gladly accept suggestions on this.
Another purpose of the methods would be didactical, they should pose the adequate attention to the fact that the IOptionsMonitor and IOptionsSnapshot accessor could throw an exception that should be correctly handled.

My view on this is that if service is critical:

We should not have a single instance of it.
We should not apply configuration changes to all instances of the service at once. (That I believe already in guidelines and even might be enforced by SOS)

Also, as I've pointed out in reply to Keith having crucial service running with incorrect configuration (and lying to all tools that it runs on other configuration) is even more dangerous.
Besides that, methods in this PR does not provide any distinction between critical and non-critical services, so since using them looks safer everybody would use them and all configuration becomes unreliable.
About the operator checking for logs errors during applying settings override. To me, it looks like a very optimistic scenario. It's a bad idea to hope that people follow the steps that are not enforced. Especially since most of the overrides are done by people on-call or Shilelds that know nothing about the internals of this particular service and what methods are used to get the settings. If we would work on enforcing this procedure, I think, there are much better practices to enforce, for example, gradual configuration rollout with fallback in case of failure or the ability for the service to provide validation rules to the override tool. Also, added methods allow not passing the logger or using NullLogger and in combination with constant log loss by our log aggregator could result in undetectable misconfiguration (both in runtime and deploy time). And if there is a possibility for that it will happen eventually.
Omex's previous way of getting configuration provided customers with the same choice of getting configuration value or getting it safely. As a result, all of the configuration requests were done using safe methods (and PR's were blocked because people not using safe ones with default values in case of failure). As a result, it caused multiple issues when the configuration used was different from the one everybody expected and made the code more convoluted obscuring the main logic. This made sense before when everything was a single service and failing in one part could break totally unrelated things, but with smaller that each has their own area of responsibility we should not fall back to the same bad practices. It was intentional design behind not giving people tools to default back to the bad practices, creating discrepancies between reported and used configuration and obscure logic.
About compilation warnings, the way to do that is by creating code analyzers that ship with the package and could provide warnings, info messages, or even code fixes on incorrect code usage, but that's much more work. The benefit is that you can do that not only for your code, create analyzers about incorrect usages of standard classes. This repo might be a good sample for that https://github.com/xunit/xunit.analyzers
About attracting attention to the fact that Options could throw, I think it would instead push people to the bad practice since as practice shows it's easier for people to use "safe" method and don't thinking too much about it than accept the fact that the service should fail if it configured incorrectly.

I will add some more thoughts about some of the points you raised:

It is true that, semantically speaking, these methods give a wrong idea of safely getting configuration for a service, while instead they are actually handling the exception internally, logging it, and return null, but:

The logger can be made a mandatory parameter in input.
The method currently returns a nullable object that will have to be handled accordingly; although this could result in an increase of defensive programming, or to simply overlook the null object in projects that do not have nullability check enabled, the alternative would simply be uglier in case a fallback value is indeed available, having that the exception would have to be manually handled.

It is true that the person on Shield for a particular team can be unaware of the logging mechanism implemented for this kind of error, but by centralising the handling of the exception, further action can be performed to, for instance, trigger the creation of a ticket to report faulty configuration with details.

To avoid inspiring semantic misconceptions regarding these methods, I propose the following changes to their implementation:

Change the signature of the methods and/or their description to express the specific case in which they should be used.
Make the logger instance mandatory.
Allow for a mandatory definition of a fallback value, or a function that gets the value from a valid configuration instance; this should provide a clearer idea of which cases the method should be used for, and would return a non-null instance, solving the problem of projects with nullable check still not enabled.

As an alternative, a good idea to document the behaviour of the existing getter methods would be to ask for the inclusion of the OptionsValidationException in the methods documentation, as it is currently absent, but this would not trigger an error or a warning, as far as I am aware, if the method is called without proper exception handling.

About the point that you've added: 1.1 Making a logger mandatory is an improvement but does not guarantee that logs will be reported. Our log aggregator constantly loses significant about of logs (Artem can tell more about it) and we had multiple cases of logger disabled during misconfiguration or using incorrect logger. 1.2 My point is that ideally there should not be fallback for configuration errors, so by hiding ugliness of exception catching we are making it harder for users to understand that they are doing something wrong. If you absolutely insist that configuration value should be optional it could be done by providing default value in the Option class itself (it won't protect from parsing error, but SOS service should be doing that). 2. As I've pointed out before if we will put an effort into automating detection of such exception it would be much better to spend those resources on not allowing applying overrides to all instances in a single change or adding better validation. Ticket creating is too slow mechanism for reacting to misconfiguration problems (especially when it depends on log parsing that could be missing), since couple seconds of running service with incorrect settings could lead to unrecoverable data corruption. Failing a service is much more reliable in this case.
The steps that you've suggested in API changes are nice but having an API pushes library users in the wrong direction. Adding a warning to the existing option methods could be done using Roslyn Analyzer, but my main point is that there are no reasonable actions for service when the configuration is incorrect, it should only fail. It is similar to how each object creation can throw out of memory exception, but we are not wrapping each allocation with try/catch because we can't do anything meaningful to resolve the issue. Same here, a service that received incorrect configuration can't and should not try to fix itself (especially in a way that will create an impression that config change applied), running with misconfiguration is dangerous. We should just fail the service until the proper configuration is provided.

I understand your point of view, and I understand that the problem is not actually the implementation itself, but rather how to treat a service with invalid configuration, and by that which API to provide to the developer consuming it. The options are the following:

Let the service fail, so do not do anything when the Value or CurrentValue getters are called by the IOptionses interfaces.

Pro: it gives immediate feedback on the failed service, avoiding unwanted behaviours due to incorrect configuration.
Con: the client's user experience would suffer, having that the service would actually not work.

Provide fallback manually (i.e. catching the exception manually in the project code).

Pro: it gives more control to the developer; the client's user experience would not suffer, if the fallback is provided correctly.
Cons: the fallback could be implemented in a way that will cause the service to eventually fail or behave unexpectedly; no centralised way of handling the configuration validation errors, that may easily result in hiding the error completely.

Provide fallback through API methods.

Pro: the client's user experience would not suffer.
Cons: again, the fallback (in this case, the null handling) could be done wrong, or not at all (e.g., in projects that do not have null checking enabled); potentially hiding the error indefinitely; causing the application to potentially work unexpectedly.

I can understand the problem you are highlighting, but I am unsure about how to avoid blocking the execution of the service. We should put in place the following:

Add validation to configuration overrides in SOS.
Implement a behaviour for microservices installed as multiple services by which only an instance of those service handles the configuration change, potentially failing, while allowing the other instances to work normally in the meantime.

But as far as my knowledge goes, I don't think any of this is actually currently implemented, and I cannot estimate how much time it would require. In the meantime, providing a well-documented API could force the developers consuming it to be aware of the problem and provide fallback themselves, for instance by falling back to the configuration parsed at startup using IOptions interface, while creating error tickets, even though they are not currently instantaneous. The cost in this case could be that, by implementing the definitive strategy at service-orchestration level, we would have to mark these extension methods as Obsolete and rely on the developer consuming them to get rid of it.
To resume, possible API alternatives to the ones implemented here could be:

Changing the API to allow users to define the fallback value directly as I mentioned before by a lambda, thus solving the problem with projects with nullability disabled, and improving documentation.
Another interface inheriting from IOptionsMonitor providing a getter with the last valid configuration, that would have to be implemented thread-safely. I didn't want to implement that because it would be a serious deviation from the standard, rather than an extension of it.
Documenting strategies to handle configuration validation errors using the Option patter, asking the team handling the Microsoft.Extensions.Options maintainer to add documentation about the exception thrown by the configuration value getters.

Option 1. Cons:
Client experience should not suffer. Even before SOS was created there was a rule that every person applying override should follow: "Do not apply overrides to all instances of the service at once". So if you applied incorrect override to some instances client would be redirected to the one that are guaranty to have correct configuration. On a contrary client calling misconfigured service could result in bad experience or data corruption.
Option 2/3. Cons:

Service failing is not the worth consequences. Imagine misconfigured service calling incorrect database/endpoint or passing incorrect information to the partners corrupting data that is impossible to recover. Fallback means that it would take longer for the person doing overrides to notice an error and as a result incorect override actually could be applied to more or all instances before problem discovered. So all instances won't work and clinent experience would suffer.
Another important point that you are missing is that SOS, ClusterExplorer, configuration dump and any other standard tool would show developer incorect configuration in this case. That's one of my main problems with with this approach. Service is lying to us and unless you are intimately familiar with its internals it's very hard to detect, when couple seconds of misconfiguration could cause unrecoverable damage.
Creating correct fallback is hard. I don't trust service developers doing it right and don't want to add this complexity for them when it's not needed. And they unable to change the fact service reporting one configuration but running with another.

About API alternatives that you are listing:
They all discuss different ways service instance should handle configuration error. My main point is that it can't and shouldn't be handled at instance level it's for service orchestrator to deal with.
In terms of other possible improvements to the process:
Just fooling the rule "Do not apply overrides to all instances of the service at once" already a protection, unless we would make failure harder to detect :).
If you are interested in improving SOS very easy UI change is to restrict applying override to all instances at once, requiring some wait period after override applied the half of instances.
More advance options could be check with diagnostic service that instances with this override are healthy before allowing user to apply override. Or doing gradual override automatically when SOS applies changes to single instance waits for some period and then applies to the next one. Ideally it should check service health between overrides and do automatic rollbacks, but just adding wait time between overrides give opportunity for user to notice error and act.
Ideal long term solution is moving to configuration deployments that SF (and hopefully AKS also) knows about and could handle proper rollout strategy for us automatically.
In terms of using this methods as temporary solution:
I'm not a big fan of temporary decisions. Removing code is much harder then adding it. Creation of those libraries took two years instead of couple month due to the layers of temporary decisions that where added but never revisited. I don't think that we should raise awareness about the problem service developers unable to solve properly and force them two write more protection/fallback code and then hopefully ask to remove it. It's easy ask person to add try/catch or call a method with "Safe" in the name, but hard to convince that it's safe to remove this protection.
Our job as platform developers, the way I see it, is not pushing more complexity and decisions on service developers, but proving them with the simplest as possible way of writhing business logic and handling all infrastructure related issues for them especially in cases when they have no way of handling it correctly.

There has been a lot written so far, but I would summarise as following:
The absolute worst thing to do is for an application to stop functioning when someone makes a live setting change. The setting override systems are usually disconnected from the service code that defines what values they can be set at making it not feasible to limit setting values on input. Relying on slow rollout systems to catch setting problems is also dangerous as the issue may not be realised until a critical % of users are being impacted.
However, hiding the change is also not a great option as developers/engineers/live site support do not get a clear view on what changes have been made and why and the current state of the system is indeterminate (although I'd argue this is always a case as secret settings are also completely hidden).
The problem then becomes one of education of the developer (i.e. clear guidelines as to what type of Option pattern to use) in combination with clear messaging when something bad occurs (i.e. monitoring when a setting change is picked up, is invalid, and then an alert created).
The best fix is that the systems that change the settings are tightly coupled with the setting values themselves to disallow invalid values up front. As most system are moving away from tight coupling, this isn't a great option.
Which makes the next best fix to handle the expected error and alert on it, understanding that the alerting could be implemented differently per service.
We are currently looking at the R9 settings implementation to see what happens there, but most of these systems are starting to use safe defaults when errors occur and expect engineers/service owners to design accordingly.

There has been a lot written so far, but I would summarise as following:
The absolute worst thing to do is for an application to stop functioning when someone makes a live setting change. The setting override systems are usually disconnected from the service code that defines what values they can be set at making it not feasible to limit setting values on input. Relying on slow rollout systems to catch setting problems is also dangerous as the issue may not be realised until a critical % of users are being impacted.
However, hiding the change is also not a great option as developers/engineers/live site support do not get a clear view on what changes have been made and why and the current state of the system is indeterminate (although I'd argue this is always a case as secret settings are also completely hidden).
The problem then becomes one of education of the developer (i.e. clear guidelines as to what type of Option pattern to use) in combination with clear messaging when something bad occurs (i.e. monitoring when a setting change is picked up, is invalid, and then an alert created).
The best fix is that the systems that change the settings are tightly coupled with the setting values themselves to disallow invalid values up front. As most system are moving away from tight coupling, this isn't a great option.
Which makes the next best fix to handle the expected error and alert on it, understanding that the alerting could be implemented differently per service.
We are currently looking at the R9 settings implementation to see what happens there, but most of these systems are starting to use safe defaults when errors occur and expect engineers/service owners to design accordingly.

"The absolute worst thing to do is for an application to stop functioning when someone makes a live setting change."
Imagine a case when the default value for blob storage location is set to test storage (reasonable default). A customer works with this service to save data in production and it looks okay, but when we finally find out mistake in configuration all data saved meanwhile disappears. I would argue that it would've been better for the service to fail right away.
"issue may not be realised until a critical % of users are being impacted" I would argue that this happens when developers catch configuration errors and try to use default :) And it's the job of the override system to make sure that rollout could be done safely.
" I'd argue this is always a case as secret settings are also completely hidden" secrets just hidden and we unable to see them, with this change SOS, ClusterExplorer, Config dump would show us value1 but in reality value2 would be used.
"The problem then becomes one of education of the developer" In my experience educating developers never works until you make incorrect way impossible, only then do they look in docs or search for guidance.
Also, I would like to note that this change would bring us back to the state when CloutTest and INT environments are useless for configuration validation, since ever when none of the configurations is available or correct service would continue working using defaults (that usually points to INT values). For me ephemeral protection from typos during config overrides does not worth it, it's better to try educating developers to override safely or ensure those safe rollout rules in SOS.

Looks like PR comments is not the best place for such discussions, we should talk about it separately. Also, don't forget that it's a public repo and we might accidentally disclose too much about our environments.
I suggest to take some real life scenarios and discuss them elsewhere. In their current form these methods don't provide a dev experience improvement.


Update README.md

added https to MagenTys url ;-)

Best PR yet!
They all count!!!
On 21 Mar 2017 7:38 PM, "Liam"<EMAIL_ADDRESS>wrote:

added https to MagenTys url ;-)
You can view, comment on, or merge this pull request online at:
https://github.com/MagenTys/donut/pull/27
Commit Summary

Update README.md

File Changes

M README.md
https://github.com/MagenTys/donut/pull/27/files#diff-0 (4)

Patch Links:

https://github.com/MagenTys/donut/pull/27.patch
https://github.com/MagenTys/donut/pull/27.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MagenTys/donut/pull/27, or mute the thread
https://github.com/notifications/unsubscribe-auth/AEL_U5MjYvRTMqs_b7uVSXhSxyzx07IKks5rn7ahgaJpZM4MjrL0
.


Fix breaking OSS-Fuzz coverage build

Coverage remained the same at 82.632% when pulling b1455b847c4cf2c4e02ab6c7a8674f9a65d3da5c on DavidKorczynski:patch-1 into d1aff18e3c6b03bf3a1b6ca2826417c48995f4c1 on Geal:master.

Thanks


Updated Extraplanetary Launchpads to 1.2.0

You need to add a ksp_version if you're using dowload.
@politas, @ayan4m1, We should also check for vrefs if no ksp_version is given

I did verify this using netkan and it did produce a correct ckan file with the correct ksp version and mod version.

That is true, but Jenkins is more stubborn then netkan.exe

So what is line should I add?
ksp_version, version or both?

"ksp_version": "1.2.0",

This should fix it.

Yep, merging


tv.Variable doc: fix typo

'b' does not exist in the example, probably 'y' was meant.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

I signed it!

I signed it!


Move GUI to separate module

A lot of users suggest this, so better move it out and document GUI-less API properly.

+1, any news on this @Kagami?

Currently no.

IMHO, it should be mentioned in the README that vmsg can also be used without displaying any UI (although it's shipped with it). I only randomly discovered this when studying the vmsg.js.
Example:
<script type="module">
    import {
        Recorder
    } from "/lib/vmsg/vmsg.js";
    window.startRecording = function () {
        if (!window.recorder) {
            window.recorder = new Recorder({
                wasmURL: "/lib/vmsg/vmsg.wasm"
            });
            window.recorder.init().then(() => window.recorder.startRecording());
        }
        else {
            window.recorder.startRecording();
        }
    }
    window.stopRecording = async function () {
        await window.recorder.stopRecording();
        return window.recorder.blobURL;
    }
</script>

There is example with custom UI in readme.


[Feature]: Operator can get consistent logs from korifi-controllers-controller-manager

Blockers/Dependencies
Background
As a Operator
I want predictable and consistent log format
So that I can use tools to search and organize logs
Acceptance Criteria
GIVEN a Korifi deployment
WHEN I kubectl logs -n korifi-controllers-system korifi-controllers-controller-manager-xxxxxxxxxx-xxxxx manager
THEN I see that the results are consistently formatted in json following this proposal
Dev Notes
See implementation notes in the proposal for suggestions
Some logging appears to come from the k8s code, e.g.
I0603 20:05:55.339392       1 request.go:601] Waited for 1.040934921s due to client-side throttling, not priority and fairness, request: GET:https://<IP_ADDRESS>:443/apis/acme.cert-manager.io/v1?timeout=32s
I0603 20:05:25.656018       1 leaderelection.go:248] attempting to acquire leader lease korifi-controllers-system/13c200ec.cloudfoundry.org...

This logging is in a different format from the other log lines from the same executable. We may have some work to do in order to make sure we have loggers consistently plumbed through the layers in our code.

Some logging appears to come from the k8s code, e.g.
I0603 20:05:55.339392       1 request.go:601] Waited for 1.040934921s due to client-side throttling, not priority and fairness, request: GET:https://<IP_ADDRESS>:443/apis/acme.cert-manager.io/v1?timeout=32s
I0603 20:05:25.656018       1 leaderelection.go:248] attempting to acquire leader lease korifi-controllers-system/13c200ec.cloudfoundry.org...

Based on https://github.com/kubernetes-sigs/controller-runtime/issues/1420 we may not be able to control the logger used by client-go in the leaderelection package, so those logs will remain controlled by the default klog implementation.

A/C passed


Cannot extend lint process anymore

With the release of the beta28 version and due to this PR, we cannot extend the ng lint command which is a serious regression for my projects.
With the previous beta26, by changing the npm scripts section we could extend the lint process like this:
  "scripts": {
    "lint": "tslint \"src/**/*.ts\" \"e2e/**/*.ts\" && stylelint \"src/**/*.scss\" --syntax scss && htmlhint \"src\""

Now that this was removed, we cannot extend the behavior of ng lint anymore with the addition of stylelint and htmllint...
This is quite a regression, while I understand the move to the tslint API for better integration, it also complicates the process by hiding it behind JSON settings and kills any customization like the one I was doing. For the meanwhile I'll move my process to use npm scripts directly, but it would be nice to find some middle ground on this.
This sort of breaking changes kinda make me worry about the future of angular-cli, removing customization features like this are bad in a maintenance update (yeah I understand it's still beta, still).

A few comments, all non official but I understand them having monitored the project for a bit:

The versioning process will not respect semver before v1.0.0 final.

The team wants extensibility points to be explicit and planned and optional

For v1, full control for the CLI is the direction
Extension points (a plug-in system yet to start being defined) planned AFTER v1.0.0.

tslint is still included as dev dependency. The same npm lint script should still work, just not from ng lint. Note that the --lint option in ng test removed (or deprecated if still there).
It's worth mentioning that I have a project that I just migrated to beta.29. It uses the npm lint task directly called from another npm script I created for my CI, and it still works. So, I'm telling this from first hand experience.

@sinedied, as @Meligy mentioned, I don't think that will be a thing should be considered for 1.0@final.
Your extension of the npm script is an unintended use case as it was intended to only be for tslint. When we have the addon system in place (post 1.0@final), I think you will see additional linting processes available.
For now, you are still able to use ng lint in combination with other linters.
"scripts": {
  "lint": "ng lint && other-linter-here && other-linter-here"
}

You said you do understand it, but I feel it's appropriate to call it out again. This is a beta application. I realize it's sometimes not treated as such, but it hasn't reached rc/final for a reason. There are some features (in this case linting) that aren't fully fleshed out yet.

Ok, so I ended up relying only on npm scripts for now so I can avoid future troubles until 1.0@final is out, but that sorta kills the ng cli idea.
Sorry if I seemed too demanding, but the quality of what you qualify as a beta is already way better that any other production-ready systems out there for Angular 2 (and even for general frontend development), so you may understand I have high expectations for it :)
I'll way for the addon system, but I really like the idea of extending ng commands via simple npm scripts, that should be kept in mind for consideration ;)

You're not being demanding at all. It's definitely something to consider and it pays to call out how people were using the ng lint command previously.
That said, I don't think it kills the ng cli idea. We're just not at the point of having addons. It's something that's on the radar and having ideas of what addons would be useful will help with the final design of the addon system.
To your last comment, I'll beat the dead horse a little more... addon 😉

I am having the same issue as my fellow developer and going for the same solution. Just want to drop, that I also really like the simple and straight forward way to extend the functionality via simple npm scripts. E.g. I use a similar approach for ng server where I have this start script:
"start": "ng serve --proxy-config proxy.conf.json & npm run mock-rest".
But overall, thank you for your effort! This CLI is awesome and such a help I cannot describe! 👍


Increase ValidatorEntry's TotalStakeAmountNanos when a user receives a reward that is restaked

Current dependencies on/for this PR:

feature/proof-of-stake

PR #831

PR #837   👈

This stack of pull requests is managed by Graphite.


Re-enable JEI support

Update JEI and re-add Curios to runtime for testing purposes
Remove double forge maven
Also remove jcenter from the buildscript as it's no longer in use

amazing!

looks good! tested and uploaded https://www.curseforge.com/minecraft/mc-mods/inventory-crafting-grid/files/4032713


#10900: Make bfloat16 constexpr trivial class

Ticket
https://github.com/tenstorrent/tt-metal/issues/10900
Problem description
bfloat16 contains unnecessary non-trivial default constructor and use of reinterpret_cast where std::bit_cast can be used. The header also contains a global using namespace std;
What's changed
The class is refactored to be constexpr and trivial, and the global using namespace has been removed.
Checklist

[ ] Post commit CI passes
[ ] Model regression CI testing passes (if applicable)
[ ] New/Existing tests provide coverage for changes

I changed operator<=> to operator== since ordered inequalities may not always yield the correct result for when comparing the integral representations. A defaulted operator== synthesizes the operator!= so it's not necessary to define that explicitly.


no partitions defined while using dind (docker in a docker) with gitlab ci runner

I am facing the same issue, while using gitlab ci runner, even when using: -v /dev:/dev
build_os_dist:
image: "docker:latest"
stage: .pre
services:

docker:dind
script:
apk update
apk add git
git clone https://github.com/solo-io/packer-plugin-arm-image
cd packer-plugin-arm-image
docker run --rm --privileged -v /dev:/dev -v {PWD}/packer_cache:/build/packer_cache -v ${PWD}/output-arm-image:/build/output-arm-image ghcr.io/solo-io/packer-plugin-arm-image build samples/raspbian_golang.json
tags:
linux

Output...
==> arm-image: Copying source image.
==> arm-image: Image is a zip file.
==> arm-image: Unzipping 2020-02-13-raspbian-buster-lite.img
arm-image: Speed: 148.38 MB/s
arm-image: Progress: 40.25%
arm-image: Speed: 91.92 MB/s
arm-image: Progress: 65.03%
arm-image: Speed: 55.48 MB/s
arm-image: Progress: 80.06%
==> arm-image: Growing partition to 4096 M<PHONE_NUMBER> bytes)
arm-image: mapping output-arm-image/image
==> arm-image: losetup --show -f -P output-arm-image/image
==> arm-image: partitions: []
==> arm-image: no partitions defined
Build 'arm-image' errored after 33 seconds 467 milliseconds: step canceled or halted
==> Wait completed after 33 seconds 467 milliseconds
==> Some builds didn't complete successfully and had errors:
--> arm-image: step canceled or halted
==> Builds finished but no artifacts were created.
Cleaning up project directory and file based variables

I faced the same problem. Make sure you are not overwritten any previously created images that may exist in the images directory. For me I created an Ubuntu 20.04 image and the next time I was creating an Ubuntu 22.04 Image but I forgot to save the .img to a different file which was causing this error. I make use of packer-variables to make it more automated.

Aha, this looks the same as my issue, so I don't think this is specific to DIND
In my case, running natively on an RPi (i.e. outside of Docker)
source "arm-image" "raspios" {
  iso_url      = "https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_arm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz"
  iso_checksum = "sha256:35f1d2f4105e01f4ca888ab4ced6912411e82a2539c53c9e4e6b795f25275a1f"
  target_image_size =<PHONE_NUMBER>
}

arm-image.raspios: output will be in this color.

==> arm-image.raspios: Image type: raspberrypi
==> arm-image.raspios: Retrieving Image
==> arm-image.raspios: Trying https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_arm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz
==> arm-image.raspios: Trying https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_arm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz?checksum=sha256%3A35f1d2f4105e01f4ca888ab4ced6912411e82a2539c53c9e4e6b795f25275a1f
==> arm-image.raspios: https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_arm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz?checksum=sha256%3A35f1d2f4105e01f4ca888ab4ced6912411e82a2539c53c9e4e6b795f25275a1f => /root/.cache/packer/9d8ad4fe8b6f43457efbb1512fc630e91f8b50ba.iso
==> arm-image.raspios: Copying source image.
==> arm-image.raspios: Image is a xz file.
    arm-image.raspios: Speed:   87.07 MB/s
    arm-image.raspios: Speed:   31.72 MB/s
    arm-image.raspios: Speed:   23.69 MB/s
    arm-image.raspios: Speed:   22.56 MB/s
    arm-image.raspios: Speed:   20.01 MB/s
    arm-image.raspios: Speed:    8.31 MB/s
    arm-image.raspios: Speed:   13.33 MB/s
    arm-image.raspios: Speed:   22.38 MB/s
    arm-image.raspios: Speed:    8.96 MB/s
    arm-image.raspios: Speed:   16.15 MB/s
    arm-image.raspios: Speed:   13.78 MB/s
    arm-image.raspios: Speed:   19.24 MB/s
    arm-image.raspios: Speed:   77.70 MB/s
==> arm-image.raspios: Growing partition to 3072 M<PHONE_NUMBER> bytes)
    arm-image.raspios: mapping output-raspios/image
==> arm-image.raspios: losetup --show -f -P output-raspios/image
==> arm-image.raspios: partitions: []
==> arm-image.raspios: no partitions defined
Build 'arm-image.raspios' errored after 1 minute 41 seconds: step canceled or halted

@shantanoo-desai's suggestion

Make sure you are not overwriting any previously created images that may exist in the images directory. For me I created an Ubuntu 20.04 image and the next time I was creating an Ubuntu 22.04 Image but I forgot to save the .img to a different file which was causing this error.

doesn't apply in my case, because I'm running this packer build from a completely fresh directory every time


protonvpn-gui: dns stops working after removing package

Describe the bug
A clear and concise description of what the bug is.
After removing the package protonvpn-gui, resolved changed the dns interface to ipv6leakintrf0, blocking any dns requests even after rebuilding the configuration
Steps To Reproduce
Steps to reproduce the behavior:

Install protonvpn-gui
Uninstall protonvpn-gui

Expected behavior
After removing the package, the interface ipv6leakintrf0 it created should be removed as well
Additional context
the issue was solved after removing the interface using
sudo ip link delete ipv6leakintrf0
and running the garbage collector, I do not know which step actually fixed the issue
Notify maintainers
@wolfangaukang
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.5.3-zen1, NixOS, 23.11 (Tapir), 23.11pre527133.5ba549eafcf3`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.17.0`
 - channels(root): `"home-manager, nixos"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Did you disconnect first? That interface should be gone when protonvpn is disconnected. Closing the GUI is not enough; it will remain in the background.


Use-case diagram updates for continuous-testing and continuous-integration

Please review. ...

@riverma All changes have been made with the exception of this. The guidance conflicts with yesterday's guidance to simplify and pare down hanging nodes. Perhaps we can address this in upcoming weeks. ...


Gem name is not elegant

I realize this is VERY subjective, but I think it would make sense to rename the gem - or at least its CLI executable - to something more elegant. Having _ in the name feels off, very rarely do CLI applications have underscores in their names.
Someone on the Modularity slack mentioned packwerker as an option. This feels more elegant, but I'm afraid this can cause confusion about the relation between packwerk and packwerker.
I'm not proposing a specific name at this point though.

Hi Oleg 👋
Great point (and packwerker is too clever not to use somewhere 💡 ).
This may be something that you can do locally in the meantime by using a binstub to rename it.

Hey @oleg-vinted –
We were thinking of possibly renaming use_packs to just packs and renaming packs to packs-specification. What would you think of that?


Resolve core_data usage

Decide on and implement the adoption of the core_data method in the dask branch.
Do we want to commit to introducing this into the public API?
If not, what is the impact? What changes are required?
Consider the impact on:

cube
data manager
PP and GRIB proxies and rules processing etc

After discussion, we have decided to maintain the status quo here.


Freeze is not available in the Arch Repository

Hi Just saw the twitter post and I really felt like its the tool I need every day. While I was installing I found out that it looks like Freeze is not yet downloadable on Arch Linux via Pacman, but yet it is mentioned in the README. Is it really not up in the Arch Repository or am I missing something ?
Tho, I've downloaded the Binary!
Thank You

It's packaged as freeze-bin

yes that's correct
thanks @FoxxMD