[yocto] Need for offline binary configuration

[Venkata ramana gollamudi]

Poky allows to build custom Linux for you, but we have cases where the post build customization is required, like user-addition, network configuration, service control. Even selecting the required packages can be a post build activity.

The current model requires the image to be rebuilt to support these configuration.
Offline Configuration tool (OCT), which allows a binary image customization before making a final target image. This case will be more evident in larger companies, where platform teams, product teams , application teams are distributed and Linux build from source will be owned and lab tested by a single team, like platform team. Other teams just configure to use it for product variants from same platform build.

Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated from poky.

The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages into final target image.
b) Provision to select external binary packages like ADT compiled applications as input and add them to final target image.
c) Binary level Offline configuration can includes 
      Configure the users/passwords
      Configure the network 
      Configure the host name 
      Select the services to be started by default
      Security related configuration
      Generate initrd in ramfs/ext3/... format
      etc..

Considering the methods to support these in our current yocto model, following changes can be done.
1) HOB can be the tool which can be extended to support these
    Poky can generate a binary package pool as one if its output and Hob can work on this package pool to select packages, configure and generate image.
So HOB can support opening HOB in Binary(or OCT) mode i.e., without build options but only with binary package selection. Configuration GUI needs to be added to HOB.
Note:HOB+OCT is together or separate, needs a bit more thought and overall organization as they will be intended for different users. 
2) Binary package pool can be a minimal/partial sstate-cache, as complete sstate-cache is quite big and not required for product teams as they are not expected to build but just need to select and configure.
    I think it is sufficient to keep the minimal binaries from sstate-cache which are required to execute image.bbclass, do_rootfs task to generate image. 
3) Along with specific configuration UI implementation, a generic configuration model similar to kernel kconfig and menuconfig can be considered, in cases where more detailed offline configurations is required like detailed security configuration.

Regards,
Ramana