Currently, @globally_unique_key sets a single attribute on the target to record the globally unique key. __initial_injections__ and I think even namespace.to_inject support the concept of multiple globally unique keys. But as mentioned, the decorator does not and thus to a large extent the container propagation code does not.
There are a number of use cases for multiple globally unique keys.
The one that was on my mind now is being able to do something like set up machine tags--to for example say that we want to tag all the machines involved in bootstrap before we set up an in-range mirror.
So we might set those machines up, get the mirror going, and then flag those machines with info about the in-range mirror before starting the rest.
Currently,
@globally_unique_key
sets a single attribute on the target to record the globally unique key. __initial_injections__ and I think even namespace.to_inject support the concept of multiple globally unique keys. But as mentioned, the decorator does not and thus to a large extent the container propagation code does not.There are a number of use cases for multiple globally unique keys. The one that was on my mind now is being able to do something like set up machine tags--to for example say that we want to tag all the machines involved in bootstrap before we set up an in-range mirror. So we might set those machines up, get the mirror going, and then flag those machines with info about the in-range mirror before starting the rest.