I am not against considering going through ifcfg -> ksdata -> ifcfg[3], be it for consistency with other spokes/modules. or we may come to point where we actually need to do it. It will require some thinking though.
Yeah, I can understand why you're hesitant to do this. Keeping things in sync between the config files and ksdata is tough here. And I can't think of anywhere else in anaconda where the primary data store is really outside our control.
One other point to consider here is that if we don't have networking going through ksdata, then no networking lines will end up in anaconda-ks.cfg. This also means that using the new anaconda as a s-c-ks front end will be more difficult.
Is there at least some way ifcfg file data can be mirrored to ksdata at the very end, when networking stuff can no longer change?
@@ -78,6 +79,8 @@ def doInstall(storage, payload, ksdata, instClass): ksdata.services.execute(storage, ksdata, instClass) ksdata.keyboard.execute(storage, ksdata, instClass)
- writeNetworkConf(storage, instClass)
- # Creating users and groups requires some pre-configuration. u = Users() createLuserConf(ROOT_PATH, algoname=u.getPassAlgo(ksdata.authconfig.authconfig))
I'd like writeNetworkConfig to still take a ksdata object as a second argument for parallelism with the execute methods, just in case I want to do some reworking here later.
- Chris