When working with Thomas on new signing process, we decided that we'd use Koji/CBS as single source of truth, so new signing process should only query koji/cbs and automatically act when there would be something to do.
Creating so a different thread to discuss the koji tags we have. We discovered some inconsistencies and we think that $now would be a good time to fix/move those if needed.
The current proposal would be (and most of the existing tags are following that convention) :
<sig><dist>-<sig_project>-<sig_project_rel>-<sig_level> If we take an example for Gluster 7 for CentOS 7, built by Storage SIG, that means the following tags : storage7-gluster-7-{candidate,testing,release}
The path where new process would automatically push out (to mirror CDN) would be so based on koji tag : mirror.centos.org/{centos,altarch}/<dist>/<sig>/{arch}/<sig_project>-<sig_project_rel>/
Once again, if we take the gluster 7 as an example, that would mean that process would automatically (for -release tag, with three enabled arches), push to those paths (created if needed) :
* http://mirror.centos.org/centos/7/storage/x86_64/gluster-7/ * http://mirror.centos.org/altarch/7/storage/aarch64/gluster-7/ * http://mirror.centos.org/altarch/7/storage/ppc64le/gluster-7/
The full path is coming from the koji tag, but we see some issues for some paths/SIGs (like NFV)
As we think that it would be good to have confirmations from all SIGs (as they are responsible for content to be pushed out, and also good time to have EOL content removed), we'd eventually "lock" koji tags for which we have *not* received confirmation for final destination path.
Other thing we discovered : some SIGs (in the past) have asked for a "common" tag but then have asked (through cbs-content-control) to have content from that common tag to be added in other repo.
As we'll *not* use cbs-content-control anymore, the way to deal with this would be : - either we use koji tag inheritance (preferred solution) - or you just "tag-build" yourself when needed from one to the other
The advantage of doing this through koji tag inheritance is the following : When you request for some tags, and specify what they would need, nothing else would have to be done and you can just tag-build from -testing to -release to trigger the sign+push to mirrors (while tag-build to -testing first would push unsigned pkgs automatically to buildlogs.centos.org, as usual)
Can we ask each SIG Chair to see which projects/releases are still needed and so come back (either in this thread of #centos-devel)
Thanks for your collaboration !
Hi,
On Wed, Mar 18, 2020 at 5:47 PM Fabian Arrotin arrfab@centos.org wrote:
When working with Thomas on new signing process, we decided that we'd use Koji/CBS as single source of truth, so new signing process should only query koji/cbs and automatically act when there would be something to do.
Creating so a different thread to discuss the koji tags we have. We discovered some inconsistencies and we think that $now would be a good time to fix/move those if needed.
The current proposal would be (and most of the existing tags are following that convention) :
<sig><dist>-<sig_project>-<sig_project_rel>-<sig_level> If we take an example for Gluster 7 for CentOS 7, built by Storage SIG, that means the following tags : storage7-gluster-7-{candidate,testing,release}
The path where new process would automatically push out (to mirror CDN) would be so based on koji tag : mirror.centos.org/{centos,altarch}/ http://mirror.centos.org/%7Bcentos,altarch%7D/ <dist>/<sig>/{arch}/<sig_project>-<sig_project_rel>/
Once again, if we take the gluster 7 as an example, that would mean that process would automatically (for -release tag, with three enabled arches), push to those paths (created if needed) :
- http://mirror.centos.org/centos/7/storage/x86_64/gluster-7/
- http://mirror.centos.org/altarch/7/storage/aarch64/gluster-7/
- http://mirror.centos.org/altarch/7/storage/ppc64le/gluster-7/
The full path is coming from the koji tag, but we see some issues for some paths/SIGs (like NFV)
As we think that it would be good to have confirmations from all SIGs (as they are responsible for content to be pushed out, and also good time to have EOL content removed), we'd eventually "lock" koji tags for which we have *not* received confirmation for final destination path.
IIUC the proposed naming and repos location is the same used by CloudSIG, so i think it's fine for us. WRT EOL, at this point we support:
- openstack-rocky (will be EOLed in a couple of weeks or so) - openstack-stein - openstack-train
openstack-queens is EOL and can be moved to EOL.
Other thing we discovered : some SIGs (in the past) have asked for a
"common" tag but then have asked (through cbs-content-control) to have content from that common tag to be added in other repo.
As we'll *not* use cbs-content-control anymore, the way to deal with this would be :
- either we use koji tag inheritance (preferred solution)
- or you just "tag-build" yourself when needed from one to the other
The advantage of doing this through koji tag inheritance is the following : When you request for some tags, and specify what they would need, nothing else would have to be done and you can just tag-build from -testing to -release to trigger the sign+push to mirrors (while tag-build to -testing first would push unsigned pkgs automatically to buildlogs.centos.org, as usual)
Can we ask each SIG Chair to see which projects/releases are still needed and so come back (either in this thread of #centos-devel)
As stated before:
- openstack-rocky (will be EOLed soon) - openstack-stein - openstack-train
Thanks for your collaboration !
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-
Alfredo Moralejo Alonso -
Fabian Arrotin