A build appliance that is a container image will be much smaller and more likely to be used by the most popular tools. For instance we could build a container that contains the "build descriptor" consumer script on top of a "build appliance container image." Or it can be used for the current crops/yocto containers on dockerhub that currently are based around standard distros that might be larger than desired.
Reassigning to Brian since he wants to leverage the existing crops containers.
AFAIK, the remaining functionality missing from the CROPS/container et al family is the ability to run qemu with a graphical display.
RFC sent out . Awaiting feedback.
Mail sent to open embedded architecture list. Several questions came up and were answered/pointed to bugs that are being worked on. ML reference: http://lists.openembedded.org/pipermail/openembedded-architecture/2016-December/000348.html
We have agreed that the containers serve a different purpose from the Build Appliance. The containers provide a lightweight way to use the YP. The Build Appliance is a complete image dogfooding test which verifies we can rebuild an image from an image we created. Because of this, we are keeping both the Build Appliance and the containers so I am marking this as resolved/obsolete as we chose not to go down the path of deprecating the Build Appliance.