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-0008.sig>