I just had a look at CBS and was wondering how one SIG (so not ConfigMgmt SIG specific, but let's use that as an example) can interact with other SIGs.
One example is Ansible : it seems some other SIGs are relying on it and so actually the ConfigMgmgt SIG isn't able to build it as it's already built with the same ENVR but in a different target/tag : https://cbs.centos.org/koji/packageinfo?packageID=1947
What would be the option for this ? Actually the direct option is for the ConfigMgmt SIG to just tag that build (for example for ansible-2.1.0.0-1.el7) so that it will appear in the correct repositories, but I'm wondering if such SIG wouldn't have to be considered "authoritative" and so having to discuss/bump/build new releases, and then other SIGs can just consume/tag a specific build/ENVR they want in their own repositories.
2016-07-12 9:10 GMT+02:00 Fabian Arrotin arrfab@centos.org:
I just had a look at CBS and was wondering how one SIG (so not ConfigMgmt SIG specific, but let's use that as an example) can interact with other SIGs.
One example is Ansible : it seems some other SIGs are relying on it and so actually the ConfigMgmgt SIG isn't able to build it as it's already built with the same ENVR but in a different target/tag : https://cbs.centos.org/koji/packageinfo?packageID=1947
What would be the option for this ? Actually the direct option is for the ConfigMgmt SIG to just tag that build (for example for ansible-2.1.0.0-1.el7) so that it will appear in the correct repositories, but I'm wondering if such SIG wouldn't have to be considered "authoritative" and so having to discuss/bump/build new releases, and then other SIGs can just consume/tag a specific build/ENVR they want in their own repositories.
-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
Concerning Cloud SIG, we're relying on two packages that are Cfg Mgmt SIG-related: * Puppet: puppet is quite critical for us, as it's the heart of our installers (packstack, TripleO), critical component for our CI and also upstream CI. We also had to patch Puppet3 default for buggy Puppet behaviours (like not supporting provides), I co-maintain the Fedora package with the help of Red Hat puppet experts. Our puppet package is mere rebuild of Fedora Rawhide (with a decent amount of CI/testing before being shipped) * Ansible: It's more and more used in our infrastructure, WeiRDO our CI swiss-knife relies on it. We're currently not shipping it but we'll likely have too.
I don't mind handing puppet packaging to Cfg Mgmt as authoritative source, nor Ansible, I think we can manage to work together. What worries me is that CfgMgmt SIG used to think about relying on Software Collections, that we're not ready to use in the Cloud SIG.
Regards, H.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 12/07/16 16:36, Haïkel wrote:
2016-07-12 9:10 GMT+02:00 Fabian Arrotin arrfab@centos.org:
I just had a look at CBS and was wondering how one SIG (so not ConfigMgmt SIG specific, but let's use that as an example) can interact with other SIGs.
One example is Ansible : it seems some other SIGs are relying on it and so actually the ConfigMgmgt SIG isn't able to build it as it's already built with the same ENVR but in a different target/tag : https://cbs.centos.org/koji/packageinfo?packageID=1947
What would be the option for this ? Actually the direct option is for the ConfigMgmt SIG to just tag that build (for example for ansible-2.1.0.0-1.el7) so that it will appear in the correct repositories, but I'm wondering if such SIG wouldn't have to be considered "authoritative" and so having to discuss/bump/build new releases, and then other SIGs can just consume/tag a specific build/ENVR they want in their own repositories.
-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
Concerning Cloud SIG, we're relying on two packages that are Cfg Mgmt SIG-related:
- Puppet: puppet is quite critical for us, as it's the heart of our
installers (packstack, TripleO), critical component for our CI and also upstream CI. We also had to patch Puppet3 default for buggy Puppet behaviours (like not supporting provides), I co-maintain the Fedora package with the help of Red Hat puppet experts. Our puppet package is mere rebuild of Fedora Rawhide (with a decent amount of CI/testing before being shipped)
- Ansible: It's more and more used in our infrastructure, WeiRDO our
CI swiss-knife relies on it. We're currently not shipping it but we'll likely have too.
I don't mind handing puppet packaging to Cfg Mgmt as authoritative source, nor Ansible, I think we can manage to work together. What worries me is that CfgMgmt SIG used to think about relying on Software Collections, that we're not ready to use in the Cloud SIG.
Regards, H.
Well, AFAIK (but Julien would be able to comment/answer on that topic) the SCLs would be used for puppet4. (and I even think that the target is puppet4, so not building puppet 3.x anymore)
2016-07-12 16:54 GMT+02:00 Fabian Arrotin arrfab@centos.org:
Well, AFAIK (but Julien would be able to comment/answer on that topic) the SCLs would be used for puppet4. (and I even think that the target is puppet4, so not building puppet 3.x anymore)
Actually puppet4 does not require SCL, currently the biggest issue we have is facter3. It has been rewritten in C++ and relies on much recent Boost than available in BaseOS, since Boost is critical dependency, we need a //-installable variant. As it's a large package, it needs to be properly reviewed by someone else. (If anyone is interested, please ping me)
-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 12 09:10, Fabian Arrotin wrote:
I just had a look at CBS and was wondering how one SIG (so not ConfigMgmt SIG specific, but let's use that as an example) can interact with other SIGs.
One example is Ansible : it seems some other SIGs are relying on it and so actually the ConfigMgmgt SIG isn't able to build it as it's already built with the same ENVR but in a different target/tag : https://cbs.centos.org/koji/packageinfo?packageID=1947
What would be the option for this ? Actually the direct option is for the ConfigMgmt SIG to just tag that build (for example for ansible-2.1.0.0-1.el7) so that it will appear in the correct repositories, but I'm wondering if such SIG wouldn't have to be considered "authoritative" and so having to discuss/bump/build new releases, and then other SIGs can just consume/tag a specific build/ENVR they want in their own repositories.
-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
I don't think we have a way to enforce anything, other than relying on the SIGs to know their 'downstreams'. It might be good for us to start with a matrix of packages (which in the short-term will be hard to maintain). Perhaps we're at the point where enough of this is happening that we should start investigating a simple pkgdb.
- --Brian
On 12/07/16 16:06, Brian Stinson wrote:
What would be the option for this ? Actually the direct option is for the ConfigMgmt SIG to just tag that build (for example for ansible-2.1.0.0-1.el7) so that it will appear in the correct repositories, but I'm wondering if such SIG wouldn't have to be considered "authoritative" and so having to discuss/bump/build new releases, and then other SIGs can just consume/tag a specific build/ENVR they want in their own repositories.
-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
I don't think we have a way to enforce anything, other than relying on the SIGs to know their 'downstreams'. It might be good for us to start with a matrix of packages (which in the short-term will be hard to maintain). Perhaps we're at the point where enough of this is happening that we should start investigating a simple pkgdb.
just a regular update from the SIG's around content would be a good way to have some visibility around packages available and consumeable.
from the storage sig side of things, a couple of other SIGs already tag content over rather than produce it locally.
regards
-
Brian Stinson -
Fabian Arrotin -
Haïkel -
Karanbir Singh