I think another point for consideration is the Puppet+Foreman support, foreman doesn't support puppet 4 yet[1], but f23 runs only with puppet >4 agents, if that doesn't get fixed soon and we can't upgrade puppet to 4, we will hit a big problem when we need to migrate more slaves to f23.
[1] http://projects.theforeman.org/issues/8447 On Sun, Apr 3, 2016 at 10:42 AM, Barak Korren <[email protected]> wrote: > On 3 April 2016 at 10:21, Eyal Edri <[email protected]> wrote: > > I'd like to ask the team what do you think on $subject, in terms of pros > & > > cons. > > > > As you all know we have been using puppet to manage our production infra > > (user access, server configuration,etc... ). > > > > Recently we started looking into migrating our mailman instance into new > > hyper-kitty instance to run on the oVirt DC in PHX. > > It seems that there is no true puppet classes available to install/manage > > mailman3 but there is an Ansible playbook used / written by fedora to > deploy > > their instance. > > So the question is should we start using/supporting Ansible as another > tool > > to manage our infra and leverage existing playbooks out there to reduce > work > > on migration of new services? > > I'm not suggesting to migrate all puppet code into Ansible, but to allow > > using Ansible when it make sense. > > > > Here is what I had in mind with regards to pro/cons: > > Pros > > > > Saving time writing puppet classes for services (if Ansible playbook > exists) > > Bringing in new infra members which are interested in Ansbile (maybe > publish > > the team in the relevant communities) > > > > > > Cons: > > > > Another tool to support/maintain > > No real support to manage in foreman as we do for puppet (for sure not in > > our old version) > > > > > > > > I'd love to hear your thoughts about it. > > > > As I've already stated elsewhere Ansible is interesting for a number > of reasons, but a dual-tool scenario will not be welcome IMO. > > There is also a lage question of the possibility of replacing Puppet > with Ansible. Puppet is a continues configuration-management system > that monitors servers for configuration drift and repairs it > (deploying missing components in the process), to do that it supports > a declarative language and a master/slave-agent architecture. > The common Ansible usage scenario OTOH seems to be AFAIK a > developer/op launching a deployment task from his laptop. For that > Ansible supports a more imperative syntax and an SSH-based agent-less > architecture. > > IMO, for long-running on-premise infrastructure (Not ad-hoc in "the > cloud") which is what oVirt has and what what it targets, the drift > monitoring approach is more suitable. > > Now, I've hared that that Ansible could also be deployed with agents > and a central server (Tower? Foreman? something else?), but I'm not > sure how mature that deployment scenario is right now, nor wither > existing Ansible code fits that scenario. > > > -- > Barak Korren > [email protected] > RHEV-CI Team > _______________________________________________ > Infra mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/infra >
_______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
