[PATCH] Another batch of initial setup related patches
Martin Sivak
msivak at redhat.com
Thu Mar 14 13:47:32 UTC 2013
Hi,
the first two patches are quite simple and not at all special. However
the other two are something I had to do to, but it might not be the
best way with regards to anaconda future and maintenance.
3) This patch implements the feature Stef asked for his realmd addon
- he was affraid that customers will regard %addon section in kickstart
as something that is not really supported that well
- so he asked us to look into allowing the addons to define their own
"first class" kickstart command that will not be distinguishable from
the rest
- I see two issues with it. One is validation, and the second is that
when addon is missing, sections are gracefully saved and transfered to
the output kickstart without breaking anaconda. Unknown command raises
an exception.
- Regarding validation.. the whole kickstart addon implementation should
be moved to pykickstart so the validation tools can load the addons as
well.
4) The last patch is a bit hairy and wild. I needed a way to determine if
a spoke was completed in anaconda. Initial-setup loads the
/root/anaconda.ks.cfg file and the code here uses the completed
attribute of spokes. BUT! It does this in the loading phase where the
spokes are not initialized yet so some magic was needed.
Spokes marked for firstboot do not have any storage, instclass or
backend available (all set to None) so if we make it a requirement that
spokes which are to be shared with initial-setup must not use anything
else than self.data in completed property this will work well.
At least the functionality of 1, 2 and 4) has to go to F19 alpha. It can be
implemented differently though. So if you have any idea how to do it better
and cleaner, I would like to hear it.
Martin
More information about the anaconda-patches
mailing list