Re: new criterion proposal: core kickstart commands
I think it's definitely too late for F18, in a moving-goalposts kind of way. But, I still would rather the criteria for F19 to be all kickstart commands work, unless they're documented as experimental or unstable, and for F20 to be a step more strict. I think Kamil's actually done 90% of that work already, and I'm happy to work with everyone and the anaconda team to update the official kickstart documentation -- but I think there's enough going on right now that it's _best_ for that to wait until after the F18 release. On our QA meeting we have agreed that we will judge kickstart issues for Fedora 18 on a case-by-case basis. Once Fedora 18 is out, I'll revive this topic and ask anaconda developers to participate here too. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
I agree with Matt. Kickstart is not only a lowest common denominator it is a critical functionality for tons of our testing and deployment tools. We don't want revolutionary change in kickstart and we definitely cannot have it be broken. Slow, gradual change properly documented is critical for kickstart. I'm less concerned about changes in anaconda's UI if I know kickstart will continue functioning. OTOH the GUI is much more used than kickstart is. Shouldn't we aim for the same goal (100% functionality) in GUI as well? I'm trying to illustrate the point that everything has to work sounds great but can't be achieved. And particularly anaconda is far from it - afaik they don't have much unit tests, any CI, etc. If we don't define a critical subset of core commands, then everything will have to be questioned all the time. Release criteria are a way to define a set which doesn't have to be questioned (much). Surely you don't want to block F18 release just because autostep [1] might be broken? Which brings me to another point. In kickstart there are commands which use a functionality we don't block the GUI on. For example there is a btrfs command, but until recenly btrfs wasn't displayed in Anaconda GUI and we didn't block the release on it. Other features are commands like multipath, driverdisk or zfcp (whatever on earth that is). Do you suppose we should block release on all these features, while we don't block on them using Anaconda GUI? We could word the criterion in such a way, that we require all kickstart commands to work except for those features we don't block even the GUI on. We could, but I'm afraid it's still a bit broad. My current pain point with release criteria is that we consider it all-or-nothing game - if it's in criteria it's a blocker, if it's not it's not. There a few exceptions, and a lot fudging when we need to cheat our own game (Adam is the guru here). I'd rather see criteria as recommendations - if it's not in the criteria, _you_ have to be very persuasive to illustrate why it should block the release; if it is in the criteria, _we_ have to be very persuasive to illustrate why it shouldn't block the release. If we understand the criteria this way, then I think these core kickstart commands are even more helpful. It your broken command is not among them, you might explain why this bug badly hurts a lot of people and it can be accepted, per-case. Or if you can promise you'll fix that bug within a few days, we can also block the release based on that fact. Currently our criteria interpretation doesn't allow for this flexible behavior. It's 1 or 0, blocker or non-blocker. (Hmm, this last paragraph might even deserve to be split into a separate thread.) [1] http://fedoraproject.org/wiki/Anaconda/Kickstart#autostep -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Fri, Dec 07, 2012 at 07:27:58AM -0500, Kamil Paral wrote: Which brings me to another point. In kickstart there are commands which use a functionality we don't block the GUI on. For example there is a btrfs command, but until recenly btrfs wasn't displayed in Anaconda GUI I've read but not memorized the criteria for the installer, but I think in general it's the case that things which are visible in the normal path in the installer must work. The current documentation for Kickstart effectively puts all commands into that category. It might be nice if they were sorted into critical and not-critical commands _and documented as such_, but I think that needs to happen *first*. (And I think you're on a reasonable track, by the way, and have obvious put some thought into it.) Initially I said that if commands need to change or go away, they should be marked deprecated for a release or two. Similarly, certain commands could be marked as Experimental (btrfs) or Unstable (autopart, say). Then, once that's done, the release criteria are easy. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Fri, 2012-12-07 at 13:11 -0500, Matthew Miller wrote: On Fri, Dec 07, 2012 at 07:27:58AM -0500, Kamil Paral wrote: Which brings me to another point. In kickstart there are commands which use a functionality we don't block the GUI on. For example there is a btrfs command, but until recenly btrfs wasn't displayed in Anaconda GUI I've read but not memorized the criteria for the installer, but I think in general it's the case that things which are visible in the normal path in the installer must work. The current documentation for Kickstart effectively puts all commands into that category. It might be nice if they were sorted into critical and not-critical commands _and documented as such_, but I think that needs to happen *first*. (And I think you're on a reasonable track, by the way, and have obvious put some thought into it.) Initially I said that if commands need to change or go away, they should be marked deprecated for a release or two. Similarly, certain commands could be marked as Experimental (btrfs) or Unstable (autopart, say). Then, once that's done, the release criteria are easy. That would be nice, but the fact is that we have to get releases done every six months, including supposedly one within the next two weeks, but we don't have any convenient guns to hold to the heads of the anaconda team to make them re-do the documentation. If we put in a criterion which says 'all documented kickstart commands must work' now, then we are committing to supporting them all for F18, unless someone magically re-does the kickstart documentation in the next two weeks, which doesn't appear likely to happen. We can't write a release validation process which works brilliantly so long as everyone else does things perfectly if everyone else is in fact _not_ doing things perfectly, because then it would lead to absurd results and there would be no trust in the process, and we'd go back to blocker-by-fiat. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Fri, Dec 07, 2012 at 11:08:27AM -0800, Adam Williamson wrote: Initially I said that if commands need to change or go away, they should be marked deprecated for a release or two. Similarly, certain commands could be marked as Experimental (btrfs) or Unstable (autopart, say). Then, once that's done, the release criteria are easy. That would be nice, but the fact is that we have to get releases done every six months, including supposedly one within the next two weeks, but we don't have any convenient guns to hold to the heads of the anaconda team to make them re-do the documentation. If we put in a criterion which says 'all documented kickstart commands must work' now, then we are committing to supporting them all for F18, unless someone magically re-does the kickstart documentation in the next two weeks, which doesn't appear likely to happen. I think it's definitely too late for F18, in a moving-goalposts kind of way. But, I still would rather the criteria for F19 to be all kickstart commands work, unless they're documented as experimental or unstable, and for F20 to be a step more strict. I think Kamil's actually done 90% of that work already, and I'm happy to work with everyone and the anaconda team to update the official kickstart documentation -- but I think there's enough going on right now that it's _best_ for that to wait until after the F18 release. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Wed, Dec 05, 2012 at 09:39:41PM -0800, Adam Williamson wrote: I think that may be the case _now_ with our current Anaconda situation, but the more I think about it, the more strongly I feel about making this the approach for future releases. When there's _not_ a big Anaconda rewrite, kickstart commands shouldn't change drastically without planning. So, I don't think it's unreasonable in the real world. The commands themselves shouldn't change, but it's certainly possible - and frequently happens - for something to change in anaconda or some layer below anaconda which happens to have the effect of breaking a kickstart directive. ... which should be a blocker. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Thu, 6 Dec 2012, Matthew Miller wrote: On Wed, Dec 05, 2012 at 09:39:41PM -0800, Adam Williamson wrote: I think that may be the case _now_ with our current Anaconda situation, but the more I think about it, the more strongly I feel about making this the approach for future releases. When there's _not_ a big Anaconda rewrite, kickstart commands shouldn't change drastically without planning. So, I don't think it's unreasonable in the real world. The commands themselves shouldn't change, but it's certainly possible - and frequently happens - for something to change in anaconda or some layer below anaconda which happens to have the effect of breaking a kickstart directive. ... which should be a blocker. I agree with Matt. Kickstart is not only a lowest common denominator it is a critical functionality for tons of our testing and deployment tools. We don't want revolutionary change in kickstart and we definitely cannot have it be broken. Slow, gradual change properly documented is critical for kickstart. I'm less concerned about changes in anaconda's UI if I know kickstart will continue functioning. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Thu, 2012-12-06 at 11:29 -0500, Seth Vidal wrote: On Thu, 6 Dec 2012, Matthew Miller wrote: On Wed, Dec 05, 2012 at 09:39:41PM -0800, Adam Williamson wrote: I think that may be the case _now_ with our current Anaconda situation, but the more I think about it, the more strongly I feel about making this the approach for future releases. When there's _not_ a big Anaconda rewrite, kickstart commands shouldn't change drastically without planning. So, I don't think it's unreasonable in the real world. The commands themselves shouldn't change, but it's certainly possible - and frequently happens - for something to change in anaconda or some layer below anaconda which happens to have the effect of breaking a kickstart directive. ... which should be a blocker. I agree with Matt. Kickstart is not only a lowest common denominator it is a critical functionality for tons of our testing and deployment tools. We don't want revolutionary change in kickstart and we definitely cannot have it be broken. Slow, gradual change properly documented is critical for kickstart. I'm less concerned about changes in anaconda's UI if I know kickstart will continue functioning. Do I see two volunteers to help fix kickstart bugs? :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Thu, Dec 6, 2012 at 7:41 PM, Adam Williamson awill...@redhat.com wrote: Do I see two volunteers to help fix kickstart bugs? :) If it came down to crunch time, and a kickstart bug was keeping us from being able to do a release, you bet I'd volunteer to help fix the kickstart bug. -- Jared Smith -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
From: Kamil Paral kpa...@redhat.com In the discussion about https://bugzilla.redhat.com/show_bug.cgi?id=869978 we agreed that we should have a list of core kickstart commands that should definitely work for a Final release. All the options are documented here: http://fedoraproject.org/wiki/Anaconda/Kickstart I tried to make a core selection. I had the following in mind: 1. Kickstarts are used for automation, therefore the most important commands related to automation must work (manual intervention is not fine). 2. Commands which are easily work-aroundable shouldn't be part of the core selection. Example: 'authconfig' kickstart command is just a wrapper around authconfig tool. You can issue the same command in %post and it should do the same. If %post works, it's trivial to work around nonfunctional authconfig kickstart command. The same applies for 'firewall', 'group', 'user' and others, it's trivial to run it in %post. 3. Some commands have plenty of options. We can't really define into the smallest detail which one of them must work and which doesn't have to. In this case a blocker-bug discussion is necessary to weight the importance of the option, its usage volume and the risk involved. I arrived at three different categories of the core set: == Setting up installation environment == network updates keyboard lang rootpw * 'network' and 'updates' are core commands, in same cases you really need them to start the installation. * 'keyboard' and 'lang' might probably be worked around in %pre, but it might be non-trivial for people. But I'm not firmly decided here. * 'rootpw' can be worked around in %post, but I consider it pretty basic command to work without problems == Partitioning the system == zerombr autopart clearpart part bootloader volgroup logvol * Partitioning is pretty major function of the installer and if doesn't work, it's just useless. I consider it core. * LVM support might be questioned. I decided to put it here, because LVM is the Fedora default and it might be pretty useful in some automated installation. We can discuss it though. * I haven't included some other partitioning commands, like 'btrfs', 'raid', or 'multipath'. They are useful and pretty, but I don't see them as really core. == Installation process == install upgrade repo %packages %pre %post poweroff reboot * 'install' and 'upgrade', because you need to be able to tell installer which mode to use * 'repo' because you need to set your mirror, or activate/deactive updates-testing, or something like that * '%packages' because package selection is one the core functions ofkickstart * '%pre' and '%post' because it is often needed for some post- install setups (setting up sshd, creating accounts etc) and also can be used to work around broken commands * 'poweroff' and 'reboot' because in an automated environment these might be very important for you. Rebooting a computer that is 1000 miles away from you might not be an easy task. It might be a bit difficult to put this into criteria, I think there is no other way except than list the core commands. We can't say everything related to partitioning, because then people would argue btrfs command is included. Maybe we can create a separate page/subpage related to kickstart core commands and just link to it from the criteria document. Comments very welcome. I make heavy use of the %include directive which I don't see that you've mentioned anywhere. It's a rather fundamental feature for how I use kickstarts through livecd-tools to effect dynamic sections. I suppose I could revise my tools to create a dynamic, yet monolith kickstart script, but at present I have everything tooled to around a core kickstart script, numerous static helpers that get %included and several dynamic helpers that are also %included. Thus I'd appreciate seeing %include added to the criteria, if it's not too much of a pain. FWIW it's presently working fine for me with my test box that was F17 originally and yum-upgraded to F18 shortly after the branch was made. This box is running my tool that runs livecd-tools to make custom live spins that I've been heavily testing and developing since the branch. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
I make heavy use of the %include directive which I don't see that you've mentioned anywhere. It's a rather fundamental feature for how I use kickstarts through livecd-tools to effect dynamic sections. I suppose I could revise my tools to create a dynamic, yet monolith kickstart script, but at present I have everything tooled to around a core kickstart script, numerous static helpers that get %included and several dynamic helpers that are also %included. Thus I'd appreciate seeing %include added to the criteria, if it's not too much of a pain. Thanks, that would mean including %ksappend as well (very similar, but different use cases). It's true that %include can be used to insert dynamic behavior into the kickstart based on the environment and the machine. Example: http://fedoraproject.org/wiki/Anaconda/Kickstart#Example Some of the functionality might be tricky to work around - you can generate several versions of your kickstarts, all static (without %include), but then you have to know which kickstarts to run on which machines, and it could defeat some points of automation. I'm not fully decided either way, maybe a bit in favor; I hope some people will comment here as well. Just keep in mind we want to keep the core command set small. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Wed, Dec 5, 2012 at 9:15 AM, Kamil Paral kpa...@redhat.com wrote: I'm not fully decided either way, maybe a bit in favor; I hope some people will comment here as well. Just keep in mind we want to keep the core command set small. I agree -- %include and %ksappend should be part of the core command set that's required to work for Final. -- Jared Smith -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Wed, Dec 05, 2012 at 08:22:52AM -0500, Kamil Paral wrote: I tried to make a core selection. I had the following in mind: 1. Kickstarts are used for automation, therefore the most important commands related to automation must work (manual intervention is not fine). 2. Commands which are easily work-aroundable shouldn't be part of the core selection. Example: 'authconfig' kickstart command is just a wrapper around authconfig tool. You can issue the same command in %post and it should do the same. If %post works, it's trivial to work around nonfunctional authconfig kickstart command. The same applies for 'firewall', 'group', 'user' and others, it's trivial to run it in %post. Having depended on kickstart for years, I'm of the very strong belief that while it's okay to have a subset for alpha and beta blockers, *all*documented commands should work for final unless they were marked as deprecated and gave warnings in a previous release. (Preferably two releases, since jumping one release is expected with our lifecycle.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Wed, Dec 05, 2012 at 08:22:52AM -0500, Kamil Paral wrote: I tried to make a core selection. I had the following in mind: 1. Kickstarts are used for automation, therefore the most important commands related to automation must work (manual intervention is not fine). 2. Commands which are easily work-aroundable shouldn't be part of the core selection. Example: 'authconfig' kickstart command is just a wrapper around authconfig tool. You can issue the same command in %post and it should do the same. If %post works, it's trivial to work around nonfunctional authconfig kickstart command. The same applies for 'firewall', 'group', 'user' and others, it's trivial to run it in %post. Having depended on kickstart for years, I'm of the very strong belief that while it's okay to have a subset for alpha and beta blockers, *all*documented commands should work for final unless they were marked as deprecated and gave warnings in a previous release. (Preferably two releases, since jumping one release is expected with our lifecycle.) I would prefer this as well, I'm just afraid it's not realistic. We now have months of delay and still dozens of accepted and proposed final blockers. If we demand something like that, we might not be able to release at all. Of course, in a better world, big thumb up. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Wed, Dec 05, 2012 at 09:54:45AM -0500, Kamil Paral wrote: *all* documented commands should work for final unless they were marked as deprecated and gave warnings in a previous release. (Preferably two releases, since jumping one release is expected with our lifecycle.) I would prefer this as well, I'm just afraid it's not realistic. We now have months of delay and still dozens of accepted and proposed final blockers. If we demand something like that, we might not be able to release at all. I guess I would settle for documented in the release notes as changed, but blockers otherwise. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On 12/05/2012 02:37 PM, Matthew Miller wrote: while it's okay to have a subset for alpha and beta blockers, *all*documented commands should work for final unless they were marked as deprecated and gave warnings in a previous release. (Preferably two releases, since jumping one release is expected with our lifecycle.) Agreed. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Wed, Dec 05, 2012 at 09:54:45AM -0500, Kamil Paral wrote: Having depended on kickstart for years, I'm of the very strong belief that while it's okay to have a subset for alpha and beta blockers, *all* documented commands should work for final unless they were marked as deprecated and gave warnings in a previous release. (Preferably two releases, since jumping one release is expected with our lifecycle.) I would prefer this as well, I'm just afraid it's not realistic. We now have months of delay and still dozens of accepted and proposed final blockers. If we demand something like that, we might not be able to release at all. I think that may be the case _now_ with our current Anaconda situation, but the more I think about it, the more strongly I feel about making this the approach for future releases. When there's _not_ a big Anaconda rewrite, kickstart commands shouldn't change drastically without planning. So, I don't think it's unreasonable in the real world. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
On Wed, 2012-12-05 at 12:13 -0500, Matthew Miller wrote: On Wed, Dec 05, 2012 at 09:54:45AM -0500, Kamil Paral wrote: Having depended on kickstart for years, I'm of the very strong belief that while it's okay to have a subset for alpha and beta blockers, *all* documented commands should work for final unless they were marked as deprecated and gave warnings in a previous release. (Preferably two releases, since jumping one release is expected with our lifecycle.) I would prefer this as well, I'm just afraid it's not realistic. We now have months of delay and still dozens of accepted and proposed final blockers. If we demand something like that, we might not be able to release at all. I think that may be the case _now_ with our current Anaconda situation, but the more I think about it, the more strongly I feel about making this the approach for future releases. When there's _not_ a big Anaconda rewrite, kickstart commands shouldn't change drastically without planning. So, I don't think it's unreasonable in the real world. The commands themselves shouldn't change, but it's certainly possible - and frequently happens - for something to change in anaconda or some layer below anaconda which happens to have the effect of breaking a kickstart directive. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
