On 08/13/2012 06:46 AM, Chiradeep Vittal wrote:
On 8/8/12 11:03 AM, "Wido den Hollander" <w...@widodh.nl> wrote:
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
Good suggestions. I suspect that some "discovered" and auto-generated
stuff is cached in this file and should be moved to its own file?
Is there a bug id?
Shame on me, I keep forgetting creating bugs!
Just created: http://bugs.cloudstack.org/browse/CS-15969
I already did a couple of commits regarding this:
https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git&a=search&h=HEAD&st=commit&s=agent%3A
I'm currently working on cloud-setup-agent and the documentation so that
this gets fixed for the 4.0 release.
Wido
Chiradeep
