[CentOS-devel] [RFC] ConfigMgmt SIG

[Julien Pivotto]

On Thu, Oct 01, 2015 at 07:44:18AM +0200, Fabian Arrotin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 30/09/15 18:53, Haïkel wrote:
> The ConfigMgmt SIG sounds like a good idea, surely for people involved
> in Infrastructure/sysadmin.
> Just one thing though : I see that the first target would be Puppet 4,
> and probably because it will not enter Epel 7. Does that sound about
> right ?
> The puppet 4 package[s]s would be "interesting" as it's a big bundle
> (and I don't understand their naming policy for those packages :
> strange NEVR schema : see https://yum.puppetlabs.com/el/7/PC1/x86_64/ )

I do not know if Puppet 4 will enter or not in EPEL, but certainly
the path upstream has chosen makes it difficult for the community to
have a clear overview of what is in that big package, how is it build
etc...

The opportunity I see there is to build Puppet packages where
we could run extensive tests against CentOS itself (extending the
t_functional tests for example).

> As said, I'd trust the Fedora packaging guidelines, so as Haïkel said,
> we'd probably have to see if that can be reused "as is", (the first
> puppet-4 SRPM I can see is the one that will be in Fedora 23 :
> https://dl.fedoraproject.org/pub/fedora/linux/development/23/source/SRPMS/p/puppet-4.2.1-2.fc23.src.rpm)

Indeed, we obviously want to avoid reinventing the wheel.

> But if the name of the SIG would be ConfigMgmt, the discussion would
> also be about guidelines for people using such packages. For example,
> as a sysadmin, I'd like to see puppet 3.x packages still there (what
> we use within centos infra right now), so different sub repositories
> to not force people to "jump" to newer version automatically when a
> SIG member decides to bump the build version ?

Yes. That is something that is important to me: providing access to the
latest Puppet 4 versions but still keeping the old work around, in
multiples repos.

> What are the other tools you have in mind ? If the SIG is about
> Configuration Management, some other tools like Chef, Ansible, Salt,
> cfengine (?) or others would be welcome too. And also tools around
> those, like Foreman.

My will is not to manage this SIG alone and I hope there are others
sysadmins who are using different tools (chef, ansible, saltstack, like
you said) who will join the race.

It would be fun to also have other 3rd parties tools joining the party
but to be realistic we should focus first of the configmgmt tools
themselves. I think a first achievement will be to see other SIG using
the work of this SIG in their daily tasks.

> As I see that you also ask for a "CentOS Board member to jump in",
> let's assume that I'm interested :-)

Nice to hear :)

> Next step would be to have a meeting (irc ?) when we can discuss a
> little bit about it, see/define the goals, and then depending on the
> results, I can propose a plan to the board during the next board meeting.

I will try to find a good spot for that meeting and then we will
announce it here.

-- 
 (o-    Julien Pivotto
 //\    Open-Source Consultant
 V_/_   Inuits - https://www.inuits.eu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 303 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20151001/e148e1d3/attachment.sig>