[Proposal] Support defining Silo metadata

[cecilphillip]

Overview

I'd like to propose the ability for developers to attach additional metadata attributes to their silo definitions.

Use cases

Enabling this feature would open up the ability to better categorize, inspect, and filter out silo instances. Similar capabilities exist in other frameworks such as AkkaDotNet . This would be particularly useful when creating custom placement strategies.

Possible workaround

Today, the SiloOptions only has a single property,SiloName. Also it is possible to create a non standard naming structure to embed metadata into silo, this is a bit of a hack.

// structure => "siloName.siloRole.SiloCategory"
 opts.SiloName = "MySilo.workflo.blue";

Possible API changes

• Add Metadata property to SiloOptions
• Expose Metadata on SiloAddress

     builder.Host.UseOrleans((context, siloBuilder) =>
        {
            siloBuilder
                .Configure<SiloOptions>(opts =>
                {
                    opts.SiloName = "MySilo";
                    opts.Metadata = new Dictionary<string, string>()
                    {
                        ["category"] = "blue",
                        ["custom.data"] = "My Custom Value",
                        [Constants.DefaultRolesNameKey] = "role1, role2, role3"
                    };
                })
  });

Conditions

• Silo metadata should be immutable. Once the silo has started, the properties cannot be changed
• Silo metadata should be added to the Membership table records

[Romanx]

I have a use-case for this in that we may want to place a specific grain only on Silos that have certain metadata as mentioned by @cecilphillip in our case it could be based on the hardware that the silo is on for example.

[SebastianStehle]

I would have a look if it can be implemented without changing the membership implementation. Perhaps with some grains. Would make it easier to implement it as small improvement.

[Romanx]

We actually do store this silo metadata in a grain. The grain itself is keyed by the silo address and we created a placement strategy that places the grain on the silo that matches.

The further placement strategy that requires the silo metadata reads the information from the silo metadata grain and caches it to avoid chatty lookups on placement. It works fine at the moment for our use-case but something more in-box would be great.

[rkargMsft]

PR #9271 is up that would address this Issue. Any feedback would be welcomed.