Working on settings / config sources.

[jtkech]

This is on the continuation of #4001 defining caching rules, also related to #4107.

• One rule being to update internal data by re-reading a store (shared or not), not just relying on the fact that we have updated them just before storing them. There are others places that would need to be updated, here i applied this rule to the shell settings / configurations.

• So, here when we update a tenant and reload it, the related shell settings are reloaded so that after having updated a given tenant through tenants.json or its specific appsettings.json, if i reload it through the admin i can see the changes under the tenants page (was not the case before).

  I think it's a more complete tenant reloading. Then in a distributed environment where a distributed event will be sent on a tenant reloading, on each instance this tenant will be reloaded by loading and using the updated settings coming e.g from a shared source.

  If an library API allows to update a shared source from an OC app e.g through the admin, the distributed event could be sent automatically. We could then think about a config provider based on Redis, maybe after on blob, database ...

• Note: Maybe an idea to also have in the admin a soft app restart that would reload all tenants.

Note: For a config provider based on the database we could use a light scope for a given tenant as we do to see if a given shell descriptor exists. Or a IDbConnectionAccessor as used in ShellDescriptorManager by UpgradeFromBeta2. In both case, on saving a new transaction would need to be created and committed.

Question: Can we remove UpgradeFromBeta2(), hmm at least in the 3.0 branch, notice that this code is always executed when creating a new tenant.

[jtkech]

• UpgradeFromBeta2 has been removed in the 3.0 branch.

• I could make ShellConfigurationSources.Save and ShellsSettingsSources.Save async (i lost my changes but easy to redo). Maybe useful if an implementation is able to update an external source, let me know.

[jtkech]

As i have time i will re-think about making save settings async.
If it could be useful when storing data in a shared external store.

[sebastienros]

Load the settings before:

if (settings.State != TenantState.Initializing)
{
  settings = _shellSettingsManager.LoadSettings(settings.Name);
}

Remove the boolean to reload settings.

[jtkech]

@sebastienros i think this one is ready, we already reviewed it together ;)

Update: Fixes #4734

[jtkech]

@sebastienros

So, after merging dev, i began to update the files related to #2450 Tenant Workflow, but right now i just fixed the build on my side because seems that there is more work to do

• The enable and disable tasks does nothing.

• For other tasks, i would say that in place of using new ShellSettings() in some places, we would have to use

  // Creates a default shell settings based on the configuration.
  shellSettings = ShellSettingsManager.CreateDefaultSettings();
  

  But just saw that the default ShellSettings ctor now does the same, so that's ok.

  But after we would need to take into account preconfigured data in place of overriding all of them in the create / setup tenant tasks.

• The create task saves the settings and returns Done even if the tenant name is not provided. Maybe intended so that a next setup task will provide it, but see below.

• In the setup task, if the settings related to the provided tenant name is not found, we create a new settings but not with all data. I assume that the setup task is intended to execute after the create tenant task to provide remaining data to do a setup. So, if we don't retrieve the previous settings related to a tenant name, maybe better to just return Failed in this case.

• It doesn't follow the save / reload pattern, e.g LoadSettings() in place of TryGetSettings(), this to take into account all the configuration stack. But this is related to what my PR has to do.

Maybe i misunderstood some things, so i would need to tried it, well understand it and then update it.

The problem with my PR, idem for #4001, is that, if it takes a too long time to be merged, it becomes not so easy to maintain, e.g to fix those that are related but merged before.

So not so motivated, i would be if this PR and #4001 will not take again a long time to be merged.