<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Thanks Devdatta/Maxime for your comments.</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>I am definitely not rigid about implementing the workflow in Nova
      and it's well known that there can be multiple integration points
      for this work including that in docker itself. However, there are
      two prime reasons why we chose Nova as integration point in
      OpenStack:<br>
      <br>
      1. Minimal changes to a VM boot workflow. No need to depend on
      Swift or any other service. <br>
      2. Faster boot up times - since the downloading of the virtual
      machine image is negated. Downloading the docker filesystems
      should be more or less easier.</p>
    <p><br>
    </p>
    <p>Some comments inline.</p>
    <p><br>
    </p>
    <p>Thanks,</p>
    <p>Sudipto<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 27/07/16 11:59 PM, Maxime Belanger
      wrote:<br>
    </div>
    <blockquote
cite="mid:BY1PR0701MB1381F335D1E6673C3D8C9457D70F0@BY1PR0701MB1381.namprd07.prod.outlook.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="Microsoft Exchange Server">
      <!-- converted from text -->
      <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
      <meta content="text/html; charset=UTF-8">
      <style type="text/css" style="">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
      <div dir="ltr">
        <div id="x_divtagdefaultwrapper" style="font-size:12pt;
          color:#000000; background-color:#FFFFFF;
          font-family:Calibri,Arial,Helvetica,sans-serif">
          <p>+1 on this,</p>
          <p><br>
          </p>
          <p>Still you loose all the great stuff about the containers
            but it is a first step towards native container
            orchestration platform.</p>
        </div>
      </div>
    </blockquote>
    IMHO, it is not about just losing stuff. We are not emulating a
    docker workflow. The expectation is to have the ability to run a
    container inside a virtual machine and then take that filesystem out
    and run it natively on the hardware as desired. You can debate on
    whether it's really needed in Nova or elsewhere and I think that's a
    fair debate. <br>
    <br>
    I am sure there are further technical challenges to overcome, if we
    want to think in this direction.<br>
    <blockquote
cite="mid:BY1PR0701MB1381F335D1E6673C3D8C9457D70F0@BY1PR0701MB1381.namprd07.prod.outlook.com"
      type="cite">
      <div dir="ltr">
        <div id="x_divtagdefaultwrapper" style="font-size:12pt;
          color:#000000; background-color:#FFFFFF;
          font-family:Calibri,Arial,Helvetica,sans-serif">
        </div>
        <hr tabindex="-1" style="display:inline-block; width:98%">
        <div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
            face="Calibri, sans-serif" color="#000000"><b>From:</b>
            Devdatta Kulkarni <a class="moz-txt-link-rfc2396E" href="mailto:devdatta.kulkarni@RACKSPACE.COM"><devdatta.kulkarni@RACKSPACE.COM></a><br>
            <b>Sent:</b> July 27, 2016 12:21:30 PM<br>
            <b>To:</b> OpenStack Development Mailing List (not for usage
            questions)<br>
            <b>Subject:</b> Re: [openstack-dev] [nova][rfc] Booting
            docker images using nova libvirt</font>
          <div> </div>
        </div>
      </div>
      <font size="2"><span style="font-size:10pt;">
          <div class="PlainText">Hi Sudipta,<br>
            <br>
            There is another approach you can consider which does not
            need any changes to Nova.<br>
            <br>
            The approach works as follows:<br>
            - Save the container image tar in Swift<br>
            - Generate a Swift tempURL for the container file<br>
            - Boot Nova vm and pass instructions for following steps
            through cloud init / user data<br>
              - download the container file from Swift (wget)<br>
          </div>
        </span></font></blockquote>
    <font size="2">I believe this has to be carried out for every docker
      image? That is if i have a nginx image and it's provisioned twice,
      a fresh copy of such has to be wget'ed every time? IF the nova
      workflow is acceptable, then there can be optimizations thought
      around this. At this moment, my implementation copies the cached
      image for each of the containers - atleast making further boots
      faster.<br>
      Also, how do you tackle the problem with snapshoting a container?<br>
    </font>
    <blockquote
cite="mid:BY1PR0701MB1381F335D1E6673C3D8C9457D70F0@BY1PR0701MB1381.namprd07.prod.outlook.com"
      type="cite"><font size="2"><span style="font-size:10pt;">
          <div class="PlainText">
              - load it (docker load)<br>
              - run it (docker run)<br>
          </div>
        </span></font></blockquote>
    <font size="2">Do you run the docker native commands inside the
      virtual machine? In such a case, do you actually install docker<br>
      as a part of the cloud-init scripts? Do you have numbers w.r.t the
      boot time of the container image in this case?<br>
    </font>
    <blockquote
cite="mid:BY1PR0701MB1381F335D1E6673C3D8C9457D70F0@BY1PR0701MB1381.namprd07.prod.outlook.com"
      type="cite"><font size="2"><span style="font-size:10pt;">
          <div class="PlainText">
            We have implemented this approach in Solum (where we use
            Heat for deploying a VM and<br>
            then run application container on it  by providing above
            instructions through user_data of the HOT).<br>
            <br>
            Thanks,<br>
            Devdatta<br>
            <br>
            <br>
            -----<br>
            <br>
            <br>
            From: Sudipta Biswas <a class="moz-txt-link-rfc2396E" href="mailto:sbiswas7@linux.vnet.ibm.com"><sbiswas7@linux.vnet.ibm.com></a><br>
            Sent: Wednesday, July 27, 2016 9:17 AM<br>
            To: OpenStack Development Mailing List (not for usage
            questions)<br>
            Subject: [openstack-dev] [nova][rfc] Booting docker images
            using nova libvirt<br>
              <br>
            Premise:<br>
            <br>
            While working with customers, we have realized:<br>
            <br>
            - They want to use containers but are wary of using the same
            host kernel for multiple containers.<br>
            - They already have a significant investment (including
            skills) in OpenStack's Virtual Machine workflow and would
            like to re-use it as much as possible.<br>
            - They are very interested in using docker images.<br>
            <br>
            There are some existing approaches like Hyper, Secure
            Containers workflows which already tries to address the
            first point. But we wanted to arrive at an approach that
            addresses all the above three in context of OpenStack Nova
            with minimalist changes.<br>
            <br>
            <br>
            Design Considerations:<br>
            <br>
            We tried a few experiments with the present libvirt driver
            in nova to accomplish a work flow to deploy containers
            inside virtual machines in OpenStack via Nova.<br>
            <br>
            The fundamental premise of our approach is to run a single
            container encapsulated in a single VM. This VM image just
            has a bare minimum operating system required to run it.<br>
            The container filesystem comes from the docker image.<br>
            <br>
            We would like to get the feedback on the below approaches
            from the community before proposing this as a spec or
            blueprint.<br>
            <br>
            <br>
            Approach 1<br>
            <br>
            User workflow:<br>
            <br>
            1. The docker image is obtained in the form of a tar file.<br>
            2. Upload this tar file in glance. This support is already
            there in glance were a container-type of docker is
            supported.<br>
            3. Use this image along with nova libvirt driver to deploy a
            virtual machine.<br>
            <br>
            Following are some of the changes to the OpenStack code that
            implements this approach:<br>
            <br>
            1. Define a new conf parameter in nova called –
            base_vm_image=/var/lib/libvirt/images/baseimage.qcow2<br>
            This option is used to specify the base VM image.<br>
            <br>
            2. define a new sub_virt_type = container in nova conf.
            Setting this parameter will ensure mounting of the container
            filesystem inside the VM.<br>
            Unless qemu and kvm are used as virt_type – this workflow
            will not work at this moment.<br>
            <br>
            3. In the virt/libvirt/driver.py we do the following based
            on the sub_virt_type = container:<br>
            <br>
            - We create a qcow2 disk from the base_vm_image and expose
            that 'disk' as the boot disk for the virtual machine.<br>
             Note – this is very similar to a regular virtual machine
            boot minus the fact that the image is not downloaded from<br>
            glance but instead it is present on the host.<br>
            <br>
            <br>
            - We download the docker image into the
            /var/lib/nova/instances/_base directory and then for each
            new virtual machine boot – we create a new directory
            /var/lib/nova/instances/<instance_uuid> as it's and
            copy the docker filesystem to it. Note – there are
            subsequent improvements to this idea that could be performed
            around the lines of using a union filesystem approach.<br>
            - The step above allows each virtual machine to have a
            different copy of the filesystem.<br>
            - We create a 'passthrough' mount of the filesystem via
            libvirt. This code is also present in the nova libvirt
            driver and we just trigger it based on our sub_virt_type
            parameter.<br>
            <br>
            4. A cloud init – userdata is provided that looks somewhat
            like this:<br>
            <br>
            runcmd:<br>
              - mount -t 9p -o trans=virtio share_dir /mnt<br>
              - chroot /mnt /bin/<command_to_run><br>
            <br>
            The command_to_run is usually the entrypoint to for the
            docker image.<br>
            <br>
            There could be better approaches to determine the entrypoint
            as well (say from docker image metadata).<br>
            <br>
            <br>
            Approach 2.<br>
            <br>
            In this approach, the workflow remains the same as the first
            one with the exception that the<br>
            docker image is changed into a qcow2 image using a tool like
            virt-make-fs before uploading it to glance, instead of a tar
            file.<br>
            <br>
            A tool like virt-make-fs can convert a tar file to a qcow2
            image very easily.<br>
            <br>
            This image is then downloaded on the compute node and a
            qcow2 disk is created/attached to the virtual machine that
            boots using the base_vm_image.<br>
            <br>
            <br>
            Approach 3<br>
            <br>
            A custom qcow2 image is created using kernel, initramfs and
            the docker image and uploaded to glance.  No changes are
            needed in openstack nova. It boots as a regular VM.<br>
            <br>
            Changes will be needed in image generation tools and will
            involve few additional tasks from an operator point of view.<br>
            <br>
            <br>
            I look forward to your comments/suggestions on the above.<br>
            <br>
            <br>
            Thanks,<br>
            Sudipto<br>
            <br>
                <br>
__________________________________________________________________________<br>
            OpenStack Development Mailing List (not for usage questions)<br>
            Unsubscribe:
            <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
            <a moz-do-not-send="true"
              href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
          </div>
        </span></font>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>