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 <ccole...@redhat.com > <mailto:ccole...@redhat.com>> wrote: > > > > > On Nov 23, 2013, at 6:48 PM, Robert Collins > <robe...@robertcollins.net <mailto:robe...@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.o...@rackspace.com > <mailto:adrian.o...@rackspace.com>> wrote: > >> > >> On Nov 23, 2013, at 2:39 PM, Robert Collins > <robe...@robertcollins.net <mailto:robe...@robertcollins.net>> > >> wrote: > >> > >>> On 24 November 2013 05:42, Clayton Coleman <ccole...@redhat.com > <mailto:ccole...@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 <rbtcoll...@hp.com <mailto:rbtcoll...@hp.com>> > >>> Distinguished Technologist > >>> HP Converged Cloud > >>> > >>> _______________________________________________ > >>> OpenStack-dev mailing list > >>> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > -- > > Robert Collins <rbtcoll...@hp.com <mailto:rbtcoll...@hp.com>> > > Distinguished Technologist > > HP Converged Cloud > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev