I'm not sure how this applies to my reservations. The query/check/update and representations to the user about state are a separate matter entirely from configuration. When we want to know if a VM is running, obviously the host running the VM is the canonical source (this is about state, not configuration). If we want to get a list of network ids, then cloudstack must certainly be the canonical source (this is about configuration, not about state). If we want to know what secondary storage we have, then cloudstack is canonical. There is no concept in cloudstack of 'query and update myself about which secondary storage devices the hosts know about'.
By making this change, we take the configuration items that exist in agent.properties out of the control of what is considered the canonical configuration source (the cloudstack database) for everything else. There is now no single correct configuration for these items; this would allow for interesting things like being able to set a different public network device on every host (maybe public.network.device is correctly set to cloudbr0 on host1 and cloudbr3 on another host), but goes against the methodologies of the rest of the infrastructure. I'm not an architect of cloudstack, so that's fine by me, I'm just asking that if that is done then there are changes made as well to ensure that cloudstack stops pretending to be a configuration source for these items. I do think that the idea that "agent.properties holds configuration items, and thus the daemon shouldn't change it" is flawed. There are plenty of scenarios where programs hold their own information in a file that's not meant to be edited by the admin. Usually they have headers that say things like "don't edit this file" (such as /etc/sysconfig/iptables). The idea is that if you need to make changes, you do it in the correct location. On Mon, Aug 13, 2012 at 9:50 AM, Matthew Patton <mpat...@inforelay.com> wrote: >> this bug fix is implemented, then cloudstack is no longer the >> canonical source of configuration, > > Which is how it should be. It is a fatal conceit to think CS knows anything > in an absolute manner. It must always query, always check and update itself. > Any representation made to the user is at best a last known state depiction. > "trust but verify" at every step of the way. Thus includes storage, network, > guest and host actions. > > You can not shortcut this and get away with it. >
