More detail in that document would be much appreciated. To answer your questions:

1. The default placement strategy is Random
2. The default placement strategy for all grains (i.e, which have not otherwise specified it) is configured by registering an implementation of PlacementStrategy in the DI container. (this could be nicer - options or an extension method would be better):

siloBuilder.ConfigureServices(services =>
  services.AddSingleton<PlacementStrategy, MyPlacementStrategy>());

3. Here are the included strategies:

All strategies select a silo from the set of compatible silos. The set of compatible silos is the set of all silos which have an implementation for the grain and where that implementation's interface version is compatible with the caller's interface version. For more information, see the grain versioning documentation.

RandomPlacement

A silo is randomly selected from the set of compatible silos.

PreferLocalPlacement

If the local silo is compatible, select the local silo, otherwise select a random silo.

HashBasedPlacement

Hash the grain id to a non-negative integer and modulo it with the number of compatible silos. Select the corresponding silo from list of compatible silos ordered by silo address. Note that this is not guaranteed to remain stable as the cluster membership changes. Specifically, adding, removing, or restarting silos can alter the silo selected for a given grain id. Because grains placed using this strategy are registered in the grain directory, this change in placement decision as membership changes typically does not have a noticeable effect.

ActivationCountPlacement

The intention of this placement strategy is to place new grain activations on the least heavily loaded silo. The implementation of this director is not simple enough to explain briefly, however. It includes a mechanism in which all silos periodically publish their total activation count to all other silos. The placement director then selects a silo which is predicted to have the fewest activations by examining the most recently reported activation count and a making prediction of the current activation count based upon the recent activation count made by the placement director on the current silo.

The general advice is to not use this placement director without careful testing and analysis. (@sergeybykov, should we submit a PR to remove it?)

If you do remove ActivationCountPlacement, could I suggest it is moved to Samples rather than deleted, as it might be a useful reference for others writing custom strategies?

In my opinion, ActivationCountPlacement is dangerous in its current form. It can be improved by making it operate based on smoothed out statistics, so that it wouldn't overreact to delayed stats.

So let's avoid documenting ActivationCountPlacement for now?

Also, can anyone confirm whether the sample in the existing document is still up to date? Specifically with regard to the strategy and director registration.

I think it's okay to document ActivationCountPlacement, so long as there's a caveat that it acts on lagging data and can overreact is a highly dynamic scenario.

The sample code looks correct for 2.x and 3.x.

We are heavily relying on ActivationCountPlacement. Please don't remove it. We understand all consequences and are using it at our own risk 😃

We should publish a Liability Waiver form that one would have to sign before using ActivationCountPlacement. 🙂