Remove confusing parameter from AzureSilo.Start

[benjaminpetit]

Yes, it is a breaking change.

But currently if you do something like this:

var config = AzureSilo.DefaultConfiguration();
config.Globals.DeploymentId = "aca7e5e9105745a0b82be8c5a6b07215";
config.AddAzureTableStorageProvider("AzureStore");
orleansAzureSilo = new AzureSilo();
bool ok = orleansAzureSilo.Start(config);

The Start method will partially ignore the DeploymentId that is in the configuration which is confusing.

[jdom]

maybe you can keep the method signature as is, and here do:
deploymentId = deploymentId ?? host.Config.Globals.DeploymentId ?? serviceRuntimeWrapper.DeploymentId;

This way the change will not be breaking, just doing fallbacks

[benjaminpetit]

It is still confusing for the caller, I don't think it is bad to have a breaking change in this case. I think we should allow to pass a config or a deploymentId that will override the value from the config, but not both.

[jdom]

yeah, I also find this very confusing, and think it stems from when Orleans was XML config based only. I think that even today there are still deployments with a static XML configuration, but they want to just override the deploymentId in code. Granted, instead of just calling Start, they could go through the process of manually loading the XML config, then updating the deploymentId, and then calling start.
But I'd be wary about making this breaking change, when we are already thinking that several breaking changes to config/startup are coming in our Orleans 2.0 release.

[jdom]

btw, looks like my concern is addressed in the latest rebase

[jdom]

does this mean that if the user has an XML configuration, he must explicitly use serviceRuntimeWrapper directly?

[benjaminpetit]

No, we don't rely on serviceRuntimeWrapper here. If the user has an XML configuration and want to override the deploymentId, he should use Start(string deploymentId = null, string connectionString = null)

[jdom]

sure, but does he have to manually pass in what was previously the default (the hosted service deployment id)?

[benjaminpetit]

Yes

[jdom]

The most common use case is that you use Azure's Hosted Service DeploymentId. Overriding is a nice to have.
With the current code in commit fa7a810 this is still the case if you use programmatic config (you start with AzureSilo.DefaultConfiguration()).
Nevertheless if you use an external XML config, this default is lost, and it will use the hardcoded deploymentId in the XML. This default should be preserved by the PR, regardless of how you handle fallbacks or mutually exclusive overrides.