You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by David Nalley <da...@gnsa.us> on 2016/06/01 15:20:56 UTC

Re: Getting planetapache back

On Tue, May 31, 2016 at 12:18 PM, Jan Matèrne (jhm) <ap...@materne.de> wrote:
> Why Puppet? The Jenkins stuff is done via Ansible.
> Multiple automatisation tools?
>

The Jenkins stuff that was done in Ansible was done by a volunteer,
who chose to use Ansible because it was something he knew, even though
we had puppet deployed (though not very widely at the time). Having
config management is better than not, so we used it, and due to other
priorities and staffing issues, we still don't have the Buildbot or
Jenkins slaves completely puppetized, though our plan is to deprecate
Ansible once that is done. But for now, it serves a very useful
purpose - and it was a mountain of work that was completed and for
that segment of our machines it was tremendously useful.

As for why puppet - because when we were evaluating config management
systems more staff members knew that than any of the others - but not
by much. Since then, all of the staff members have picked it up - some
by just doing it, others by attending training, and it's worked pretty
consistently into our process. It's not necessarily the best CM tool,
but it's the one that seems to be working for us now.

--David

AW: Getting planetapache back

Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
> On Tue, May 31, 2016 at 12:18 PM, Jan Matèrne (jhm) <ap...@materne.de>
> wrote:
> > Why Puppet? The Jenkins stuff is done via Ansible.
> > Multiple automatisation tools?
> >
> 
> The Jenkins stuff that was done in Ansible was done by a volunteer, who
> chose to use Ansible because it was something he knew, even though we
> had puppet deployed (though not very widely at the time). Having config
> management is better than not, so we used it, and due to other
> priorities and staffing issues, we still don't have the Buildbot or
> Jenkins slaves completely puppetized, though our plan is to deprecate
> Ansible once that is done. But for now, it serves a very useful purpose
> - and it was a mountain of work that was completed and for that segment
> of our machines it was tremendously useful.
> 
> As for why puppet - because when we were evaluating config management
> systems more staff members knew that than any of the others - but not
> by much. Since then, all of the staff members have picked it up - some
> by just doing it, others by attending training, and it's worked pretty
> consistently into our process. It's not necessarily the best CM tool,
> but it's the one that seems to be working for us now.
> 
> --David

Thanks for that detailed explanation, David.
I thinking which tool I should learn next and understanding the ASF infra is one point on my agenda.

Jan