(To possibly help with the agenda): Is Fedora Infrastructure fine with the plan? Legal?

The changes will probably affect releng more than infra.

Nominating to vote "en block" on this feature.

Ausil, could you comment here in ticket or are you planning to attend FESCo meeting?

agreed defer to next week, more discussion with other relengs needed (+6,-0)

Please Denis, could you get in touch with rest of the group and solve the technical issues? Thanks.

Hi,

This does require a lot of additional work to support, It is a lot of extra deliverables and there is no current process or support to do any of it. So while I am not willing to say no, im not willing to commit to doing everything needed to support this. after talking with some of the other Red Hat release engineers i can get some help to get some of it done, but its likely going to require more than just the two of us to deliver things.

at this point I am not 100% sure what exactly will be needed or all the details how it can all work.

Dennis

From release engineering:

• We need the automatic weekly scratch builds for rawhide and for the F19 branch once it occurs. These should automatically use the latest kickstart from the cloud-kickstarts git repository, and the resulting qcow2 tar.xz'd raw and will go onto alt.fedoraproject.org. Ideally, this will all be scripted rather than manual. (Right now, one kickstart script per arch; in the future, we may want to have test versions of multiple different kickstarts, so the script should be a little flexible.)
• We need qcow2 and raw.tar.xz builds for Alpha, Beta, and Final. These should go onto the mirror network along with the install ISOs and etc., and should have GPG-signed checksums. This probably needs at least some manual intervention, but isn't completely unlike what you're already doing with EC2 images.
• Continue doing what you're doing with Amazon EC2; I don't think that'll change much, although we will want to better promote the AMIs for Alpha and Beta.

Let me know how I can help with these things. I'm happy to work on things where I have the access needed.

Also, I think it would be helpful to have a list of functional requirements for koji (e.g, needs to keep track of which RPMs were used and maybe retain the corresponding source; needs to record the Oz / Imagefactory versions used to make the images; needs to make images which correspond to such and such ISO format standard; etc.). I know the Koji devs are looking at what it'll take to make Oz / Imagefactory run under a chroot so that the version used is the version from the release, but if that's not technically feasible we want to make sure we get the accountability and repeatability desired in a different way. (Oz and Imagefactory are ''designed'' to build "foreign" operating systems in consistent way, and Oz builds the actual contents of the image in a VM using the included Anaconda, so it's actually ''more'' repeatable and correct than the current chroot approach in any case, but any bugs found in the infrastructure will need to be fixed on the builders rather than in the repo, kind of like if there is a bug found in mock today. Conceptually, one can think of the new image build process as a new builder subsystem running on the same level as mock, not underneath it.)

I'm happy to take on some of the actual work to produce the images. I'll need the appropriate access to release engineering infrastructure.

Based on our conversation at FUDCon, I understood that you (Dennis) were planning to do scripted weekly image builds anyway, which is the first item on the list above. And you're already doing the third one. It's the middle thing, the official signed builds, which is really new work, right?

its not just the composing of images. right now everything is manual, Im planing to do automated weekly composes of the install tree. that never included any cloud anything.

today we have no means to automatically upload and register the images, i have to run through a few steps manually to do it. there is no means to automatically make it available in ec2. so far we have never had a ec2 image at alpha because composing has been broken every time. we have done very few ec2 uploads. so i really dont want to commit to producing images for Alpha.

we need to do major work on the tooling and procceses for both composing images, as well as deployment of them. that is to make the tree for the Images as well as to upload to ec2 and do all the bits, I am sure its all doable but it is a massive amount of work. If it was just composing the images it wouldnt be a big deal thats a pretty small part of the workflow.

Replying to [comment:8 ausil]:

today we have no means to automatically upload and register the images, i have to run through a few steps manually to do it. there is no means to automatically make it available in ec2. so far we have never had a ec2 image at alpha because composing has been broken every time. we have done very few ec2 uploads. so i really dont want to commit to producing images for Alpha.

Imagefactory can convert and push images into the cloud, so this feature should ''reduce'' that workload overall. The new infrastructure (and active maintenance of the images themselves) means that composing ''should not'' be broken (and building images automatically from rawhide and from the branch should help ensure that). Jay is working on the tooling upstream, and it's my understanding that it'll be ready in a timely manner. If there are particular requirements that we might not be aware of, it'd be really good to hear about them sooner rather than later.

In order to produce high-quality cloud images, we really do eventually need composing of the cloud images to not be broken at Alpha release time, but if consensus is that the schedule is too aggressive for F19, we could make Alpha cloud images a soft goal and not a feature-breaker this time around.

AGREED: Feature is approved (+9, 0, 0)