-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/14/2015 04:28 PM, Nico Kadel-Garcia wrote:
On Wed, Jan 14, 2015 at 9:27 AM, Dries Verachtert dries.verachtert@dries.eu wrote:
On Sat, Jan 10, 2015 at 4:18 PM, Jim Perrin jperrin@centos.org wrote:
On 01/09/2015 06:27 PM, Karanbir Singh wrote:
the problem is - the scope of this would be large enough that anyone can manage it, and everyone can get involved. But I dont want to do this as a part of the Core effort, that closes too many doors. But the SIGs are too specialised in their outlook to curate something of this nature.
The only group in a suiteable place to perhaps take ownership of a resource like that would be the docs group - so we do a community contributed setup there, and the build services retail their own metadata ( which is what the atomic / docker / cloud stuff is ) as and when and where they need it.
That sounds reasonable. Who from the community would like to lead this effort?
Hello,
I would like to help with this. Editing & testing kickstart files can be time consuming trial and error and some nice samples for various setups could be very useful for quite some people I think.
Kind regards, Dries
If you're going this route, can I beg you to put in this? I've asked the anaconda developers for this before, and it's invaluable for getting your actual ks.cfg saved for reference, rather than that wildly distinct and script discarding 'anaconda-ks.cfg'.
%post --nochroot cp -a /tmp/ks.cfg /mnt/sysimage/root/ks.cfg %end
This kind of thing makes me think, metadata around each kickstart is crucial to this. We can't just have a raw .ks file, unless it's as well documented (#commented) as a Tom Callaway tutorial example.
What I mean is, we need a way to track your comment about why that bit is invaluable for which situations, and how/where it's useful in what sort of kickstart files.
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41