Supporting Ansible as another tool for ovirt infra mgmt

[Eyal Edri]

OK,

So if we agree Ansible can't replace Puppet or live side by side Puppet as
CM tool for oVirt services,
We can still leverage existing Ansible playbook to deploy a service (like
mailman3) single time and then when its deployed with all the relevant
basic configuration,
It might be easier to prepare Puppet manifests for it, using existing conf
we have to adapting it as needed.



On Sun, Apr 3, 2016 at 11:59 AM, Anton Marchukov <amarchuk at redhat.com>
wrote:

> Hello All.
>
> I did not follow the recent Ansible developments, but at the time when I
> researched it looked like a fancy SSH playbook library (a "better" fabric)
> rather than "configuration management" system. This is not always bad
> depending on what we want.
>
> 1. The strongest benefit of the Ansible is that it is easy to start using
> it for anybody knowing Python, same way as fabric it is essentially SSH
> client with imperative Python code that sequentially execute the actions.
> They claim the concept of idempotence, but it is not desired state system
> like Puppet, so instead of declaring a desired state and letting the
> computer do the magic, you just list the steps to execute it imperatively
> and if done right several runs won't break anything due to idempotence.
>
> 2. Also it is push approach and uses SSH so unless we want to execute it
> from personal laptops as with fabric we will have to have a central server
> with root SSH access to all our Ansible-managed servers where we can
> execute it. There were orchestration tools such as Tower, but they were not
> open source and looks like are not open source yet. Maybe there is
> something other I am not aware about, please let me know.
>
> Given those two items I really not sure we can use Puppet and Ansible
> systems together as  configuration management tools. The only ways to use
> them together that I see are:
>
> 1. Use Ansible as a fabric replacement - to run things ad hoc (e.g.
> running yum upgrade openssl) This does not work for mailman3 as it will be
> "unpuppetized" in our terms.
> 2. Use Ansible only on part of the hosts. This works for mailman3, but for
> us those host will leave as "unpuppetized" again plus we have to come up
> with infra to support those hosts deployment due to luck of foreman
> support. In addition we have to develop a way to transfer our users (puppet
> classes + hiera now) to those servers that complicates deployment even more.
>
> However it is not all or nothing problem, so the short term solution I
> would propose and  agree with:
>
> It is ok to use Ansible for a limited set of hosts because it is easier
> for people to learn and use it and hence - contribute deployment
> instructions to us. But I would treat those hosts as "unpuppetized" on our
> side. The motivation for that is that well, we do have a bunch of
> unpuppetized hosts and obviously puppetizing everything is not a one day
> effort deal. Myabe it should not block PHX migration. If somebody wants to
> use Ansible instead of manually configuring hosts over SSH it is great. The
> host is still unpuppetzied, but same way we have deployment instructions as
> a playbook in SCM. And to get our users on the host we can use foreman +
> puppet infra classes the same way we do for manually installed servers. So
> the requirement for PHX migration than will be relaxed: deployment should
> be reproducible + the host should support our infra tools such as foreman
> and user classes.
>
> Anton.
>
>
> --
> Anton Marchukov
> Senior Software Engineer - RHEV CI - Red Hat
>
>


-- 
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160403/1154b5a3/attachment.html>