[PATCH 1/4] networking: write configuration in doInstall

Radek Vykydal rvykydal at redhat.com
Thu Aug 2 15:01:26 UTC 2012


On 07/27/2012 05:44 PM, Chris Lumens wrote:
>> 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.
>

We are actually updating ksdata from ifcfg files in NetworkSpoke.apply,
I am just not using them in the patchset.

> 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?
>

We can use what we do in NetworkSpoke.apply in writeNetworkConf,
but given what the post installation changes are:

     instClass.setNetworkOnbootDefault()
     disableNMForStorageDevices(storage)
     autostartFCoEDevices(storage)

which is only setting ONBOOT and NM_CONTROLLED values
(we don't have counterpart in ksdata for the latter), I'd rather just
update ksdata created in spoke.apply in the methods above
(keeping all the tweaking in one place) instead of filling the whole
ksdata here - at the end of installation.


>> @@ -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.
>

Yep, I am adding it in 3/4.



More information about the anaconda-patches mailing list