Hi guys,
I have written a summary of my discussion with dcantrell and dmach from release engineering.
https://fedoraproject.org/wiki/Anaconda/Features/InstallClassesInRepo
Might be worth a thought.
-- Martin Sivák msivak@redhat.com Red Hat Czech Anaconda team / Brno, CZ
Martin Sivak (msivak@redhat.com) said:
I have written a summary of my discussion with dcantrell and dmach from release engineering.
https://fedoraproject.org/wiki/Anaconda/Features/InstallClassesInRepo
Commenting here. If you want it on the feature page, can do that too.
1) I think the idea of having this in a package in the repo isn't the best.
- It complicates the build/update/modification process for delivery - you have to commit to a SCM somewhere, build a package, push an update, and so on. - It complicates the anaconda side - you have to find the magic package in the repo, explode it, and put it where you need to read it.
Why wouldn't we just include the data we need *in* the repository metadata (either directly as a structured form in the comps file, or as an adjunct bit of data referenced in repomd.xml)?
2) The idea of a default kickstart that this is using I'm not sure fits with our current production framework, where we have a variety of products we produce in a release (Desktop, KDE, Games, etc.) - these would *each* be a top level object, and there is no single 'default' that can be used - unless we go to a method where we actually have separate repos based on what you're installing.
If you look at other Fedora-derived distributions, we have a variety of installclasses that are used - there is no single 'default'.
Bill
Hi,
Why wouldn't we just include the data we need *in* the repository metadata (either directly as a structured form in the comps file, or as an adjunct bit of data referenced in repomd.xml)?
We were discussing this and this was my first idea too. But Dan MAch expressed concerns about versioning, because customers sometime request updated metadata and want to see the info in errata. Package can be versioned and but in the errata using existing processes.
- The idea of a default kickstart that this is using I'm not sure
fits with our current production framework, where we have a variety of products we produce in a release (Desktop, KDE, Games, etc.) - these would *each* be a top level object, and there is no single 'default' that can be used - unless we go to a method where we actually have separate repos based on what you're installing.
I am not exactly following here. This is not replacing comps groups, install data only select the groups and the kickstart will do much the same we do now: Select the default setup for installation.
If you look at other Fedora-derived distributions, we have a variety of installclasses that are used - there is no single 'default'.
The default is needed only to enable special features during pre-network stages. I didn't intend to select packages there, only to enable/disable automatic stuff like driver disc detection.. After the repository is initialized, the metadata from that repository will be used.
Martin
----- Original Message -----
Martin Sivak (msivak@redhat.com) said:
I have written a summary of my discussion with dcantrell and dmach from release engineering.
https://fedoraproject.org/wiki/Anaconda/Features/InstallClassesInRepo
Commenting here. If you want it on the feature page, can do that too.
- I think the idea of having this in a package in the repo isn't the
best.
- It complicates the build/update/modification process for delivery -
you have to commit to a SCM somewhere, build a package, push an update, and so on.
- It complicates the anaconda side - you have to find the magic
package in the repo, explode it, and put it where you need to read it.
Why wouldn't we just include the data we need *in* the repository metadata (either directly as a structured form in the comps file, or as an adjunct bit of data referenced in repomd.xml)?
- The idea of a default kickstart that this is using I'm not sure
fits with our current production framework, where we have a variety of products we produce in a release (Desktop, KDE, Games, etc.) - these would *each* be a top level object, and there is no single 'default' that can be used - unless we go to a method where we actually have separate repos based on what you're installing.
If you look at other Fedora-derived distributions, we have a variety of installclasses that are used - there is no single 'default'.
Bill
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Martin Sivak (msivak@redhat.com) said:
Why wouldn't we just include the data we need *in* the repository metadata (either directly as a structured form in the comps file, or as an adjunct bit of data referenced in repomd.xml)?
We were discussing this and this was my first idea too. But Dan MAch expressed concerns about versioning, because customers sometime request updated metadata and want to see the info in errata. Package can be versioned and but in the errata using existing processes.
An errata to change the product composition? That seems weird - we don't do that now.
- The idea of a default kickstart that this is using I'm not sure
fits with our current production framework, where we have a variety of products we produce in a release (Desktop, KDE, Games, etc.) - these would *each* be a top level object, and there is no single 'default' that can be used - unless we go to a method where we actually have separate repos based on what you're installing.
I am not exactly following here. This is not replacing comps groups, install data only select the groups and the kickstart will do much the same we do now: Select the default setup for installation.
But we don't have a single default install class. We have multiple (or no) defaults - we have a KDE desktop spin, a GNOME spin, etc. - each of these have different defaults. For that other product, we have multiple install classes, all of which has different default groups and parameters.
Bill
Hi,
An errata to change the product composition? That seems weird - we don't do that now.
This has to be discussed with release engineering then.
I am not exactly following here. This is not replacing comps groups, install data only select the groups and the kickstart will do much the same we do now: Select the default setup for installation.
But we don't have a single default install class. We have multiple (or no) defaults - we have a KDE desktop spin, a GNOME spin, etc. - each of these have different defaults. For that other product, we have multiple install classes, all of which has different default groups and parameters.
We do not do anything like this now either.. Right now anaconda uses default comps. So yes, I was thinking that in this regard each product has it's own repository.
And regarding code to explode package. We already have it in place, I use it for driverdisc features.
Martin
Martin Sivak (msivak@redhat.com) said:
An errata to change the product composition? That seems weird - we don't do that now.
This has to be discussed with release engineering then.
Obviously they should be on the list. :) But by that argument, shouldn't the certificate be packaged too?
I am not exactly following here. This is not replacing comps groups, install data only select the groups and the kickstart will do much the same we do now: Select the default setup for installation.
But we don't have a single default install class. We have multiple (or no) defaults - we have a KDE desktop spin, a GNOME spin, etc. - each of these have different defaults. For that other product, we have multiple install classes, all of which has different default groups and parameters.
We do not do anything like this now either.. Right now anaconda uses default comps.
Yes, but even those default values are filtered through the task lists defined in the install classes, which overrides them in strange and not-always-predictable ways.
So yes, I was thinking that in this regard each product has it's own repository.
With my Fedora rel-eng hat on, "ugh". Having to have separate repositories just to contain group data + 1 package seems like overkill.
Bill
This has to be discussed with release engineering then.
Obviously they should be on the list. :) But by that argument, shouldn't the certificate be packaged too?
Well before this goes completely the wrong direction. The package section modification was meant to allow for the kernel selection algorithm to work, not to replace comps mandatory and optional flags.
The RPM in question will then contain a bit of logic (when/unless) we have in anaconda right now (kernel selection) and thus versioning it is something we might really consider.
I wasn't really thinking about how the user selects tasks when I was sketching this, but we might provide multiple annotated kickstarts (with one or two groups each) in the package, show the titles in GUI and let the user select. But that would be wandering to comps territory again.
With my Fedora rel-eng hat on, "ugh". Having to have separate repositories just to contain group data + 1 package seems like overkill.
It surely is, but aren't we doing it with spins right now? Isn't every spin just another repository generated by pungi with modified kickstart?
I was actually thinking (unrelated to this, but good time to mention it :) that spin should really be just a package with dependencies, post config scripts and maybe some artwork for the spin (kind of metapackage..).
Martin
----- Original Message -----
Martin Sivak (msivak@redhat.com) said:
An errata to change the product composition? That seems weird - we don't do that now.
This has to be discussed with release engineering then.
Obviously they should be on the list. :) But by that argument, shouldn't the certificate be packaged too?
I am not exactly following here. This is not replacing comps groups, install data only select the groups and the kickstart will do much the same we do now: Select the default setup for installation.
But we don't have a single default install class. We have multiple (or no) defaults - we have a KDE desktop spin, a GNOME spin, etc. - each of these have different defaults. For that other product, we have multiple install classes, all of which has different default groups and parameters.
We do not do anything like this now either.. Right now anaconda uses default comps.
Yes, but even those default values are filtered through the task lists defined in the install classes, which overrides them in strange and not-always-predictable ways.
So yes, I was thinking that in this regard each product has it's own repository.
With my Fedora rel-eng hat on, "ugh". Having to have separate repositories just to contain group data + 1 package seems like overkill.
Bill
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Martin Sivak (msivak@redhat.com) said:
Obviously they should be on the list. :) But by that argument, shouldn't the certificate be packaged too?
Well before this goes completely the wrong direction. The package section modification was meant to allow for the kernel selection algorithm to work, not to replace comps mandatory and optional flags.
The obvious problem there is that you *have* a kernel selection algorithm. Let's just remove that. (Serious here - there is only kernel, and it works where it works - it's not like we're backporting this to older releases where we didn't have pv_ops.)
I wasn't really thinking about how the user selects tasks when I was sketching this, but we might provide multiple annotated kickstarts (with one or two groups each) in the package, show the titles in GUI and let the user select. But that would be wandering to comps territory again.
Right. We may not *have* the concept of optional packages in F17+, after all (that part of anaconda is going away, so what do they serve?)
Perhaps it's better to split out what we do with install classses now:
1. define tasks (groups of groups, can be selected in the UI) 2. set some boring metadata strings for the UI 3. skip steps we don't want to show 4. set some random configuration parameters (bootloader args? wtf?) 5. set the installer backend 6. set the upgrade match list
Now, it's entirely possible that with what you're talking about, we split some of these functions off into different areas. For example, I have no idea how we do #3 or #4 in the new anaconda UI world, even with what you're proposing.
With my Fedora rel-eng hat on, "ugh". Having to have separate repositories just to contain group data + 1 package seems like overkill.
It surely is, but aren't we doing it with spins right now? Isn't every spin just another repository generated by pungi with modified kickstart?
All spins except the weird, bastardized, 'Fedora' spin are live images, not repositories. Chris had mentioned an idea of 'fixing' the infrastructure so that it would be easier in anaconda to select a spin and get the right thing, even if you're installing from the network repo.
I was actually thinking (unrelated to this, but good time to mention it :) that spin should really be just a package with dependencies, post config scripts and maybe some artwork for the spin (kind of metapackage..).
The problem is that our current spin configurations aren't refined enough now to cleanly separate what of this is 'things that define this spin', 'things that make any spin work on a live image', and 'things that make this particular spin work on a live image'. We'd need some better organization to get there.
Bill
The obvious problem there is that you *have* a kernel selection algorithm. Let's just remove that. (Serious here - there is only kernel, and it works where it works - it's not like we're backporting this to older releases where we didn't have pv_ops.)
That would be perfect if we could just kill it. And if pv_ops solve all the cases we have to check now, it just got much better.
Right. We may not *have* the concept of optional packages in F17+, after all (that part of anaconda is going away, so what do they serve?)
Perhaps it's better to split out what we do with install classses now:
- define tasks (groups of groups, can be selected in the UI)
- set some boring metadata strings for the UI
- skip steps we don't want to show
- set some random configuration parameters (bootloader args? wtf?)
- set the installer backend
- set the upgrade match list
Now, it's entirely possible that with what you're talking about, we split some of these functions off into different areas. For example, I have no idea how we do #3 or #4 in the new anaconda UI world, even with what you're proposing.
1. We should really get this away from anaconda sources 2., 3. and 4. I hoped to use the proposed %flags section for such kind of stuff. 5. and 6. I have no idea, I haven't got that far yet :) Parts will obviously be controllable by flags, for some we might need some kind of another section
We might use different format for this than kickstart at the end, I based the proposal around it simply because most of the stuff is already there (at least the parser :).
It surely is, but aren't we doing it with spins right now? Isn't every spin just another repository generated by pungi with modified kickstart?
All spins except the weird, bastardized, 'Fedora' spin are live images, not repositories. Chris had mentioned an idea of 'fixing' the infrastructure so that it would be easier in anaconda to select a spin and get the right thing, even if you're installing from the network repo.
Yep we talked about spin selection in Tempe, but your answer bellow needs to be properly addressed first before that can happen...
I was actually thinking (unrelated to this, but good time to mention it :) that spin should really be just a package with dependencies, post config scripts and maybe some artwork for the spin (kind of metapackage..).
The problem is that our current spin configurations aren't refined enough now to cleanly separate what of this is 'things that define this spin', 'things that make any spin work on a live image', and 'things that make this particular spin work on a live image'. We'd need some better organization to get there.
Sure this need much broader discussion on a different level (FESCo comes in mind).
Martin
Martin Sivak (msivak@redhat.com) said:
Right. We may not *have* the concept of optional packages in F17+, after all (that part of anaconda is going away, so what do they serve?)
Perhaps it's better to split out what we do with install classses now:
- define tasks (groups of groups, can be selected in the UI)
- set some boring metadata strings for the UI
- skip steps we don't want to show
- set some random configuration parameters (bootloader args? wtf?)
- set the installer backend
- set the upgrade match list
Now, it's entirely possible that with what you're talking about, we split some of these functions off into different areas. For example, I have no idea how we do #3 or #4 in the new anaconda UI world, even with what you're proposing.
- We should really get this away from anaconda sources
No objection to that. I think it likely can be separate from most of the other items, and we need to figure out, in the context of spins, etc. what the best form & location for this data is.
Given the UI redesign, I'm not even sure we would have the concept of 'tasks' as they currently exist.
2., 3. and 4. I hoped to use the proposed %flags section for such kind of stuff.
OK. #2 is text shown on the task screen; we can punt that handling until we figure out tasks for #1.
#3, in the examples I have, is skipping filtertype, as a hack to disable certain install targets. It's highly anaconda-version specific, and I don't know if we want to, or need to, support that going forward.
#4 we could use flags. We'd need to define what sort of flags we need, as, like with #3, what's done with this currently is taking advantage of being able to frob random things in the anaconda runtime data.
- and 6. I have no idea, I haven't got that far yet :) Parts will obviously be controllable by flags, for some we might need some kind of another section
#5 is ideally set automatically from the method/repo URL? Dunno.
#6 ... should probably find a better way in general to handle this.
Bill
The obvious problem there is that you *have* a kernel selection algorithm. Let's just remove that. (Serious here - there is only kernel, and it works where it works - it's not like we're backporting this to older releases where we didn't have pv_ops.)
In Fedora right now, it looks like we only have kernel vs. kernel-PAE on i686. I don't remember whether or not we're going to continue doing i686. If not, then yeah we should definitely kill this code.
Right. We may not *have* the concept of optional packages in F17+, after all (that part of anaconda is going away, so what do they serve?)
We've been discussing not having an optional package selection UI in anaconda, and relegating this to a kickstart-only thing. Of course if you are doing install classes via kickstart, then you still have the ability to enable optional packages. However, at that point they really become default packages since you've got nowhere to disable them.
- define tasks (groups of groups, can be selected in the UI)
- set some boring metadata strings for the UI
- skip steps we don't want to show
- set some random configuration parameters (bootloader args? wtf?)
- set the installer backend
- set the upgrade match list
Now, it's entirely possible that with what you're talking about, we split some of these functions off into different areas. For example, I have no idea how we do #3 or #4 in the new anaconda UI world, even with what you're proposing.
There will be no concept named "steps" in the new UI. It should be possible to remove spokes via an updates image that just toggles the showable property.
Random configuration parameters - no ideas yet.
Tasks - we're not really going to have a concept of tasks, though what we'll do instead is still a bit up in the air. At least, I don't remember much about this given that the majority of our effort has been spent designing a storage UI. Since I am currently working on the Install Source spoke, I'll likely turn my attention to Software Selection next.
All spins except the weird, bastardized, 'Fedora' spin are live images, not repositories. Chris had mentioned an idea of 'fixing' the infrastructure so that it would be easier in anaconda to select a spin and get the right thing, even if you're installing from the network repo.
I don't remember this, but that's not at all surprising.
- Chris
On Wed, 2011-11-16 at 06:59 -0500, Martin Sivak wrote:
Hi guys,
I have written a summary of my discussion with dcantrell and dmach from release engineering.
https://fedoraproject.org/wiki/Anaconda/Features/InstallClassesInRepo
Might be worth a thought.
It's an interesting idea - I like the "when/unless" syntax, too.
One question: why store it in a package? This seems a lot like .buildstamp - it's metadata the installer uses to decide how it should run and what options it should present.
We could store the various .installclass files (or whatever they would be called) in a package like we do with fedora-kickstarts.
In fact, in the future I'd like to see all the bits and pieces that go into making a tree/image (kickstarts, bootloader configs, lorax templates, etc.) collected in one package, with one directory per spin. Having an 'installclass' file in there would be pretty simple, and that'd allow lorax to drop it into the agreed-upon place in the tree.
Unless there's some reason it needs to be inside a package in the tree?
-w
Hi,
One question: why store it in a package? This seems a lot like .buildstamp - it's metadata the installer uses to decide how it should run and what options it should present.
Yes, but this information should be based on what you are installing not on from which build you got the installer.
We could store the various .installclass files (or whatever they would be called) in a package like we do with fedora-kickstarts.
In fact, in the future I'd like to see all the bits and pieces that go into making a tree/image (kickstarts, bootloader configs, lorax templates, etc.) collected in one package, with one directory per spin. Having an 'installclass' file in there would be pretty simple, and that'd allow lorax to drop it into the agreed-upon place in the tree.
Unless there's some reason it needs to be inside a package in the tree?
See my answer to Bill about versioning stuff..
Martin
anaconda-devel@lists.fedoraproject.org
-
Bill Nottingham -
Chris Lumens -
Martin Sivak -
Will Woods