[OE-core] [Openembedded-architecture] RFC BuildAppliance future

[Brian Avery]

Excellent Questions!



Dogfooding – Good point.  The
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9502 bug is intended to
address that. With this, we can build and test container images just as we
can do with the Build Appliance. As an added win, those folks building
Busybox based minimal sized containers would have a different way to do
that...



OS availability: Docker is available for Windows, Mac, and Linux.  Were
there fears about specific Linux distributions?



It does not seem to be too much harder to try Docker on Windows than it was
to try Virtualbox.  That being said, Docker is moving/changing more quickly
so it may have more bumps in the road but more features too…



Windows explained more in depth or one of those bumps…:

  The answer is a little complicated, so please bear with me.  There are 2
different versions of Docker for Windows.  The original version is known as
“Docker Toolbox” https://www.docker.com/products/docker-toolbox.  This is
basically Docker running in a minimal VirtualBox Linux VM.  They made a
separate host binary called docker-machine to help manage the images. This
is, in my opinion, a little clunky and does add some complexity when
switching from Docker running on Linux to Docker Toolbox running on
Windows. The clunkiness is largely due to the VirtualBox VM being “between”
the host and the Docker Engine. This version is targeted to people whose
Windows version does not meet the requirements specified below.



  If you have 64bit Windows 10 Pro, Enterprise and Education (1511 November
update, Build 10586 or later) and Microsoft Hyper-V, then you can download
“Docker for Windows” https://docs.docker.com/docker-for-windows/.  This is
a Docker implementation for Windows that relies on Hyper-V and a much
smaller vm.  It is also better integrated into the host environment so that
the discontinuity between the host side and the Docker  Engine is no longer
as jarring.  For example, you get a disk tray icon for Docker, can set up
http proxies for it, can manage how much memory and how many cpus it will
get…


This (https://docs.docker.com/docker-for-mac/docker-toolbox/) is nice page
that addresses the difference between the newer hypervisor approach and the
older "Docker Toolbox aka VirtualBox" approach.  The page is discussing it
from a Mac perspective but if you replace xhyve with Windows 10 Hyper-V,
the page is relevant to Windows as well.



The Mac implementation is functionally equivalent to “Docker for Windows”
and is called “Docker for Mac”
https://docs.docker.com/engine/installation/mac/.  It runs on a modified
xhyve hypervisor.



The Linux implementation runs as a container and uses the same kernel as
the host.



Thanks for the feedback and if I missed or shortchanged something please
let me know,

-Brian


an intel employee

On Mon, Dec 5, 2016 at 10:42 AM, Khem Raj <raj.khem at gmail.com> wrote:

> On Mon, Dec 5, 2016 at 10:04 AM, Brian Avery <avery.brian at gmail.com>
> wrote:
> >   Please note, this is going out to 3 lists in an attempt to insure that
> no
> > one who would be impacted by this change misses it. Implied spam apology
> > included.
> >
> >   The Yocto Project currently provides a virtual machine image called the
> > Build Appliance
> > (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-
> appliance/).
> > This image can be run using either VirtualBox or VMware. It enables you
> to
> > build and boot a custom embedded Linux image with the Yocto Project on a
> > non-Linux development system.  It is not intended for day to day
> development
> > use, but instead, is intended to allow users to “try out” the tools even
> if
> > they do not have access to a Linux system.
> >
> >   We are considering replacing the VM based Build Appliance with a set of
> > containers (https://hub.docker.com/r/crops/poky/, or if you want a user
> > interface (https://hub.docker.com/r/crops/toaster-master/ ).  These
> > containers currently provide most of the functionality of the Build
> > Appliance and should shortly be at feature parity with the Build
> Appliance.
> > We are actively adding to and supporting the containers as some of our
> > developers are using them in their day to day development in order to
> > benefit from the host isolation and ease with which other distributions
> can
> > be tested.
> >
> >   This is an RFC to see what features in the Build Appliance are
> important
> > to you but would not be provided by the container solutions.  If the
> > community would be just as content using the container approach as using
> the
> > VM based Build Appliance image, then we’d be better off deprecating the
> > Build Appliance and applying those resources elsewhere.  If there are
> > important features the Build Appliance provides which the container
> solution
> > does not, or cannot provide, we’d love to hear what they are!
>
> Personally, I dont use build appliance but I think using containers is a
> good
> step forward, provided, we can address all build host OSes that
> virtual appliance
> could.
>
> Build appliance is also a sort of "eat your own dog-food" for ensuring
> that we
> are doing ok on preparing cloud images for deployment. Hopefully we wont
> lose that testing, may be we can add another image to cover that.
>
> >
> > Thanks in advance for any feedback,
> >
> > -Brian
> >
> > an Intel Employee
> >
> >
> > _______________________________________________
> > Openembedded-architecture mailing list
> > Openembedded-architecture at lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161205/8433a891/attachment-0002.html>