Hi,
In the Storage SIG we have several tools that depend on Ansible. What would be the best approach to make the Ansible packages available for users that want to install these tools?
For a concrete example, the gdeploy tool for Gluster can automate installation and configuration of Gluster and integrated projects (like Samba and NFS-Ganesha) through a simple configuration file. Internally gdeploy generates Ansible playbooks and can run them.
Lets assume we put gdeploy in a YUM repository from the Storage SIG. Because gdeploy depends on Ansible, we either need to:
a. tag/sign/push some Ansible package from the CBS in the Storage SIG b. add a dependency on centos-release-<ansible?> in the centos-release-gluster package (which c-r-ansible?) c. something else (please specify)
My preference would be to go with (b). I do not really want to care about the Ansible packages and their updates. It would be easier for me to have the SIG providing Ansible take care of that.
Thanks, Niels
On Thu, Jan 26, 2017 at 6:00 PM, Niels de Vos ndevos@redhat.com wrote:
Hi,
In the Storage SIG we have several tools that depend on Ansible. What would be the best approach to make the Ansible packages available for users that want to install these tools?
For a concrete example, the gdeploy tool for Gluster can automate installation and configuration of Gluster and integrated projects (like Samba and NFS-Ganesha) through a simple configuration file. Internally gdeploy generates Ansible playbooks and can run them.
Lets assume we put gdeploy in a YUM repository from the Storage SIG. Because gdeploy depends on Ansible, we either need to:
a. tag/sign/push some Ansible package from the CBS in the Storage SIG b. add a dependency on centos-release-<ansible?> in the centos-release-gluster package (which c-r-ansible?) c. something else (please specify)
My preference would be to go with (b). I do not really want to care about the Ansible packages and their updates. It would be easier for me to have the SIG providing Ansible take care of that.
That will be interesting for Virt SIG as well, since oVIrt 4.1 uses ansible as well for configuring metrics related stuff.
Thanks, Niels
I know the paas SIG is building ansible for their purposes, and the configmanagement SIG was meant to pick up and maintain a version of ansible.
I'm forgetting what we're blocked on for this?
On Jan 26 18:17, Sandro Bonazzola wrote:
On Thu, Jan 26, 2017 at 6:00 PM, Niels de Vos ndevos@redhat.com wrote:
Hi,
In the Storage SIG we have several tools that depend on Ansible. What would be the best approach to make the Ansible packages available for users that want to install these tools?
For a concrete example, the gdeploy tool for Gluster can automate installation and configuration of Gluster and integrated projects (like Samba and NFS-Ganesha) through a simple configuration file. Internally gdeploy generates Ansible playbooks and can run them.
Lets assume we put gdeploy in a YUM repository from the Storage SIG. Because gdeploy depends on Ansible, we either need to:
a. tag/sign/push some Ansible package from the CBS in the Storage SIG b. add a dependency on centos-release-<ansible?> in the centos-release-gluster package (which c-r-ansible?) c. something else (please specify)
My preference would be to go with (b). I do not really want to care about the Ansible packages and their updates. It would be easier for me to have the SIG providing Ansible take care of that.
That will be interesting for Virt SIG as well, since oVIrt 4.1 uses ansible as well for configuring metrics related stuff.
Thanks, Niels
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Jan 27, 2017 at 02:23:20AM -0600, Brian Stinson wrote:
I know the paas SIG is building ansible for their purposes, and the configmanagement SIG was meant to pick up and maintain a version of ansible.
I'm forgetting what we're blocked on for this?
opstools SIG uses ansible to deploy the server side of operational tools.
Until now, we relied on Fedora and ansible installed on the machine running the deployment.
Matthias
-
Brian Stinson -
Matthias Runge -
Niels de Vos -
Sandro Bonazzola