On Sat, 2016-02-20 at 15:33 -0800, Adam Williamson wrote: > Hi folks! > > So I've been working lately on revamping the release validation process > for Pungi 4 composes. I've made quite a bit of progress, but I'm now > kind of stuck, because we don't know how the full release cycle is > actually going to work with Pungi 4 composes. There are some questions > that haven't been answered: > > * What will the compose IDs be for anything other than Rawhide snapshots? > * When do we compose what kinds of composes? > * What information do we need about the composes and where? > > I've asked if there are any plans about this a few times, and the > answer has always been "not yet". So I figured instead of sitting > around waiting, I'd think the issues through and come up with a > proposal! So I did a bit of digging around in pungi4 / productmd code today. Unfortunately it didn't really make me that happy :/ Simply put, productmd does all the things I've been thinking are a bad idea (in terms of encapsulating all sorts of specific properties of a particular compose process) and this is broadly tied into pungi4. I'm looking at stuff like this: https://pagure.io/pungi/blob/master/f/bin/pungi-koji that's the executable releng actually has to call to produce a compose. Note that it doesn't let you simply say: hey, I want a compose with ID foo. Oh, no. It requires you to specify '--nightly' to produce a "nightly" compose, or '--test' to produce a "test" compose. If you leave both of those out, you get a "production" compose, and are required to specify a "label" - but you can't just pick your label, because it calls: productmd.composeinfo.verify_label(opts.label) so let's go look at that... https://github.com/release-engineering/productmd/blob/master/productmd/composeinfo.py and, well, ew. Just in this file productmd basically enforces a whole pile of assumptions about a compose process. Really, it's assuming all composes look like RHEL composes. verify_label basically requires that the label looks like this: (MILESTONE)-(VERSION).(RESPIN) MILESTONE has to be one of "DevelPhaseExit", "InternalAlpha", "Alpha", "InternalSnapshot", "Beta", "Snapshot", "RC" or "Update". VERSION and RESPIN have to be integers (and I'm pretty sure both have various magical meanings throughout productmd). There aren't any compose types other than 'production', 'test' and 'nightly', that's all you can build. Each of these is of course a complex construct that doesn't really apply entirely to the Fedora compose process. So...yeah. We can of course slowly and painstakingly revise all this magic stuff to support Fedora's compose process as well as RHEL's...but I really just don't like the design at all. All this enforcement of metadata being bundled into compose creation makes it unnecessarily difficult to be flexible in the compose process. It also results in stuff like: you really can't do the thing where you spin up a compose, then decide you want to bless it as, say, an Alpha RC, or the Alpha itself, later. You have to declare ahead of time that this *is* "Alpha 1" or whatever. (And then the whole 'respin' thing feels like a hacky way to deal with the problem where you say "this build is going to be Alpha 1!" and then it explodes into a pile of fiery debris; if 'blessing' was separable from compose creation this would not be a problem at all). I don't really have a very productive ending to this mail, I guess I just wanted to record what I'd found, and note that it's rather at odds with my happy-clappy view of How The World Ought To Work. I guess it's useful to know that pungi4/productmd's assumptions about how non-nightly builds will be done and what they fundamentally *are* don't seem terribly compatible with Fedora's current practice; we're either going to have to change them in a hurry, I guess, or start thinking about how we adapt Fedora's processes to the way pungi4 wants to work, or come up with some kinda workaround. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
