RFC BuildAppliance future

RFC BuildAppliance future

[Brian Avery]

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

  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!

Thanks in advance for any feedback,

-Brian

an Intel Employee

[-- Attachment #2: Type: text/html, Size: 3160 bytes --]

Re: [Openembedded-architecture] RFC BuildAppliance future

[Mark Hatle]

On 12/5/16 12:04 PM, Brian Avery 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.

What are the requirements for a Windows user to use this, instead of the VM
approach.  (In the past it was easy for a Windows user to get the VM, and just
run it to test out things.)

--Mark

>   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!
> 
> 
Thanks in advance for any feedback,
> 
> -Brian
> 
> an Intel Employee
> 
> 
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 

Re: [Openembedded-architecture] RFC BuildAppliance future

[Khem Raj]

On Mon, Dec 5, 2016 at 10:04 AM, Brian Avery <avery.brian@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>

Re: [Openembedded-architecture] RFC BuildAppliance future

[Brian Avery]

[-- Attachment #1: Type: text/plain, Size: 5794 bytes --]

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@gmail.com> wrote:

> On Mon, Dec 5, 2016 at 10:04 AM, Brian Avery <avery.brian@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@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> >
>

[-- Attachment #2: Type: text/html, Size: 9231 bytes --]