@mohanboddu @kevin @ausil

We have a very similar need in modularity land for taskotron testing: something that produces a compose (with no images) whenever a stack of modules is rebuilt.

Our thought was that we should make a little flask app that can produce very limited "CI" composes on request for certain accounts.

Some fedmsg-driven thing could then ping that app as it sees certain conditions fly by.

/cc @sgallagh @mikeb

Interesting that these two requests came in so close to each other. Sounds like a compose service could satisfy both use-cases.

I was kinda assuming that something like this would be a pretty innate part of Factory 2.0, and that this is more of a request for a short-term hacky implementation for Factory 1.0 until we get to the promised land. :P But if the two can be the same thing, or share bits, great.

I was figuring that the 'super shiny 2.0' version would need all the stuff that's planned to be built about knowing what bits (packages, modules, whatever) go into what 'deliverables', but for a 'dumb 1.0' version we could just do something like a hand-maintained list of package names that trigger runs of a certain compose profile (or more than one, I guess).

@mikeb this is actually something I've been talking about for like two years, I just never got around to filing a ticket till now...

@ausil @kevin @adamwill @kellin and @mohanboddu met and decided on the following things

1. @mohanboddu and @kellin will create a pungi compose config for Server Image.
2. Create an ansible job to compose a Server Image.
3. The test compose should have minimum life span of 2 days in /mnt/koji/.
4. The compose should be made from fXX-compose-testing tag which is inherited from fXX tag and the tag should have all the updates that needs to be tested. The tag should be cleaned up after each compose.
5. The initial compose_id will be Fedora_UpdatesTesting. @adamwill and @ausil will collaborate to generate a more descriptive shortname identifying the updates in the compose at a later date.
6. @adamwill will provide a list of packages that should trigger the testing compose when updated.
7. We will look into using loopabull to automate the compose process.

On 5), really the requirement is 'figure out a way the openQA scheduler can know the update ID and/or package NEVRs from the update'. The compose ID is one possible way to signal that, but there may be others. I think the only way to do it with the compose ID would be to (ab?)use the shortname property, and we haven't previously done a thing where we change the shortname for every compose of a given type, so that might present problems for you guys, I don't know. I suspect it might be something PDC isn't really designed for.

On 6), here's my initial suggested list:

anaconda
authconfig
python-blivet
pyparted
parted
pykickstart
blivet-gui
libblockdev
e2fsprogs
dosfstools
grub2
shim-signed
libselinux

A kinda 'second tier' of things that maybe aren't critical enough to worry about at first might be:

chrony
fcoe-utils
hfsplus-tools
firewalld
realmd
yelp
libtimezonemap

then there's all the things anaconda sits on top of, I'm not sure whether we want to include any of those at first, but that list would be something like:

kernel
systemd
dracut
plymouth
gtk3
python3
etc. etc.

btw, I'd suggest that it would be good to think about "Branched" rather than "26" throughout, here. By which I mean, don't just think about setting everything up for Fedora 26, think about implementing processes by which this will all also happen when Fedora 27 branches from Rawhide with minimal human intervention (and with what human intervention is actually necessary being part of a specific plan that a specific person will definitely do at a specific time).

One more thought on the signalling thing: the openQA triggering runs off the fedmsg, so we could actually live with the information not being in the compose's properties anywhere, but only in the compose fedmsgs. If that makes things any easier.

@adamwill Can you tell me if the compose should be triggered if the pkg is successfully built in koji or when that build is submitted for an update. It feels right to do when the build is submitted for an update, but I want to know your thoughts as well.

Update. We can't practically test individual package builds, because often multiple packages go together, like anaconda and blivet.

@adamwill Do you need disk images for aarch64 and armhfp or just install tree and install media?

note on the update fedmsgs to listen for: you can crib that from https://pagure.io/fedora-qa/fedora_openqa/blob/master/f/fedora_openqa/consumer.py , which has the existing bits for running tests off of updates. basically you have to listen for 'new update' messages and also for 'update edited' messages. (might want to refine the code to check whether the builds in the update changed, on edit).

on arches: in theory it might be nice to have armhfp as it's a primary arch, but in practice at present we're only actually going to be running tests on x86_64, so that's all we need at least for now.

@ralph just told me about ODCS, which sounds like exactly what we want for this sort of thing. Apparently it can't build images yet, though.

I've wanted something like this before (for even after release since atomic releases every two weeks and sometimes we want to include fixes for stuff we found after f2x released). Basically in my mind we would add two more composes (I don't think requiring them to be "on demand" is a requirement especially for the time period leading right up to release, after release on demand could be reasonable).

All we really have to do to make this happen today is just define a new pungi config and add it to the rotation. The two new composes I would say we should do are 1 for stable and 1 for updates-testing (so a candidate build can be properly updated). We'd also need a defined package subset that is just needed for anaconda.

@kellin points out that I'd already filed this years ago as #342.

This is not a break-fix but an RFE. Closing this ticket as it's part of https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/epic/1001

"Permission denied

You don't have permission to access to this page."

That's great.

@adamwill you need to log in with FAS. Ping me in IRC if you have other issues.

Has some progress been done on this in the last two months ? It would be really helpful to have the minimal composes in place before the F29 threadmill starts - otherwise I'm afraid we will be doing all the last minute production compose fixing again for yet another release...

@mohanboddu said we can reopen this ticket now (the taiga is not the thing any more apparently), so I'm re-opening it...

Current state: I have less of an urgent need for this now because I sorta gave up waiting and did it myself. openQA has a test now which creates an installer image containing the package from the update and then tests it - which is the thing I was trying to get done. (It doesn't do a live image test yet, but I'll probably implement that next).

This would still probably be nice to have for others to use and perhaps to get more images for testing, though.

@mohanboddu says the thing that's missing now is a list of the packages which should act as 'triggers' for this process; we don't really have such a thing, so we'd have to either write one or somehow try and synthesize one out of comps and kickstart and fedora-pungi data or something.

@mohanboddu will try to work on this in the F31 cycle.

Nice! Really looking forward to this, as this has the potential to save a lot of everyones time by tracking down compose breaking issues early. :)

@kevin @humaton Can you verify this work flow?

Seems fine, but I am not sure i understand the complete message... wouldn't that go to some other application to consume (openqa?)

Seems fine, but I am not sure i understand the complete message... wouldn't that go to some other application to consume (openqa?)

@kevin Yes, but this is just for our side of things, once the compose is done, it will be available on /mnt/koji/.. or some other place where qa can play with it.

The only reason I am checking if a compose is running or not because I dont want to start multiple composes at the same time.

package_to_compose.json -> holds the builds that should go into the next compose
compose_packages.json -> holds what builds went into what compose for our book keeping.

Hi, since the need for this is already covered in openqa, Release Engineering is not going to implement it.

yeah, the current way of doing things is working fine (and also provides a handy way for us to test messy changes before actually landing them where they'd affect real composes). I have to try and remember to keep up with changes to the 'real' build pipeline, but it does the job.

openQA now builds and tests an everything netinst, a workstation and a KDE live, and a silverblue ostree and installer image. These tests run on all relevant updates as derived from the comps critical path groups.