Add Cluster properties and rename DeploymentId to ClusterId

[nehmebilal]

This PR addresses issue #33

For a quick overview of the changes in the Api and DeploymentConfig.json, take a look at the tests.

The new DeploymentConfig.json is as follows:

{
    "Applications":
    [
        {
            "Id": "app1",
            "Version": "1.0.0",
            "TargetClusters": [ "YAMS_CLUSTER_ID" ],
            "Properties":
            {
                "NodeType": "PROD"
            }
        },  
        {
            "Id": "app1",
            "Version": "1.0.1",
            "TargetClusters": [ "YAMS_CLUSTER_ID"],
            "Properties":
            {
                "NodeType": "QA"
            }
        },
    ]
}

DeploymentIds has been renamed to TargetClusters and the DeploymentId token has been renamed to ClusterId. I didn't end up adding the 'Yams' prefix because it was quickly spreading through the code and felt heavy. If that's a major concern we can rename it.

Yams will match on properties by default (no need to create a custom matcher). To add properties to the cluster, you can use the YamsConfigBuilder.AddClusterProperty("Foo", "Bar") Api as shown in the tests. Only the properties that are added through YamsConfigBuilder will be used by the default matcher (other properties in the DeploymentConfig.json will be carried over but not used for matching). All properties can be used as token in the AppConfig.json (${propName}).

I also updated the sample and docs but not all of them. I'm hoping that Orleans guys (@jdom) will be able to help with the Orleans sample and cloud service sample.

Note that some of the Api changes are not backward compatible but should be easy to fix.

Finally, I extracted the DeploymentConfig serialization into its own interface so that it can be replaced. This means that you can now easily replace the json representation with whatever you prefer.

Let me know what you think!

[jdom]

LGTM

[jdom]

should you update these to MY_CLUSTER_ID?

[nehmebilal]

Yep thanks

[nehmebilal]

Done.

[jdom]

not sure for what purpose this relevant to override, but are you certain that 2 different sets with the same values will return the same hashcode? or is that not what you want anyway?

[nehmebilal]

I'll test this a bit more. I generated it the implementation with Resharper. I'd expect that two sets with the same values would have the same hashcode (GetHashCode is supposed to be consistent with Equals) but I'll make sure.

[veikkoeeva]

Possible could be also EqualityComparer<HashSet<AppDeploymentConfig>.Default.GetHashCode(_apps), I think.

[nehmebilal]

@jdom was right, the default implementation doesn't handle IEnumerable's correctly. I fixed the implementation and added corresponding tests.

[jdom]

there's a lot of references to 1.1.0-test, is that something that you want merged?

[nehmebilal]

No they should be replaced with the actual nuget version that will be published. I'll clean that up before merging, thanks.

[nehmebilal]

Replaced with 1.1.0-rc

[jdom]

might want to add coverage for using the new AddApplication overload that takes a deployment config with properties

[nehmebilal]

Good point!

[nehmebilal]

Tests added. Found some issues and ended up replacing the internal HashSet with a Dictionary which was more appropriate.

[nehmebilal]

@jdom Please confirm if your comments have been addressed and then I'll merge and publish a NuGet.

[jdom]

LGTM, ship it :P

[nehmebilal]

One last change. I made the cluster properties also available as tokens (properties added to the cluster at startup) and fixed a bug in resolving version tokens that was introduced by the switch to SemVersion (version.Patch should be used instead of version.Build).