[yocto] Need for offline binary configuration

[Mark Hatle]

On 11/29/12 5:09 AM, Venkata ramana gollamudi wrote:
> Added few more thoughts
> Looking for possible options to implement Offline Configuration Tool requirement. please check and comment on it.
>
> Configuration flow:
>
> a) Task do_createconfig will generate data to configure. This serves as input for configuration UI in OCT.

Using tasks to control the configuration elements will require the build system 
and recipes.  This is really good for the existing workflow, but doesn't help 
with the blessed binaries situation.

What I'd love to see (but don't expect) is a way for the binary packages to 
document he configuration files and options in a way that the UI can load this 
information, give the user simple check-box/drop down style configuration -- or 
simply a text editor with the end result something that gets back to the target 
environment.

> b) OCT UI will read that config data(from step(a)) to show it in GUI. User configures using GUI inputs. Stores the user OCT configuration to OCT config file. (Note user can directly modify the OCT config file, if User is familier with it)
>
> c) preinst, postinst, prerm, postrm, or a do_applyconfig(without bb files reparse), can read OCT config file content (using a library) and apply necessary changes.

I'm not sure pre/post is the right place to do these changes.  Typically I've 
seen the default configuration files marked as such within the package system 
and then the modifications are made externally.  Sometimes they're made in 
ancillary packages or just made raw on the disk.  Most package management 
systems I'm aware of can handle this just fine.

My concern with modifying the defaults is that the feed become project specific, 
and again it requires input during the build process as opposed to the install 
process.

> Now we can look into possibility of using a specific configuration UI implementation or a generic configuration model or combination of both.
>
> 1) Using a specific configuration GUI implementation:
>     do_createconfig generates the configuration information, in format like datafile/xml and OCT reads this config data and provides a GUI to modify or configure the features.
>
> Pros: Detailed and complex GUIs can be supported which will be user friendly. Ex: User management, network management etc.
> Cons: As UI is static, it has to be modified to support new configuration requirements
> and UI modifications are generally complex.

Having something like a do_createconfig (or even a do_describeconfig) to 
generate a file that is later made available to the UI tool is my suggestion. 
Then the input/output of the tool ends up in the rootfs directly.  (The methods 
to get to the rootfs should be either a specific path, a URL for get/put 
operations, or a method like tcf/ssh to copy the item to a running target.

Either a custom per-package model or a generic model may be needed.  I don't 
know what the best approach is -- however I know previous attempts to do this 
have generally resulted in more 'custom' model then generic + config file model.

But in general there seem to be three main types of configuration files that 
I've seen:

Column/format based -- i.e. /etc/fstab, /etc/exports
Key/Value based -- things like Key=Value, or Key:\nValue, etc..
XML-like -- Highly formatted configuration files like apache.

--Mark

> 2) A generic configuration model
>     do_createconfig generates configuration information with presentation information included (like kconfig) and OCT reads this config information and provides a generic UI implementation to modify or config the data like menuconfig.
>
> Pros:
> 	- Generic and dynamic UI allowing the config menus to be added from poky layers providing platform for configuration.
> 	- New features can add new menus configuration options. Feature/package enable and disable can control the configurtion menus.
> 	- So configuration is shown only if feature/package is present/selected.
> Cons:
> 	- Generic method of implementing can be complex, specifically for features where configuration is complex ex: User management, network configuration.
> 	- Custom or specific UI will be more user friendly and gives more control to UI designer.
>
> 3) Combination of both
> Complex features requiring more UI control can implement those features using the method(1) and also providing the plaform for generic UI implementation.
> OCT displays both UI configurations.
> Ex: Static Image level features like User management, network config can be implemented using method(1)
>      Service configuration, file system type, hist size configure etc can be implemented using method(2).
>
> Pros: Gives control to project to select the Complex and simple UIs.
>
> Cons: Still needs a OCT UI change if method(1) feature need to be changed.
>        Drawing a line between complex and simple UI features may not very straight forward.
>        Adding dynamic Complex UI is not possible to be added from poky layers.
>
> Decision to provide a generic configuration model is mainly based on how much we expect the configuration area to grow along with layers.
> Image level features like user management, network management generally are not dynamic features, so having a specific/custom UI implementation looks fine for such features.
>
> Regards,
> Ramana
>