incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: KVM Agent setup/configuration
Date Mon, 13 Aug 2012 16:59:25 GMT
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 <mpatton@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.
>

Mime
View raw message