Hi Jan,

On Mar 11, 2010, at 3:48 AM, Jan Damborsky wrote:

> On 03/10/10 08:58 PM, Alok Aggarwal wrote:
>> Hi Sarah,
>>
>> On Tue, 9 Mar 2010, Sarah Jelinek wrote:
>>
>>> So, a few things I wanted to comment on with regard to this:
>>>
>>> -system configuration is system configuration. Yes, this is  
>>> technically an administrative task, but applying system  
>>> configuration to a booted microroot, that is applying  
>>> configuration that does not require reboot such as network setup,  
>>> is the same as applying it to a live system, imo.
>>>
>>> -Asking the user to type in a command in a shell or terminal  
>>> window seems like not a great user experience to me. Having them  
>>> utilize the front end we provide via our installers and having  
>>> the configuration apply to the booted environment if the user  
>>> chooses seems like a better user experience.
>>>
>>> -We do some 'configuration' up front now, and apply it to the  
>>> booted install environment, such as keyboard and language. Why  
>>> would this be different for something like networking. We don't  
>>> ask the user to open a shell and type in a command to do this, we  
>>> mask it behind screens.
>>>
>>> For me, applying system configuration should be the same, if at  
>>> all possible, in all environments. Applying a network  
>>> configuration via SMF and having the network service apply that  
>>> in the microroot seems reasonable to me.
>>
>> Those are actually all very valid points. So I agree with
>> you that at this point we shouldn't rule out the installers  
>> (interactive or AI), needing to change the network configuration
>> in the installation environment in addition to the install
>> target.
>>
>> In terms of this functionality having a requirement on the sysconfig
>> proposal - I don't there needs to be one. Sysconfig should just
>> be able to apply the configuration in the installation environment
>> similar to how it would do in the install target. That is, in
>> both instances it will just deliver the eSMF profile in the
>> appropriate place and kick the respective SMF component(s) to
>> effect the changes.
>>
>> However, it does bring about a requirement on the network
>> configuration services in that they need to be able to deal
>> with changing the network configuration on a running system.
>>
>> Jan, is that something you can bring up with the networking
>> team as you're working with them on network configuration?
>
> Sure, I will bring this point during following discussions.

Thanks for doing that.

Alok

Reply via email to