marking as blocked as it needs investigation/time as kiwi was just tested but nothing after, and there is no process to ship anything at this stage. To be discussed at next public infra sig / prioritisation call in two weeks, and see if we're allowed to work on this now or later

Can this get unblocked?
The Hyperscale SIG is now able to create images and containers with kiwi, but the Alternative Images SIG is completely stopped.

I understand that we cannot sign or push our images until #1039 is finished, but we cannot try anything until we have some targets and tags to test with. We have several months of setting up configurations and testing builds and scripts before we are ready to sign and push anything.

Can we follow the naming convention from SIGs guide ?
https://sigs.centos.org/guide/cbs/#koji-naming-convention
Also, now this request seems duplicate of #958 so worth closing one and discussing in this ticket ? :)

Before we try to blindly create these, let's have a common pattern so that when I'll have free time (almost none as you know) to work on the releng process, it will be already using the correct name (it's actually parsing the tags to know what to push and where)

Back to $topic, based on guideline, as group is sig-altimages , that means that koji tags should be named like this : altimages{8s,9s}-<project>-<version>-{candidate,testing,release}

Now that's the interesting part, and ideally Hyperscale SIG would do the same : either we decide that is something like spin_media (example : https://cbs.centos.org/koji/search?match=glob&type=tag&terms=spin_media) or something else (but let's just stick to one and then document it so that it's then official)

@ngompa , @dcavalca ^ opinions to standardize on spin_media for when it's an image (whatever the format, like .iso, .qcow2, etc)

If so, that can be (again, example) : altimages8s-spin_media-<whatever> (can be even 'live' for live images so altimages8s-spin_media-live) .. Creating tags is automated but we need first a hard decision so that we can document that as "spin" policy for cbs :)

As it seems Hyperscale is using that, we can use spin_media if that works for you

@ngompa , @dcavalca ^ opinions to standardize on spin_media for when it's an image (whatever the format, like .iso, .qcow2, etc)

I think using spin_media is fine. It's a little weird with the naming of the AltImages SIG, but it's probably fine at large scale. We came up with that term as an alternate for packages that wouldn't be too confusing with the Hyperscale spin work. Alternatively, we could call it images (like how we normally default to packages).

I am fine closing #958 and keeping this one.

I totally agree with using the standard naming convention. I totally missed that when I originally created this ticket.

I would prefer images as @ngompa said above. But I don't hate spin_media

As for different types of <version> we'll have to discuss those. What types we will create and what to call them. But for the initial tags and targets, use live because I know we all agree on that.

@ngompa , @tdawson : happy to use images but that would mean recreating the hyperscale tags then. Let me give your final decision on either images or spin_media and then I can create tags

PS : @amoloney : can we discuss that publicly so that SIGs don't have wrong expectations about time we can spend on this ?

I'm fine with images, we haven't released any artifacts yet that would cause this to be a problem. Let's go ahead and change it.

both koji targets are created now, based on discussion in this thread :

https://cbs.centos.org/koji/search?match=glob&type=target&terms=altimages*

You can now start doing some kiwi scratch builds to test that it's all ok ?

Ugh, I can't because https://pagure.io/centos-sig-alt-images/kiwi-descriptions isn't allowed for CBS. :(

true, but nothing new : the only allowed SCMs in cbs are git.centos.org and gitlab.com/CentOS/ .
I'd suggest asking for altimages namespace on gitlab (as you did for hyperscale)

Done: #1071

Worth knowing that I just added tags and kiwi-build group but no comps import was requested, so if you need that too, let me know :)

Oh, yes, I need the comps import too, please. Can we also not call it the tag -live, and use -main instead? I don't know yet of a reason to have multiple tags for different types of images (even if using different image build tools!).

Also, CBS was not able to clone from GitLab.com: https://cbs.centos.org/koji/taskinfo?taskID=3226785

https://gitlab.com/CentOS/AltImages/releng/kiwi-descriptions.git instead of 404 https://gitlab.com/CentOS/AltImages/releng/kiwi-descriptionss.git ? :)

I used live because that's what @tdawson said (see https://pagure.io/centos-infra/issue/988#comment-839884) :-)

Happy to create another one but I'll have to import comps anyway .. Let me know the final name for the tag and we can then implement it again

I think @tdawson didn't realize we can build different image types in one tag. So changing from -live to -main should be fine.

However, it looks like we don't have anaconda-live package in base CentOS Stream, so we need package targets for building anaconda with the live installer available...

it's built and in centos stream 9 , but probably not pushed out, so one can ask for the centos9s-buildroot repo to be added : https://kojihub.stream.centos.org/koji/buildinfo?buildID=30115

Ah, that would be useful. Can we have it added to our tags (at the lowest priority, so EPEL packages overshadow it)?

In retrospect, let's keep the -live tag, now that we may be having the buildroot repo for anaconda-live. Can you import comps and add the centos8s-buildroot and centos9s-buildroot repo at the lowest priority?

Done for the 9s one :

Tag: altimages9s-images-live-el9s-build [2705]
Arches: x86_64 aarch64
Groups: additional-devel, anaconda-tools, backup-client, base, base-x, build, conflicts-appstream, conflicts-baseos, console-internet, container-management, core, crb, critical-path-kde, debugging, desktop-debugging, development, dial-up, dns-server, dotnet, emacs, fedora-packager, file-server, firefox, fonts, ftp-server, gnome-apps, gnome-desktop, graphical-admin-tools, graphics, guest-agents, guest-desktop-agents, hardware-monitoring, hardware-support, headless-management, infiniband, input-methods, internet-applications, internet-browser, java-development, java-platform, kde-apps, kde-desktop, kde-education, kde-media, kde-office, kde-software-development, kf5-software-development, kiwi-build, large-systems, legacy-unix, legacy-x, mail-server, mainframe-access, multimedia, network-file-system-client, network-server, network-tools, networkmanager-submodules, office-suite, ostree-support, performance, print-client, python-web, remote-system-management, scientific, security-tools, server-product, smart-card, smb-server, srpm-build, standard, system-tools, workstation-product, xfce-desktop
Tag options:
  mock.new_chroot : 0
  mock.package_manager : 'dnf'
  mock.yum.module_hotfixes : 1
This tag is a buildroot for one or more targets
Current repo: repo#1018000: 2023-02-11 15:53:09.148163+00:00
Targets that build from this tag:
  altimages9s-images-live-el9s
External repos:
    5 centos9s-baseos (http://mirror.stream.centos.org/9-stream/BaseOS/$arch/os/, merge mode: bare), arches: inherited from tag
   10 centos9s-appstream (http://mirror.stream.centos.org/9-stream/AppStream/$arch/os/, merge mode: bare), arches: inherited from tag
   15 centos9s-crb (http://mirror.stream.centos.org/9-stream/CRB/$arch/os/, merge mode: bare), arches: inherited from tag
   20 epel9 (https://cbs.centos.org/kojifiles/repos/epel/9/Everything/$arch/, merge mode: bare), arches: inherited from tag
   25 epel9-next (https://cbs.centos.org/kojifiles/repos/epel/next/9/Everything/$arch/, merge mode: bare), arches: inherited from tag
   30 centos9s-buildroot (https://kojihub.stream.centos.org/kojifiles/repos/c9s-build/latest/$arch/, merge mode: bare), arches: inherited from tag
Inheritance:
  0    .... extras9s-extras-common-release [2555]
  5    .... buildsys9s-release [2363]
  10   .... altimages9s-images-live-candidate [2702]

Let me know how that goes and we can then proceed with the 8s one too (and hopefully nothing forgotten)

While I was at it, done for 8s too :

Tag: altimages8s-images-live-el8s-build [2701]
Arches: x86_64 aarch64
Groups: additional-devel, anaconda-tools, base, base-x, build, conflicts-baseos, core, critical-path-kde, development, dial-up, fedora-packager, file-server, firefox, fonts, gnome-desktop, graphical-admin-tools, guest-desktop-agents, hardware-monitoring, hardware-support, headless-management, infiniband, input-methods, kde-apps, kde-desktop, kde-education, kde-media, kde-office, kde-software-development, kf5-software-development, kiwi-build, large-systems, legacy-unix, mail-server, mainframe-access, multimedia, network-file-system-client, network-server, network-tools, networkmanager-submodules, performance, platform-devel, print-client, python-web, remote-system-management, scientific, security-tools, server-product, smart-card, smb-server, srpm-build, standard, system-tools, workstation-product, xfce-desktop
Tag options:
  mock.new_chroot : 0
  mock.package_manager : 'dnf'
  mock.yum.module_hotfixes : 1
This tag is a buildroot for one or more targets
Current repo: repo#1018004: 2023-02-11 19:05:29.406910+00:00
Targets that build from this tag:
  altimages8s-images-live-el8s
External repos:
    5 centos8s-extras (http://mirror.centos.org/centos/8-stream//extras/$arch/os/, merge mode: bare), arches: inherited from tag
   10 centos8s-powertools (http://mirror.centos.org/centos/8-stream//PowerTools/$arch/os/, merge mode: bare), arches: inherited from tag
   15 centos8s-appstream (http://mirror.centos.org/centos/8-stream//AppStream/$arch/os/, merge mode: bare), arches: inherited from tag
   20 centos8s-baseos (http://mirror.centos.org/centos/8-stream//BaseOS/$arch/os/, merge mode: bare), arches: inherited from tag
   25 epel8 (https://cbs.centos.org/kojifiles/repos/epel/8/Everything/$arch/, merge mode: bare), arches: inherited from tag
   30 epel8-next (https://cbs.centos.org/kojifiles/repos/epel/next/8/Everything/$arch/, merge mode: bare), arches: inherited from tag
   35 centos8s-buildroot (http://kojifiles.rdu2.centos.org/kojifiles/repos/dist-c8-stream-build/latest/$arch/, merge mode: bare), arches: inherited from tag
Inheritance:
  0    .... extras8s-extras-common-release [2563]
  5    .... buildsys8s-release [1866]
  10   .... altimages8s-images-live-candidate [2698]

Giving it a test: https://cbs.centos.org/koji/taskinfo?taskID=3226940

Image build works, though the resulting image creates broken installs. That's not a Koji problem though. :)

Great .. Let me know if you need anything else or if we can just close this ticket (as tags exist now).
We can announce/document the images decision (for the tag convention) and also have a look at automating releases later on (ticket #1039)

Was just wondering about how a proper build will be found at koji side (and so tag it). Maybe worth trying using --release=RELEASE when calling kiwi-build task and that would create specific build ?

When comparing with the ec2 images built for Stream, it's treated by koji like a package name and so with a version/release : https://kojihub.stream.centos.org/koji/packageinfo?buildStart=0&packageID=3437&buildOrder=-completion_time&tagOrder=name&tagStart=0#buildlist

Just submitted one with that parameter added: https://cbs.centos.org/koji/taskinfo?taskID=3227396

Just quickly reviewing this ticket : can we consider that tags and build targets are in a functional state to let you do some scratch build (or even a real one that would be landing into candidate) ?

Yep!

Yep.