[CentOS-devel] [RFC] ConfigMgmt SIG

[Fabian Arrotin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30/09/15 18:53, Haïkel wrote:
> 2015-09-29 15:09 GMT+02:00 Julien Pivotto
> <roidelapluie at inuits.eu>:
>> Hi all,
>> 
>> This is a request for comment about a new SIG for the CentOS
>> project. It is also a call for a Centos Board mentor to jump in.
>> 
>> The goal of this proposed SIG is to provide vendor-independent,
>> nicely written packages for automation tools.
>> 
>> Targeted automation tools include Puppet, Chef, Ansible... Some
>> of those tools come in a so-called all-in-one package, with
>> everything built-in in some vendor-defined dependencies. I do
>> think that an alternative for those packages should be possible.
>> It is good for the diversity of our ecosystems and would help
>> anyone who wants to fine control dependencies on those packages
>> or patch one particular dependencies to do so. It would also do
>> its best to re-use system dependencies as much as possible (e.g
>> openssl).
>> 
>> That SIG will probably be a source of interests for other SIG
>> that could use this work to deploy their work based on community
>> packages. It could optionally depend on some Softwares
>> Collections if needed.
>> 
>> My personal interest is to target Puppet 4 on ContOS 7, and that
>> would be the first objective, but this SIG is open to any
>> Open-Source Configuration Management tool.
>> 
>> 
> 
> (just commenting the paragraph above) Fedora Puppet4 package should
> build unchanged on CBS, if there are any changes required, patches
> are welcome. If it gets imported in CBS, I'd like to keep packaging
> consistent on all related platforms.
> 

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/ )

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)

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 ?

The idea adopted by the virt SIG for such packages is different
repositories : for example I see virt-7-xen-44 and virt-7-xen-46. Same
for virt7-ovirt-35 and virt7-ovrit-36.

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.

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

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.

- -- 
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlYMyDIACgkQnVkHo1a+xU5B9wCfYItYUD4OIETWMuuPG+PZBuQc
mRkAn02owGwajNUrDLyQwfZaH6n2J3J6
=ig0h
-----END PGP SIGNATURE-----