Few questions about automateit

[darkweaver87]

Hi to all,

I'm currently testing configuration management softwares in order to
install it on great scale environnement (a lot of load-balanced web
servers, NAS, DB ...) .

I've already tested Puppet, Foreman but it's not flexible enough for
my purpose.

I'm a newbie in AutomateIt and I have some troubles for using it.
I'm using the version 0.80624 on a Debian Lenny.

So, here are my questions:
- is it possible to declare some kind of variables for one host ?
For instance:
web01: addresses { "bond0": ip => 10.x.x.x, netmask => 255.0.0.0;
"bond0:1" : ip => 10.x.x.x, netmask =>
255.0.0.0;}

- is there a daemon or have I to rsync project directory and then the
command (for instance run rake install) ?
- is there a dependency graph as puppet does or tasks are ran in
"invoke" order ?

Thanks for your answers.

[Igal Koshevoy]

darkweaver87 wrote:
> So, here are my questions:
> - is it possible to declare some kind of variables for one host ?
> For instance:
> web01: addresses { "bond0": ip => 10.x.x.x, netmask => 255.0.0.0;
> "bond0:1" : ip => 10.x.x.x, netmask =>
> 255.0.0.0;}
>

AutomateIt is pretty flexible about how you choose to do this, but I
would probably add these to the fields.yml file. Here are two ways to do
this:

# Organize field data by category, e.g., "networking" and "database":
networking:
web01:
bond0:
ip: 10.x.x.x
netmask: 255.0.0.0
bond1:
...
web02:
...
database:
web01:
...

# ...Or organize field data by host, e.g., "web01" has all its
# related data in one place:
hosts:
web01:
networking:
bond0:
ip: 10.x.x.x
netmask: 255.0.0.0
bond1:
...
database:
...
web02:

> - is there a daemon or have I to rsync project directory and then the
> command (for instance run rake install) ?

There's no AutomateIt daemon, the recipes are plain text files and a
machine can execute them if it can read them -- so you can use rsync,
nfs, git or whatever to share recipes between machines. In practice,
this is quite easy to setup. Please see this thread for further details:
http://groups.google.com/group/automateit/msg/2d93957c5ba8cd42?

> - is there a dependency graph as puppet does or tasks are ran in
> "invoke" order ?

AutomateIt executes code from top-to-bottom like bash, Ruby, Perl, PHP
or other imperative programming languages. There's no dependency graph,
which was a deliberate design decision because I find that top-to-bottom
execution makes the resulting recipes easier to read, write and live
with compared to graph-based systems.

-igal

[Tim Uckun]

>> - is there a dependency graph as puppet does or tasks are ran in
>> "invoke" order ?
> AutomateIt executes code from top-to-bottom like bash, Ruby, Perl, PHP
> or other imperative programming languages. There's no dependency graph,
> which was a deliberate design decision because I find that top-to-bottom
> execution makes the resulting recipes easier to read, write and live
> with compared to graph-based systems.
>

I was thinking of doing something like this.

def invoke_once (tag)
unless @invoked_tags.include? tag
@invoked_tags <<tag
invoke tag
end
end

This would allow you to willy nilly add "invoke_once" into your
recipes to declare dependencies but they will only run once.

If you think you need that kind of functionality you may give it a shot.

as for per host variables another approach you could take is to create
a recipe called "your_host_name" and run a "invoke socket.gethostname"
if File.exists(Socket.gethostname)

In that file you can put all your host specific stuff. It's the same
thing as "if tagged? hostname" but just a different approach.

[Igal Koshevoy]

Tim Uckun wrote:
>>> - is there a dependency graph as puppet does or tasks are ran in
>>> "invoke" order ?
>>>
>> AutomateIt executes code from top-to-bottom like bash, Ruby, Perl, PHP
>> or other imperative programming languages. There's no dependency graph,
>> which was a deliberate design decision because I find that top-to-bottom
>> execution makes the resulting recipes easier to read, write and live
>> with compared to graph-based systems.
>>
>>
>
>
> I was thinking of doing something like this.
>
> def invoke_once (tag)
> unless @invoked_tags.include? tag
> @invoked_tags <<tag
> invoke tag
> end
> end
>
> This would allow you to willy nilly add "invoke_once" into your
> recipes to declare dependencies but they will only run once.
>
> If you think you need that kind of functionality you may give it a shot.
>

Sure, that'd work. It may, however be more straightforward to create
library functions that can be called many times, but keep track of state
and only execute expensive logic once.

For example, something that sets up Apache sites...

# In lib/setup_apache_site.rb
def setup_apache_site(hostname, ...)
if tagged? :setup_apache_prepared
# TODO Install Apache in general here
tags << :setup_apache_prepared
end
# TODO Setup an individual Apache site here
end

# In your recipes
## First time called, this will install Apache in general AND "foo.com":
setup_apache_site("foo.com", ...)
## Subsequent calls, this will only install the site, like "bar.com":
setup_apache_site("bar.com", ...)

Anyway, I've avoided having to do this mostly by splitting my recipes
up. For example, I have one recipe setup a generic Apache configuration,
and then later recipes that configure each website.

-igal

[darkweaver87]

Thank you to both.

With the example given on the web site I was not expecting such
flexibility on fields.yml. I was thinking it was just a file to define
some/only general constants which can be applied to all nodes.
So, I think I will use your solution.

Rémi

[darkweaver87]

Hi,

Does package manager provide a way to answer to installer questions ?
I didn't find this in documentation.

Thanks in advance.

[Igal Koshevoy]

darkweaver87 wrote:
> Does package manager provide a way to answer to installer questions ?
> I didn't find this in documentation.

The `package_manager.install` asks the package manager to perform a
standard unattended install. If a particular package's author has
deliberately decided to make standard unattended installation
impossible, they're doing it wrong and AutomateIt won't be able to guess
what to do.

When you encounter naughty installers, you need to figure out how they
work and script them directly -- like by running AutomateIt "sh"
commands that feed the installer arguments, flags, environmental
variables, or even execute Expect wrappers to deal with troublesome
interaction.

If you have a particular package you're running into problems with,
mention it and maybe someone has already figured out what to do about it.

-igal

[darkweaver87]

OK. No problem with any package.

Just let's take the following example.
I'm installing nagios-nrpe-server : package_manager.install("nagios-
nrpe-server").
When installing the samba-common dependency it asks me for entering a
WORKGROUP name.

I would like to set it to "foo".

If I understand correctly what you mean I have to edit configuration
file and replace with the value I want or to run a command like the
following before the package installation:
echo "samba-common samba-common/workgroup string foo" | debconf-
set-selections

Is there anyway to intergrate it to integrate it in
package_manager.install as a kind of "preseed file" parameter (e.g.
http://reductivelabs.com/trac/puppet/wiki/TypeReference#responsefile)
?

Rémi