+++ This bug was initially created as a clone of Bug #610782 +++ Customer has to update kickstart profiles manually when each minor version of RHEL got released. So customer looking for this feature that kickstart distribution tree always point to latest minor release with base distribution. --- Additional comment from Stephen Herr on 2013-02-22 15:30:46 EST --- Notes to QA: Work for this bug touched a lot of different places, so I'll try to give an overview of the testing necessary. First of all, when you create a kickstart profile through the wizard or edit the OS of an existing profile, there should now be options available to always use the newest [gerneral, Red Hat] tree. The option for newest Red Hat tree will only appear if the base channel you have selected currently has Red Hat trees available. If you select newest Red Hat tree, it should only ever use ks trees that were synced from Red Hat, whereas the other option allows user-added ks trees (or "distributions") to be set. "Newest" is determined by the last_modified date for the ks tree. The above does not apply for kickstart profiles that were created the "advanced" way, i.e. by directly uploading a ks file. In that case we don't know what ks trees would be applicable, so we can't automatically keep it updated. The kickstart profile api methods should all be updated to have a new field that allows people to set the updating behavior, with appropriately updated documentation. For backwards-compatibility the old methods without that additional field still exist, update_type defaults to "none", meaning that the ks tree they set will continue to be the ks tree for that profile until they manually change it. Any time you manually change the update type manually the newest kickstart tree should be calculated and saved both in the Satellite DB (and so it will appear in the web UI) and to Cobbler (which you can examine using 'cobbler profile dumpvars --name <name>'). You should also test the ability to automatically update to the newest ks tree after a sat-sync or new distribution is created. In either case the ks tree for the profile should be updated in both the Satellite DB and Cobbler the next time the Cobbler-sync taskomatic task runs, by default once a minute. Testing a new user-created ks tree is easy enough, just set the appropriate option on the kickstart profile and create a new "distribution" that registers to the same base channel as the kickstart profile. A minute later everything should be updated. Simulating a Red Hat distribution release is slightly harder. The best way I've found to simulating a new Red Hat ks tree being released is to: 1) set the profile to no update strategy and an older Red Hat ks tree 2) manually update the rhnksdata field update_type to 'red_hat' for that profile. 3) wait for taskomatic to run This should approximate the update_type already being set and a new ks tree being released. --- Additional comment from Stephen Herr on 2013-02-25 00:54:04 EST --- Update to above comment: It is perfectly possible to allow an advanced kickstart profile to update the kickstart tree, but the user must select a kickstart tree to start with. So for the "advanced" kickstart profiles, the user must select both a kickstart tree and an update method (optional). Then the kickstart trees will update automatically, staying on the same base channel as the original kickstart tree.
Committed to Spacewalk master: d2d3ad28da4edb7644ff9c7a7725d38dc678a004
Also needed (some small issues fixed): 392516363f1cf1001bdef3b1e0f92cd1247dff0e 9bc62e8cc9c24595b7d431414e7b40f8fe20567d b6b8d9dc3b00ce9695747c3ac072921c1d32de47 5e861200d958b9e33b46fa0093de886590377f99
Marking bug as ON_QA since tonight's build of Spacewalk nightly is a release candidate for Spacewalk 1.9.
Spacewalk 1.9 has been released. https://fedorahosted.org/spacewalk/wiki/ReleaseNotes19