Bug 915158

Summary: [RFE] Feature request to allow kickstart to always point to the latest RHEL release
Product: [Community] Spacewalk Reporter: Stephen Herr <sherr>
Component: WebUIAssignee: Stephen Herr <sherr>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satellite-qa-list>
Severity: low Docs Contact:
Priority: low    
Version: 1.9CC: cperry, pbatkowski, tao
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: spacewalk-java-1.9.75-1 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 610782 Environment:
Last Closed: 2013-03-06 13:35:35 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 737830, 917805    

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
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.
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):
392516363f1cf1001bdef3b1e0f92cd1247dff0e
9bc62e8cc9c24595b7d431414e7b40f8fe20567d
b6b8d9dc3b00ce9695747c3ac072921c1d32de47
5e861200d958b9e33b46fa0093de886590377f99
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.

https://fedorahosted.org/spacewalk/wiki/ReleaseNotes19