Bug 915158 - [RFE] Feature request to allow kickstart to always point to the latest RHEL release
[RFE] Feature request to allow kickstart to always point to the latest RHEL r...
Product: Spacewalk
Classification: Community
Component: WebUI (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Stephen Herr
Red Hat Satellite QA List
: FutureFeature, Triaged
Depends On:
Blocks: spacewalk-rfe space19
  Show dependency treegraph
Reported: 2013-02-25 00:55 EST by Stephen Herr
Modified: 2013-03-21 07:23 EDT (History)
3 users (show)

See Also:
Fixed In Version: spacewalk-java-1.9.75-1
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 610782
Last Closed: 2013-03-06 13:35:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Herr 2013-02-25 00:55:28 EST
+++ 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

--- 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.
Comment 1 Stephen Herr 2013-02-25 01:00:15 EST
Committed to Spacewalk master: d2d3ad28da4edb7644ff9c7a7725d38dc678a004
Comment 2 Stephen Herr 2013-02-25 08:46:35 EST
Also needed (some small issues fixed):
Comment 3 Stephen Herr 2013-03-01 12:07:55 EST
Marking bug as ON_QA since tonight's build of Spacewalk nightly is a release candidate for Spacewalk 1.9.
Comment 4 Stephen Herr 2013-03-06 13:35:35 EST
Spacewalk 1.9 has been released.


Note You need to log in before you can comment on or make changes to this bug.