Hi guys,
we would like to chat abu the different possibilities of SCL Prefixes:
/opt/centos /opt/centos-sig-configmgt /opt/centos/sig-configmgt /opt/centos/sig-configmgt-hiera44 /opt/centos-sig-configmgt/hiera44 /opt/centos/sig-configmgt/hiera44
What is your opinion about this?
My preference would go to /opt/centos/sig-configmgt-ruby22.
Please remember that ze do not plan to expose that to users (e.g puppet will be installed in /usr, not in a SCL). However, those SCL will be used for dependencies and/or rebuilds of EPEL packages.
On Thu, May 12, 2016 at 5:37 AM, Julien Pivotto roidelapluie@inuits.eu wrote:
Please remember that ze do not plan to expose that to users (e.g puppet will be installed in /usr, not in a SCL). However, those SCL will be used for dependencies and/or rebuilds of EPEL packages.
The big headline on softwarecollections.org is:
All versions of any software on your system. Together.
That is how I have always understood it. So how would installing to /usr fit the SCL paradigm? Or has the SCL paradigm changed?
On 12 May 11:04, BC wrote:
On Thu, May 12, 2016 at 5:37 AM, Julien Pivotto roidelapluie@inuits.eu wrote:
Please remember that ze do not plan to expose that to users (e.g puppet will be installed in /usr, not in a SCL). However, those SCL will be used for dependencies and/or rebuilds of EPEL packages.
The big headline on softwarecollections.org is:
All versions of any software on your system. Together.
That is how I have always understood it. So how would installing to /usr fit the SCL paradigm? Or has the SCL paradigm changed?
We are not the SCL sig. We do not plan to let you install multiple versions of Puppet at the same time on your system.
Maybe a better way to rephrase it is:
which prefix will we use for our dependencies that are not packagable in the system?
On Thu, 2016-05-12 at 20:24 +0200, Julien Pivotto wrote:
On 12 May 11:04, BC wrote:
On Thu, May 12, 2016 at 5:37 AM, Julien Pivotto <roidelapluie@inuit s.eu> wrote:
Please remember that ze do not plan to expose that to users (e.g puppet will be installed in /usr, not in a SCL). However, those SCL will be used for dependencies and/or rebuilds of EPEL packages.
The big headline on softwarecollections.org is:
All versions of any software on your system. Together.
That is how I have always understood it. So how would installing to /usr fit the SCL paradigm? Or has the SCL paradigm changed?
We are not the SCL sig. We do not plan to let you install multiple versions of Puppet at the same time on your system.
Hi,
Why not have multiple versions of puppet, it seems like a good idea.
But even with just one I would also put everything in the software collection and just avoid the system, apart from anything else it will clash with the epel pkgs and what not.
Maybe a better way to rephrase it is:
which prefix will we use for our dependencies that are not packagable in the system?
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 13 May 11:03, Steve Traylen wrote:
On Thu, 2016-05-12 at 20:24 +0200, Julien Pivotto wrote:
On 12 May 11:04, BC wrote:
On Thu, May 12, 2016 at 5:37 AM, Julien Pivotto <roidelapluie@inuit s.eu> wrote:
Please remember that ze do not plan to expose that to users (e.g puppet will be installed in /usr, not in a SCL). However, those SCL will be used for dependencies and/or rebuilds of EPEL packages.
The big headline on softwarecollections.org is:
All versions of any software on your system. Together.
That is how I have always understood it. So how would installing to /usr fit the SCL paradigm? Or has the SCL paradigm changed?
We are not the SCL sig. We do not plan to let you install multiple versions of Puppet at the same time on your system.
Hi,
Why not have multiple versions of puppet, it seems like a good idea.
My preference is to have puppet in /usr/bin, configuration in /etc/puppet. Upstream also does not allow to have multiple puppet versions at the same time. It is not the intention of the SIG to build SCL's. I'd prefer that we use them for pure technical reasons e.g because we use ruby SCL's in the back and we miss a gem.
But even with just one I would also put everything in the software collection and just avoid the system, apart from anything else it will clash with the epel pkgs and what not.
Maybe we can get input from the Foreman project, they use the same pattern as the one I describe.
On 13/05/16 10:27, Julien Pivotto wrote:
On 13 May 11:03, Steve Traylen wrote:
On Thu, 2016-05-12 at 20:24 +0200, Julien Pivotto wrote:
On 12 May 11:04, BC wrote:
On Thu, May 12, 2016 at 5:37 AM, Julien Pivotto <roidelapluie@inuit s.eu> wrote:
Please remember that ze do not plan to expose that to users (e.g puppet will be installed in /usr, not in a SCL). However, those SCL will be used for dependencies and/or rebuilds of EPEL packages.
The big headline on softwarecollections.org is:
All versions of any software on your system. Together.
That is how I have always understood it. So how would installing to /usr fit the SCL paradigm? Or has the SCL paradigm changed?
We are not the SCL sig. We do not plan to let you install multiple versions of Puppet at the same time on your system.
Hi,
Why not have multiple versions of puppet, it seems like a good idea.
My preference is to have puppet in /usr/bin, configuration in /etc/puppet. Upstream also does not allow to have multiple puppet versions at the same time. It is not the intention of the SIG to build SCL's. I'd prefer that we use them for pure technical reasons e.g because we use ruby SCL's in the back and we miss a gem.
But even with just one I would also put everything in the software collection and just avoid the system, apart from anything else it will clash with the epel pkgs and what not.
Maybe we can get input from the Foreman project, they use the same pattern as the one I describe.
It's true, we use the same pattern in Foreman of having a single 'foreman' application RPM uses an SCL (sclo-ror42) which has the limitation BC mentions, that you can only have one version of Foreman installed. For us that's a reasonable limitation, particularly as it's backed by an external database with version-specific schema.
I can see four main options:
1. Package a cfgmgmt tool entirely as an SCL using SCL macros, creating a metapackage etc, like a version of PostgreSQL or Python provided by the SCLo SIG. a. traditional SCL, which requires enabling the SCL to access binaries b. provide extra unique names under /usr, /etc for easy access
2. Package a cfgmgmt tool under /opt, have it activate an SCL to get its dependencies (Python, Ruby etc). a. provide a common name under /usr, /etc which will deliberately conflict with other packages, so users must choose one b. provide a unique name under /usr, /etc which will allow multiple versions, e.g. /usr/bin/puppet4.4
Foreman's packaged along the lines of 2(a), where it uses an SCL for dependencies and can only be installed once. I think Julien's proposing the same for config management tools.
I can see advantages of having multiple versions of a config management tool installed, especially for doing upgrades where you could run version 1 for production use, and version 2 in a testing/no-op mode. I can imagine this would be very useful for "power users" and large environments.
The main disadvantage is that it'll surprise users who either know, are reading documentation or using software designed for existing packages with files and binaries in common paths (/usr/bin/puppet, /etc/puppet). This will make it harder to adopt packages from this SIG as they may not be drop-in replacements for packages from other sources, like EPEL.
Perhaps there's some middle ground, e.g. using alternatives to support multiple versions while trying to keep paths identical to existing packages? The SIG's packages couldn't then be installed alongside an EPEL package, but you might be able to install multiple versions from the SIG. It'd require extra work though.
On 13 May 10:55, Dominic Cleal wrote:
I can see four main options:
- Package a cfgmgmt tool entirely as an SCL using SCL macros, creating
a metapackage etc, like a version of PostgreSQL or Python provided by the SCLo SIG. a. traditional SCL, which requires enabling the SCL to access binaries b. provide extra unique names under /usr, /etc for easy access
- Package a cfgmgmt tool under /opt, have it activate an SCL to get its
dependencies (Python, Ruby etc). a. provide a common name under /usr, /etc which will deliberately conflict with other packages, so users must choose one b. provide a unique name under /usr, /etc which will allow multiple versions, e.g. /usr/bin/puppet4.4
Foreman's packaged along the lines of 2(a), where it uses an SCL for dependencies and can only be installed once. I think Julien's proposing the same for config management tools.
Yes. If we want that SIG to be a success be need to be 'desirable'. If each time upstream releases a new .y release, you need to change you executables, copy your config file, that will make it far too difficult for a lot of people to jump in.
I also expect that for most of the people rpm -qi puppet should be a sufficient command to know what version of Puppet is installed and in use.
If we create to much complexity and we increase arbitrary the price to move to the packages offered by this SIG I think that we will miss a big market.
I can see advantages of having multiple versions of a config management tool installed, especially for doing upgrades where you could run version 1 for production use, and version 2 in a testing/no-op mode. I can imagine this would be very useful for "power users" and large environments.
When you have large env you'd rather run version 1 for production and version 2 in a testing env. However that is still a valid point that it might be handy.
Regarding the tools, if we build the Puppet gem, that will be doable.
Ansible can be installed on 2 different machines as the pattern is different so there it is not 'so' needed (except on sysadmin machines).
The main disadvantage is that it'll surprise users who either know, are reading documentation or using software designed for existing packages with files and binaries in common paths (/usr/bin/puppet, /etc/puppet). This will make it harder to adopt packages from this SIG as they may not be drop-in replacements for packages from other sources, like EPEL.
Yes, that is my main concern. Creating packages that no-one uses is not useful.
Perhaps there's some middle ground, e.g. using alternatives to support multiple versions while trying to keep paths identical to existing packages? The SIG's packages couldn't then be installed alongside an EPEL package, but you might be able to install multiple versions from the SIG. It'd require extra work though.
You mean, like having:
- puppet RPM -> /usr/bin/puppet ; /etc/puppet - puppet44 RPM -> /opt/xxx/bin/puppet44/puppet.conf ; /etc/../puppet44/puppet.conf
It is indeed more work -- but will force us to automate as much as possible :)
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 13/05/16 13:01, Julien Pivotto wrote:
Perhaps there's some middle ground, e.g. using alternatives to support multiple versions while trying to keep paths identical to existing packages? The SIG's packages couldn't then be installed alongside an EPEL package, but you might be able to install multiple versions from the SIG. It'd require extra work though.
You mean, like having:
- puppet RPM -> /usr/bin/puppet ; /etc/puppet
- puppet44 RPM -> /opt/xxx/bin/puppet44/puppet.conf ; /etc/../puppet44/puppet.conf
I mean having:
- puppet43 RPM -> /usr/bin/puppet43 - puppet44 RPM -> /usr/bin/puppet44
and using update-alternatives(8) or similar to symlink /usr/bin/puppet to puppet43 or 44, depending on the user's preference. Other packages such as JREs use this mechanism.
I'm not sure what you'd do about confdir/vardir in the example of Puppet.
-
BC -
Dominic Cleal -
Julien Pivotto -
Steve Traylen