#388 Grant Hyperscale the ability to create live media and appliance images
Closed: Duplicate by ngompa. Opened by ngompa.

Hyperscale is working on creating spins, which requires the ability to produce media in CBS.

We need the ability to use the following calls for at least scratch builds (and ideally also real builds in the future):

  • appliance
  • image
  • livecd
  • livemedia
  • createAppliance
  • createImage
  • createLiveCD
  • createLiveMedia

We're currently planning on using the createLiveCD and createAppliance scratch build tasks and going from there.


Metadata Update from @mobrien:
- Issue tagged with: cbs, centos-common-infra

Metadata Update from @arrfab:
- Issue assigned to arrfab

Metadata Update from @arrfab:
- Issue tagged with: feature-request, need-more-info

Hey @ngompa ,

a cbs list-permissions shows indeed the image, appliance, livecd, image and appliance permissions, but not the livemediaone. Do you know from where it should be coming ?
In the past, the image one was enough for some SIGs to build (through imagefactory) images, but the centos vagrant images aren't built anymore through cbs.centos.org, so nobody is using that feature anymore.

Happy to verify with you as it can be that the oz/imagefactory stack running on 8-stream now doesn't fully work.

The livemedia one is the lorax-based stuff using livemedia-creator.

I mean that it's not in standard koji so wondering from where it's coming. Any pointer ?

Seems to be part of kojid:

  • https://pagure.io/koji/blob/master/f/builder/kojid#_85-93
  • https://pagure.io/koji/blob/master/f/builder/kojid#_2781-2918
  • https://pagure.io/koji/blob/master/f/builder/kojid#_3426-3674

as said, it shows livecd, appliance and image permissions (which you should already have).
Don't know about the one not shown in default koji ...

Found that one has to create the channel/permissions in koji and it's now done.
Still based on the official doc now, we need to define which packages can enter the livemedia-buildgroup and tag it.
@ngompa : happy to do it for one of your hyperscale -build tag and then you can give it a try with a scratch build ?
Other thing I saw in upstream doc : Since only packages you have built (or include from an external repo) should be there so in theory that means that it would be able to combine CentOS Stream repositories and your hyperscale ones (built through cbs) so worth giving it a try if you have a kickstart ?

It seems like our tags only have epel8-next and not epel8 as well (epel8-next is an overlay on epel8).

And I don't see a build tag that exists with all of our hyperscale repos + epel repos + centos stream repos.

I can produce a kickstart fairly easily to test with, but I don't think we have a tag for it.

proposal : create a dedicated new tag/build target that can be used to build media and using koji inheritance to cherry-pick which external repositories and cbs other tags to combine. Would that work for you ?

Absolutely, that'd be perfect!

well, have other tasks to work on in parallel (back from PTO this week) but if you can come with a name and list of other tags/external repos, I'll create it and you'll be able to give it a try :)

hyperscale8s-spin_media-main (with -build/-candidate/-testing/-release suffixes) with contains:

  • hyperscale8s-packages-main-release
  • hyperscale8s-packages-hotfixes-release
  • hyperscale8s-packages-spin-release
  • centos8s-cr
  • centos8s-extras
  • centos8s-powertools
  • centos8s-appstream
  • centos8s-baseos
  • epel8-next
  • epel8

Additionally, I'd like hyperscale8s-spin_media-experimental (with -build/-candidate/-testing/-release suffixes) that additionally contains hyperscale8s-packages-experimental-release.

Can you update that tag name to be following the standard naming convention ?
-- , so 3 fields and hyperscale8s-spin-media-main has 4.
What about hyperscale8s-media_spin-main (and so hyperscale8s-media_spin-experimental) ?

hyperscale8s-spin_media works, I've updated the request comment.

both hyperscale8s-spin_media-main and hyperscale8s-spin_media-experimental tags were created (with candidate/testing/release, per usual process) and normally with external repositories and other inheritances (from your other tags)
Please just verify as I'm doing this while attending Nest sessions and it's 10pm here already :-)

Update: hold on while I'll have first to create the livemedia-buildpkg group for these tags with some pkgs to be used to populate the buildroot .. I'll update when done

For createLiveCD, we want livecd-tools, and for createAppliance, we want appliance-tools. I'm not actually sure how this is done, though I know Fedora's Koji has this set up.

Let's just start with spin-livemedia koji task and we'll see later about the other ones, as livecd seems deprecated and appliance is clearly marked in doc as "The spin-appliance command, described herein, is deprecated." (https://docs.pagure.org/koji/image_build/#building-appliances)

Can you give it a try (scratch build) against either hyperscale8s-spin_media-experimental-el8s-build or hyperscale8s-spin_media-main-el8s-build tags ?

the livemedia-build pkg group was added for both and with "bash coreutils glibc-all-langpacks lorax-lmc-novirt selinux-policy-targeted shadow-utils util-linux" pkgs (per koji doc)

I can't use spin-livemedia because that uses livemedia-creator and our stuff uses livecd-tools.

well, that's the one we discussed in this thread, that we wanted to start with, as it's the officially supported one (https://docs.pagure.org/koji/image_build/#building-livemedias) .
So if you want to use spin-livecd let's start from scratch with a pkg list for the pkg-group.
Can you provide the pkgs to be populated in that group ? Once done you'll be able to give it a try.

PS: as it seems deprecated, it's not listed on official koji upstream doc, so I guess that it's livecd-build group pkg that is needed.
Curious btw : why do you want to build with a method that seems deprecated ? (and so subject to disappear completely) . What's wrong with the livemedia-creator task that seems to be the one supported by koji for the future ?

well, that's the one we discussed in this thread, that we wanted to start with, as it's the officially supported one (https://docs.pagure.org/koji/image_build/#building-livemedias) .
So if you want to use spin-livecd let's start from scratch with a pkg list for the pkg-group.
Can you provide the pkgs to be populated in that group ? Once done you'll be able to give it a try.

The group is the same as livemedia-build except you swap lorax-lmc-novirt for livecd-tools.

So as you listed, it is: "bash coreutils glibc-all-langpacks livecd-tools selinux-policy-targeted shadow-utils util-linux"

PS: as it seems deprecated, it's not listed on official koji upstream doc, so I guess that it's livecd-build group pkg that is needed.
Curious btw : why do you want to build with a method that seems deprecated ? (and so subject to disappear completely) . What's wrong with the livemedia-creator task that seems to be the one supported by koji for the future ?

There are a few reasons:

  1. livemedia-creator (from lorax) is built on Anaconda. While I do have a build of Anaconda that might work, that needs much more testing before I'd be confident in using it for that purpose.
  2. It's impossible to customize Lorax's behavior to deal with hotfix packages (to override modules) and such, because the pykickstart team refuses to consider extending the kickstart language to handle it. And plumbing that through myself requires a lot of work on lorax, pykickstart, and anaconda.
  3. I'm the upstream for livecd-tools, so I am able to extend and customize its behavior to support our needs, given the constraints of CBS. I do not know why the tasks for building media with livecd-tools and appliance-tools were deprecated since I actively maintain the tools.

ack so the livecd-build group-pkg is now added for both hyperscale8s-spin_media-main-el8s-build and hyperscale8s-spin_media-experimental-el8s-build
Can you give it a try ? let's try first with livecd and we can then give appliance a try ?

Metadata Update from @arrfab:
- Issue priority set to: Waiting on Reporter (was: Needs Review)

no feedback for the last 3 weeks, so removing myself from that task for now ...

Metadata Update from @arrfab:
- Assignee reset

@arrfab Sorry, I've been working on making the new kickstarts to test with it, I'm hoping to test this week.

I've done some testing locally and the big problem I noticed up front is that Hyperscale images cannot build on a standard CentOS 8 environment (which is what CBS builders currently have). If we could get a builder for images running our kernel (once we've completed our rebase to the CS9 kernel) and our systemd, then we should be good to go for building Hyperscale 8 images.

@ngompa as discussed during last centos dojo, we can setup something like this and give it a try.
Can you point to specific kernel that we can use for this ? also, is a newer systemd pkg also really needed for the build part ? I understand for kernel (that needs to know about btrfs) but curious about systemd.
Can you point us to specific build that we'd need to apply ? As nothing was tagged to -release (yet) we'll have to download from cbs and apply

The newer systemd is needed because of the SELinux policy stuff. @dcavalca, @jvreeland, and I will hopefully have the kernel we want to use for this within a week or so.

@ngompa Is this still something you want to have?

Yes, I do. I also want to use the new kiwi build functionality in Koji 1.28 once that's deployed in CBS.

I'm planning to resume this work with CentOS Stream 9 bringup in Hyperscale. This will also require us to get a builder deployed running CentOS Stream 9 with Btrfs support enabled (either via the Kmods SIG version or through deploying the Hyperscale kernel).

Metadata Update from @zlopez:
- Issue priority set to: Waiting on Assignee (was: Waiting on Reporter)

We've decided going to focus on kiwi going forward, so let's close this and concentrate on https://pagure.io/centos-infra/issue/696 to get that enabled. Thanks!

Metadata Update from @ngompa:
- Issue close_status updated to: Duplicate
- Issue status updated to: Closed (was: Open)

Log in to comment on this ticket.

Metadata