<div dir="ltr">Hi,<div><br></div><div>Just for clarification for Windows images, I think Windows image creation is closer to Docker approach. In order to create a special Windows image we use KVM\QEMU VM with initial base image, then install all necessary components, configure them and then run special tool sysprep to remove all machine specific information like passwords and SIDS and then create a snapshot. </div>
<div><br></div><div>I got an impression that Docker does the same, installs application on running VM and then creates a snapshot.</div><div><br></div><div>It looks like that this can be done with using Heat + HOT software orchestration\Deployment tools without any additional services. This solution scales very well as all configuration steps are executed inside a VM. </div>
<div><br></div><div>Thanks</div><div>Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 23, 2013 at 4:30 PM, Clayton Coleman <span dir="ltr"><<a href="mailto:ccoleman@redhat.com" target="_blank">ccoleman@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
> On Nov 23, 2013, at 6:48 PM, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
> Ok, so no - diskimage-builder builds regular OpenStack full disk disk images.<br>
><br>
> Translating that to a filesystem is easy; doing a diff against another<br>
> filesystem version is also doable, and if the container service for<br>
> Nova understands such partial container contents you could certainly<br>
> glue it all in together, but we don't have any specific glue for that<br>
> today.<br>
><br>
> I think docker is great, and if the goal of solum is to deploy via<br>
> docker, I'd suggest using docker - no need to make diskimage-builder<br>
> into a docker clone.<br>
><br>
> OTOH if you're deploying via heat, I think Diskimage-builder is<br>
> targeted directly at your needs : we wrote it for deploying OpenStack<br>
> after all.<br>
<br>
</div>I think we're targeting all possible deployment paths, rather than just one.  Docker simply represents one emerging direction for deployments due to its speed and efficiency (which vms can't match).<br>
<br>
The base concept (images and image like constructs that can be started by nova) provides a clean abstraction - how those images are created is specific to the ecosystem or organization.  An organization that is heavily invested in a particular image creation technology already can still take advantage of Solum, because all that is necessary for Solum to know about is a thin shim around transforming that base image into a deployable image.  The developer and administrative support roles can split responsibilities - one that maintains a baseline, and one that consumes that baseline.<br>

<div class="HOEnZb"><div class="h5"><br>
><br>
> -Rob<br>
><br>
><br>
>> On 24 November 2013 12:24, Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>> wrote:<br>
>><br>
>> On Nov 23, 2013, at 2:39 PM, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
>> wrote:<br>
>><br>
>>> On 24 November 2013 05:42, Clayton Coleman <<a href="mailto:ccoleman@redhat.com">ccoleman@redhat.com</a>> wrote:<br>
>>><br>
>>>>> Containers will work fine in diskimage-builder. One only needs to hack<br>
>>>>> in the ability to save in the container image format rather than qcow2.<br>
>>>><br>
>>>> That's good to know.  Will diskimage-builder be able to break those down into multiple layers?<br>
>>><br>
>>> What do you mean?<br>
>><br>
>> Docker images can be layered. You can have a base image on the bottom, and then an arbitrary number of deltas on top of that. It essentially works like incremental backups do. You can think of it as each "layer" has a parent image, and if they all collapse together, you get the current state. Keeping track of past layers gives you the potential for rolling back to a particular restore point, or only distributing incremental changes when you know that the previous layer is already on the host.<br>

>><br>
>>><br>
>>> -Rob<br>
>>><br>
>>><br>
>>> --<br>
>>> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
>>> Distinguished Technologist<br>
>>> HP Converged Cloud<br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> --<br>
> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
> Distinguished Technologist<br>
> HP Converged Cloud<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284<br>
</div>