ansible and cobbler

[Andreas Davour]

I am suspecting that more people than us are using both cobbler and ansible. Right now we are kind of in the process of merging more and more of our old procedures into cobbler, which leaves the question of where ansible fit it.

I guess you could do it in multiple ways, but I'd be glad to hear how someone else have drawn the line.

Right now we put lots of config files in HERE documents by "snippets" in cobbler, but I'm thinking if they might better be handled by ansible and the templating system.

Any impressions or reactions?

/andreas

[Jérémie Tarot]

Hi,

2012/7/24 Andreas Davour <andreas...@snowmen.se>:

I'm at the very beginning of a multi-tenant infrastructure automation
project. I have to admit that I never liked here docs because they
always appeared as a mix of logic and content, which should be avoided
for many reasons. One good answer to this problem is templating.

My current PoV about where to draw the line between provisioning and
configuration management is that provisioning should go no further
than the point where the system is bootable and manageable by the
configuration management system (this may require integration in AAA
system). With Ansible, this just requires a pair of python modules and
OpenSSH, which are installed anyway, so this is a very bare OS
install.
At this stage (system booted and accessible via SSH), configuration
management takes over to apply the classes/groups/playbooks needed for
the node to provide the service it is aimed at.

Hope it helps
Bests

--
Jérémie Tarot
http://about.me/silopolis

[Andreas Davour]

At Fri, 27 Jul 2012 10:45:42 +0200,

Jérémie Tarot wrote:
>
>
> I'm at the very beginning of a multi-tenant infrastructure automation
> project. I have to admit that I never liked here docs because they
> always appeared as a mix of logic and content, which should be avoided
> for many reasons. One good answer to this problem is templating.

I agree.

> My current PoV about where to draw the line between provisioning and
> configuration management is that provisioning should go no further
> than the point where the system is bootable and manageable by the
> configuration management system (this may require integration in AAA
> system). With Ansible, this just requires a pair of python modules
> and OpenSSH, which are installed anyway, so this is a very bare OS
> install. At this stage (system booted and accessible via SSH),
> configuration management takes over to apply the
> classes/groups/playbooks needed for the node to provide the service
> it is aimed at.

Thanks for your feedback!

Anyone else having something to say on the matter which feels this is not the forum for it, feel free to email me.

/andreas

[Michael DeHaan]

>
> My current PoV about where to draw the line between provisioning and
> configuration management is that provisioning should go no further
> than the point where the system is bootable and manageable by the
> configuration management system (this may require integration in AAA
> system). With Ansible, this just requires a pair of python modules and
> OpenSSH, which are installed anyway, so this is a very bare OS
> install.

Definitely -- Deploying a minimal generic system in kickstart is the way to go regardless of what configuration system you use.
I do like to try to run the configuration tool in %post or at first boot time if possible though.

James Cammarata at one point was quite interested in improving Ansible support in Cobbler, I would assume with a better external inventory script than the one I wrote and a few basic snippets. This might be worth bringing up on Cobbler's list too. (I'll leave that for others to do though).

The most logical thing to me, I think, is if you wanted to set up Ansible-pull. (IF). This gives you a way to make sure things are fully configured immediately post kickstart. This could be done in %post. If you did not, you'd have to make it a two stage deploy, which is where scripts like Seth's provisioning script that uses virt-install would come into play.

The other thing in Cobbler that is really useful is the keep_ssh_host_keys snippet, especially if using the SSH connection type (because paramiko is a bit less picky about changing keys). This snippet removes nearly ALL of the SSH reprovisioning pain people talk about -- and is really a pretty neat trick. For the uninitiated, what it does is preserve the host's SSH keys in a /tmp partition while you are reinstalling via kickstarts, so Anaconda doesn't blow them away.

[Dag Wieers]

> 2012/7/24 Andreas Davour <andreas...@snowmen.se>:
>
> I am suspecting that more people than us are using both cobbler and ansible. Right now we are
> kind of in the process of merging more and more of our old procedures into cobbler, which
> leaves the question of where ansible fit it.
>
> I guess you could do it in multiple ways, but I'd be glad to hear how someone else have drawn
> the line.
>
> Right now we put lots of config files in HERE documents by "snippets" in cobbler, but I'm
> thinking if they might better be handled by ansible and the templating system.
>
> Any impressions or reactions?

We decided not to use cobbler, as we use an inventory script (yaml) which
we plan to connect directly to a corporate CMDB at some point.

The provisioning is done using a simple kickstart and mrepo (synchronizing
with RHN). The kickstart file has a very brief post-install that keeps
sshd running in the chrooted system to complete the configuration
management with Ansible.

I plan to automate the provisioning using kickstart as well, but given we
need iLO, VMware and KVM support this is not something we are looking at
right away. However I would still like to have something that waits until
the post-installation has kicked in to continue the configuration
management phase.

Due to strict security requirements we are not looking into ansible-pull.
Systems often are isolated and cannot initiate communication other than
what is strictly necessary (and configuration management is not considered
a strict requirement, and definitely not something that should require
permanent access).

Given some of these requirements we build similar solutions for different
customers based on common principles.

--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, in...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

[Jérémie Tarot]

Hi,

2012/7/27 Michael DeHaan <michael...@gmail.com>:

>
> James Cammarata at one point was quite interested in improving Ansible support in Cobbler,
>

That would be nice...

> The most logical thing to me, I think, is if you wanted to set up Ansible-pull. (IF).
> This gives you a way to make sure things are fully configured immediately post
> kickstart. This could be done in %post.
>

Will test this in my preseed/late_command...

> If you did not, you'd have to make it a two stage deploy, which is where scripts like
> Seth's provisioning script that uses virt-install would come into play.
>

Any pointer for this ? I'd love to study it !

[Jérémie Tarot]

2012/7/30 Jérémie Tarot <silo...@gmail.com>:
> 2012/7/27 Michael DeHaan <michael...@gmail.com>:

>>
>> If you did not, you'd have to make it a two stage deploy, which is where scripts like
>> Seth's provisioning script that uses virt-install would come into play.
>>
> Any pointer for this ? I'd love to study it !
>

'k,got got it, sorry for the noise