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.
About me:
I am a sysadmin using CentOS daily. I operate on several infrastructures of different scales mixing several automation/orchestration tools. I come from Belgium and I have been involved as a speaker at previous CentOS DOJO's in Brussels and Paris.
On Tue, Sep 29, 2015 at 03:09:49PM +0200, Julien Pivotto wrote:
Hi all,
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
Errata: vendor-defined directories
2015-09-29 15:09 GMT+02:00 Julien Pivotto roidelapluie@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.
About me:
I am a sysadmin using CentOS daily. I operate on several infrastructures of different scales mixing several automation/orchestration tools. I come from Belgium and I have been involved as a speaker at previous CentOS DOJO's in Brussels and Paris.
-- (o- Julien Pivotto //\ Open-Source Consultant V_/_ Inuits - https://www.inuits.eu
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-----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@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/...)
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
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/...)
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.
-
Fabian Arrotin -
Haïkel -
Julien Pivotto