[CentOS-devel] Tags structure proposal (and fix) for CBS

Thu Mar 19 16:04:14 UTC 2020
Alfredo Moralejo Alonso <amoralej at redhat.com>

Hi,

On Wed, Mar 18, 2020 at 5:47 PM Fabian Arrotin <arrfab at 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 at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200319/4983bd75/attachment-0007.html>