[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