Environ config changes: to lock or not to lock?
Jeroen Vermeulen
jeroen.vermeulen at canonical.com
Mon Jun 24 09:47:11 UTC 2013
Hi all,
The provider implementations contain mutexes that protect attributes
against concurrent config changes. But I still feel a little unsure
about exactly what we can assume, and I was hoping you could give me
some pointers to answers, or hints that we can turn into documentation:
Do we want consistent images of an environ and its config, so that a
provider operation concurrent with a config change doesn't get a view
that's nonsensical in some way? Or are the locks just there to prevent
undefined behaviour at the language level?
We're mostly looking at the ec2 provider as an example, but it's hard to
get this stuff right by imitation: why is it safe for providers to set
environ.name, when read access to that attribute is not lock-protected?
When we release an environment's lock between reading multiple
attributes, is there a risk of reconfiguration happening inbetween, and
do we mind? It'd be great to have the reasons explicit in the code.
Jeroen
More information about the Juju-dev
mailing list