Bug 504049 - Reprovisioning ignores kickstart's associated activation keys
Reprovisioning ignores kickstart's associated activation keys
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Provisioning (Show other bugs)
530
All Linux
low Severity medium
: ---
: ---
Assigned To: Justin Sherrill
Dave Parker
: Regression
Depends On:
Blocks: 457075
  Show dependency treegraph
 
Reported: 2009-06-03 19:07 EDT by Justin Sherrill
Modified: 2009-09-10 15:26 EDT (History)
2 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 15:26:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Justin Sherrill 2009-06-03 19:07:51 EDT
If you create a kickstart file and associate one or more activation keys they will not be used if you reprovision a machine using that kickstart.

The reason is that we associate the keys to the cobbler profile but at provisioning time set the key in the system record to the system's reactivation token. 

So when the kickstart is rendered for the system it just uses that reactivation key and not any of the profile's activation keys. 



We have to do 2 things:

1.  When scheduling a kickstart, set the system record's key to include both the reactivation token and the kickstart's keys.
2.  When modifying a kickstart's activation key selections, you have to modify any associated system records to include the new key and remove any old ones. fun :/
Comment 1 Justin Sherrill 2009-06-05 15:26:09 EDT
e79579a


So there are 4 places where things have changed.

1.  Clicking the "Create cobbler system record" (this ties a profile with a system)
2.  Deleting an activation key that is associated to a kickstart profile (That has been associated to a system)
3.  renaming an activation key that  is associated to a kickstart profile (That has been associated to a system)
4.  adding or removing an activation key from a kickstart profile that is associated to a system

doing all of these should result in the "redhat mgmt key" within the cobbler profile or system record objects being updated correctly.
Comment 2 Steve Salevan 2009-07-06 16:38:46 EDT
FAILS_QA on 7/2 build.

Created an activation key which would register a machine to a cloned base channel and associated it to a kickstart.  Scheduled kickstart, and after kickstart completion, this key was ignored and the machine was registered to the normal, non-cloned channel.
Comment 3 Justin Sherrill 2009-07-08 12:01:50 EDT
So I wasn't able to reproduce the error.  I created an activation key with a custom base channel, assigned it to a kickstart, then re-provisioned a machine with it.  

After it registered, it was registered to a different base channel.
Comment 4 Dave Parker 2009-07-21 19:35:30 EDT
I kickstarted a box to a normal base channel, then created a clone of that base channel and associated it with a new activation key -- which I in turn associated with a kickstart profile (the same one I initially kickstarted the box with).  Subsequent to kickstart the machine appears to be registered to the cloned base channel.
Comment 5 Preethi Thomas 2009-08-04 14:03:51 EDT
Release Pending
test1182.test.redhat.com
Comment 6 Brandon Perkins 2009-09-10 15:26:11 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html

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