On 08/08/2012 05:59 PM, Marcus Sorensen wrote:
What's the process exactly when the management server adds a host?
Does it ssh in run cloud-setup-agent, then start the agent? Is it
viable to manage agent.properties on your own when it really needs to
be in sync with what the management server (and cloud) knows about?
For example you can't just change the traffic labels on the host and
in its agent.properties and expect things to work, the manager is
still going to want the originals.
If you provide the Agent a correct agent.properties you don't need to
run cloud-setup-agent.
The management server indeed logs in via SSH and executes
cloud-setup-agent on that host.
I think you actually can change the traffic labels on the Agent, it
looks up private.network.device, public and guest and uses those values.
I however don't know how this goes with migrations, I guess not to
well.. I wouldn't recommend it.
Wido
On Wed, Aug 8, 2012 at 9:46 AM, John Kinsella <j...@stratosec.co> wrote:
+1 the daemon overwriting the file got me a few times, as well…
On Aug 8, 2012, at 6:33 AM, Wido den Hollander wrote:
Hi,
I was looking into the Agent setup and configuration today and found out that
this is quit outdated.
All the documentation is still pointing to the cloud-setup-agent tool, but do
we still want that?
On my systems this tool seems to brake more then you want.
I'm working on fixing most of the bugs, but setting up the agent isn't that
hard at all.
1. Make sure your interfaces match you traffic labels
2. Fill the agent.properties (guid, resource host, private nic, public nic)
3. Start the agent
There is however one thing I don't like. The agent is overwriting it's
agent.properties file with various own lines, mangling anything you might have
written to it.
Admins might deploy their agents with Puppet or Chef and those tools usually go
crazy when files change without them noticing it.
Do we really need to write to this file? Shouldn't the agent just start and
whenever some property is not set use a default value?
The agent for example generates a UUID for local storage and stores it in
agent.properties. Should it? Shouldn't it simply complain if that value is not
set and let this value be set by cloud-setup-agent or by the admin manually?
I personally don't like daemons who start touching my configuration and
modifying files without me knowing it.
To sum it up:
I think setting up an agent should be able by just providing a agent.properties
and nothing more. Start the agent and go online.
No need for the cloud-setup-agent tool imho. This is a black magic box which
does all kinds of things which should actually be documented.
Wido
Stratosec - Secure Infrastructure as a Service
o: 415.315.9385
@johnlkinsella