Open Stack

On 11/25/2013 12:39 PM, Georgy Okrokvertskhov wrote:
> Hi,
> 
> 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. 
> 
> I got an impression that Docker does the same, installs application on
> running VM and then creates a snapshot.
> 
> 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. 

Right. This is essentially what diskimage-builder does now. You don't
even need heat for it- it does all of that locally and makes a nice qcow
for you - but it starts with a base cloud image, executes commands in
it, and saves the results.

> 
> On Sat, Nov 23, 2013 at 4:30 PM, Clayton Coleman <ccoleman at redhat.com
> <mailto:ccoleman at redhat.com>> wrote:
> 
> 
> 
>     > On Nov 23, 2013, at 6:48 PM, Robert Collins
>     <robertc at robertcollins.net <mailto:robertc at robertcollins.net>> wrote:
>     >
>     > Ok, so no - diskimage-builder builds regular OpenStack full disk
>     disk images.
>     >
>     > Translating that to a filesystem is easy; doing a diff against another
>     > filesystem version is also doable, and if the container service for
>     > Nova understands such partial container contents you could certainly
>     > glue it all in together, but we don't have any specific glue for that
>     > today.
>     >
>     > I think docker is great, and if the goal of solum is to deploy via
>     > docker, I'd suggest using docker - no need to make diskimage-builder
>     > into a docker clone.
>     >
>     > OTOH if you're deploying via heat, I think Diskimage-builder is
>     > targeted directly at your needs : we wrote it for deploying OpenStack
>     > after all.
> 
>     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).
> 
>     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.
> 
>     >
>     > -Rob
>     >
>     >
>     >> On 24 November 2013 12:24, Adrian Otto <adrian.otto at rackspace.com
>     <mailto:adrian.otto at rackspace.com>> wrote:
>     >>
>     >> On Nov 23, 2013, at 2:39 PM, Robert Collins
>     <robertc at robertcollins.net <mailto:robertc at robertcollins.net>>
>     >> wrote:
>     >>
>     >>> On 24 November 2013 05:42, Clayton Coleman <ccoleman at redhat.com
>     <mailto:ccoleman at redhat.com>> wrote:
>     >>>
>     >>>>> Containers will work fine in diskimage-builder. One only needs
>     to hack
>     >>>>> in the ability to save in the container image format rather
>     than qcow2.
>     >>>>
>     >>>> That's good to know.  Will diskimage-builder be able to break
>     those down into multiple layers?
>     >>>
>     >>> What do you mean?
>     >>
>     >> 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.
>     >>
>     >>>
>     >>> -Rob
>     >>>
>     >>>
>     >>> --
>     >>> Robert Collins <rbtcollins at hp.com <mailto:rbtcollins at hp.com>>
>     >>> Distinguished Technologist
>     >>> HP Converged Cloud
>     >>>
>     >>> _______________________________________________
>     >>> OpenStack-dev mailing list
>     >>> OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >>
>     >>
>     >> _______________________________________________
>     >> OpenStack-dev mailing list
>     >> OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     >
>     > --
>     > Robert Collins <rbtcollins at hp.com <mailto:rbtcollins at hp.com>>
>     > Distinguished Technologist
>     > HP Converged Cloud
>     >
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> Mirantis
> http://www.mirantis.com <http://www.mirantis.com/>
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>