> On Mon, Aug 13, 2012 at 12:59 PM, Marcus Sorensen <shadow...@gmail.com> > wrote:
>> 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'. Fair enough. But it damn well better NOT remove anything. Rewriting agent.config leads to just this problem. A sysadmin is well within his rights to have guests, mount points, and bridges on Hosts that CS knows nothing about. It's one thing to deploy a configuration to a virgin box and in doing so completely rejigger networking, storage, etc. But if a Host has a populated agentproperties it better not change anything without explicit approval. It's perfectly fair for the 'Add Host' operation to fail and in so doing provide the admin a simple means to diff against what it found vs what it wanted to push. The guest deployment logic likewise needs to take into consideration that not every Host will have the same set of storage or network resources by design or by accident. Only with explicit admin permission should CS "remedy" any non-compliance items, but frankly I wouldn't trust CS to do it correctly. >> 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). EXACTLY. It is beyond naive for CS to assume every host even within a cluster are all configured the same. > 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. absolutely.
