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