On Mon, Aug 13, 2012 at 12:59 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > 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. >
So in the case of iptables those are merely 'advisory' because of the consequences of bad syntax, and no daemon changes them. sudoers has the same 'warning' but it's not because sudoers has a daemon changing it. They do have a special syntax checking application. I assure you all of those config files (sudoers and iptables) are editable in a text editor. The only program I can think of that behaves that way is fail2ban, and many argue with the design principle behind that I am sure there are other examples though. CloudStack isn't a config management system, nor does it have ESP with which to interpret the admins intentions. The management server should reject anything that doesn't conform from a configuration standpoint, and not try and change it, IMO. --David
