Hi Not really sure what you're saying here. My intent is to do versioning of the kickstart profile by logging changes to the KS profile (package adds/removes, partitioning changes, script changes, etc) into the DB.
Now that I think about it, it might make more sense to have a seperate table with columns of ks_id, change_id, description and date. That way you could get all the changes for a KS profile if you wanted of all changes within a date range. I'd also meant to state that currently I store the changelog manually at the top of the KS post script but this is painful and requires all people modifying the KS profile to do the same but experience has shown this not to be the case. CC ________________________________________ From: [email protected] [[email protected]] On Behalf Of [email protected] [[email protected]] Sent: Wednesday, 7 January 2009 6:54 PM To: [email protected] Subject: RE: [Spacewalk-devel] RFC: Automatic kickstart profile changelogging Hi, >I'd like to try and implement automatic changelogging of kickstart profiles. >I want to do this as I'm required by my employer to show how >the 'build >process' changes with respect to our RHEL technical workstations and cluster >nodes (230+ nodes all up). > >I figure that I'd add two new columns to table 'rhnKSData' being: >- 'changeLog' (type blob); and >- 'changeVersion' (type number). > >When a new kickstart profile is created a note to that effect is stored in >changeLog with a date/time stamp. Whenever the kickstart profile >is updated, >a description of the change is written to changeLog. > >The purpose of this email is to find out if anyone is already working on >something like this or if there are any objections. I don't have any objections but it does sound only a step away from versioning the kickstarts or changes. For me personally that would be first price. I would rather have "change comments" as part of the change then stored separately. Maybe long term we could have a versioning plug-in that facilitates storing versioned information of kickstarts/scripts(anything else relevant). You could still keep the version in the database as "authoritave" and show versions if available, that way if your underlying svn, git, whatever breaks it does not break spacewalk. Regards ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments. _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
