Re: [openstack-dev] [Solum] Working group on language packs

2013-12-02 Thread Clayton Coleman


- Original Message -
 Clayton, good detail documentation of the design approach @
 https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts
 
 A few questions -
 1. On the objective of supporting both heroku build packs and openshift
 cartridges: how compatible are these two with each other? i.e. is there
 enough common denominator between the two that Solum can be compatible with
 both?

A buildpack is:

1) an ubuntu base image with a set of preinstalled packages
2) a set of buildpack files downloaded into a specific location on disk
3) a copy of the application git repository downloaded into a specific location 
on disk
4) a script that is invoked to transform the buildpack files and git repository 
into a set of binaries (the deployment unit) in an output directory

Since the Solum proposal is a transformation of a base (#1) via a script (which 
can call #4) with injected app data (#2 and #3), we should have all the 
ingredients.

An openshift cartridge is:

1) a rhel base image with a set of preinstalled packages
   a) some additional tools and environment to execute cartridges
2) a metadata file that describes how the cartridge can be used (what the ports 
it exposes are, how it can be used)
3) a set of cartridge files that include binaries and control scripts
   a) a bin/install script that does setup of the binaries on disk, and the 
basics preparation
   b) a bin/control script that manages running processes and to do builds

An OpenShift cartridge would be a base image (#1) with a script that invokes 
the correct steps in the cartridge (#3) to create, build, and deploy the 
contents.

 
 2. What is the intended user persona for the image author? Is it the
 service operator, the developer end user, or could be both?

Yes, and there is a 3rd persona which could be a vendor packaging up their 
software in distributable format for consumption by multiple service operators. 
 Will add a section to the proposal.

These were discussed in the API meeting as well 
(http://irclogs.solum.io/2013/solum.2013-12-02-17.05.html), the additional info 
will be added to the proposal.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Solum] Working group on language packs

2013-11-29 Thread Monty Taylor


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
 
  

Re: [openstack-dev] [Solum] Working group on language packs

2013-11-25 Thread Georgy Okrokvertskhov
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.

Thanks
Georgy


On Sat, Nov 23, 2013 at 4:30 PM, Clayton Coleman ccole...@redhat.comwrote:



  On Nov 23, 2013, at 6:48 PM, Robert Collins 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
 wrote:
 
  On Nov 23, 2013, at 2:39 PM, Robert Collins robe...@robertcollins.net
  wrote:
 
  On 24 November 2013 05:42, Clayton Coleman 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
  Distinguished Technologist
  HP Converged Cloud
 
  ___
  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
 
 
 
  --
  Robert Collins rbtcoll...@hp.com
  Distinguished Technologist
  HP Converged Cloud
 
  ___
  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




-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
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


Re: [openstack-dev] [Solum] Working group on language packs

2013-11-23 Thread Clayton Coleman


 On Nov 23, 2013, at 2:37 AM, Clint Byrum cl...@fewbar.com wrote:
 
 Excerpts from Clayton Coleman's message of 2013-11-22 21:43:40 -0800:
 
 On Nov 22, 2013, at 9:54 PM, Monty Taylor mord...@inaugust.com wrote:
 
 
 
 On 11/22/2013 11:34 AM, Clayton Coleman wrote:
 I have updated the language pack (name subject to change) blueprint
 with the outcomes from the face2face meetings, and drafted a
 specification that captures the discussion so far.  The spec is
 centered around the core idea of transitioning base images into
 deployable images (that can be stored in Nova and sent to Glance).
 These are *DRAFT* and are intended for public debate.
 
 https://blueprints.launchpad.net/solum/+spec/lang-pack 
 https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts
 
 Please take this opportunity to review these documents and offer
 criticism and critique via the ML - I will schedule a follow up deep
 dive for those who expressed interest in participation [1] after US
 Thanksgiving.
 
 Hi!
 
 I'd strongly suggest looking at the diskimage-builder project that's
 part of the TripleO program. Someone has already done a POC of turning
 it in to an aaS, and there are already people working on tying
 diskimage-builder elements and heat templates. Given that OpenStack has
 prior art and work in this direction, you should be able to accelerate
 getting to your goals pretty quickly.
 
 diskimage-builder is definitely a primary tool choice for an openstack 
 deployer creating vm images, and should certainly be promoted where 
 possible.  I'll add an example to the doc.
 
 The spec does try to be agnostic to the actual image creation technology in 
 play - organizations using containers or Windows images may have alternative 
 preferences about the underlying mechanism by which they generate images.  
 Decoupling the image creation from how the image is used is a key goal, 
 especially since organizations often want to separate environment 
 preparation and development along role lines.
 
 Windows images are special, yes. For those, perhaps chat with the Murano
 folk?
 
 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?

 
 I actually think diskimage-builder would be really useful for container
 building, as it doesn't make any assumptions about things like having a
 kernel. In fact we've discussed the possibility of using lxc to do the
 image builds instead of chroot so that the builds would be more
 isolated from the build host.
 
 ___
 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


Re: [openstack-dev] [Solum] Working group on language packs

2013-11-23 Thread Robert Collins
On 24 November 2013 05:42, Clayton Coleman 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?

-Rob


-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Solum] Working group on language packs

2013-11-23 Thread Adrian Otto

On Nov 23, 2013, at 2:39 PM, Robert Collins robe...@robertcollins.net
 wrote:

 On 24 November 2013 05:42, Clayton Coleman 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
 Distinguished Technologist
 HP Converged Cloud
 
 ___
 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


Re: [openstack-dev] [Solum] Working group on language packs

2013-11-23 Thread Robert Collins
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.

-Rob


On 24 November 2013 12:24, Adrian Otto adrian.o...@rackspace.com wrote:

 On Nov 23, 2013, at 2:39 PM, Robert Collins robe...@robertcollins.net
  wrote:

 On 24 November 2013 05:42, Clayton Coleman 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
 Distinguished Technologist
 HP Converged Cloud

 ___
 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



-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Solum] Working group on language packs

2013-11-22 Thread Adrian Otto
The breakout meeting schedule poll is published here (dates will be published 
here once they are selected):
https://wiki.openstack.org/wiki/Solum/BreakoutMeetings#Language_Pack_Working_Group_Series

If you would like to join the working group, please:

1) Subscribe to the lang-pack blueprint: 
https://blueprints.launchpad.net/solum/+spec/lang-pack
2) Participate in the doodle poll currently published on the wiki page 
referenced above to help select the best time for the meetings.

Thanks,

Adrian


For those interested in joining this working group,
On Nov 22, 2013, at 8:34 AM, Clayton Coleman ccole...@redhat.com wrote:

 I have updated the language pack (name subject to change) blueprint with the 
 outcomes from the face2face meetings, and drafted a specification that 
 captures the discussion so far.  The spec is centered around the core idea of 
 transitioning base images into deployable images (that can be stored in Nova 
 and sent to Glance).  These are *DRAFT* and are intended for public debate.  
 
 https://blueprints.launchpad.net/solum/+spec/lang-pack
 https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts
 
 Please take this opportunity to review these documents and offer criticism 
 and critique via the ML - I will schedule a follow up deep dive for those who 
 expressed interest in participation [1] after US Thanksgiving.
 
 [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes
 
 
 
 
 
 
 ___
 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


Re: [openstack-dev] [Solum] Working group on language packs

2013-11-22 Thread Monty Taylor


On 11/22/2013 11:34 AM, Clayton Coleman wrote:
 I have updated the language pack (name subject to change) blueprint
 with the outcomes from the face2face meetings, and drafted a
 specification that captures the discussion so far.  The spec is
 centered around the core idea of transitioning base images into
 deployable images (that can be stored in Nova and sent to Glance).
 These are *DRAFT* and are intended for public debate.
 
 https://blueprints.launchpad.net/solum/+spec/lang-pack 
 https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts

  Please take this opportunity to review these documents and offer
 criticism and critique via the ML - I will schedule a follow up deep
 dive for those who expressed interest in participation [1] after US
 Thanksgiving.

Hi!

I'd strongly suggest looking at the diskimage-builder project that's
part of the TripleO program. Someone has already done a POC of turning
it in to an aaS, and there are already people working on tying
diskimage-builder elements and heat templates. Given that OpenStack has
prior art and work in this direction, you should be able to accelerate
getting to your goals pretty quickly.

 [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes
 
 
 
 
 
 
 ___ 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


Re: [openstack-dev] [Solum] Working group on language packs

2013-11-22 Thread Clayton Coleman


 On Nov 22, 2013, at 9:54 PM, Monty Taylor mord...@inaugust.com wrote:
 
 
 
 On 11/22/2013 11:34 AM, Clayton Coleman wrote:
 I have updated the language pack (name subject to change) blueprint
 with the outcomes from the face2face meetings, and drafted a
 specification that captures the discussion so far.  The spec is
 centered around the core idea of transitioning base images into
 deployable images (that can be stored in Nova and sent to Glance).
 These are *DRAFT* and are intended for public debate.
 
 https://blueprints.launchpad.net/solum/+spec/lang-pack 
 https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts
 
 Please take this opportunity to review these documents and offer
 criticism and critique via the ML - I will schedule a follow up deep
 dive for those who expressed interest in participation [1] after US
 Thanksgiving.
 
 Hi!
 
 I'd strongly suggest looking at the diskimage-builder project that's
 part of the TripleO program. Someone has already done a POC of turning
 it in to an aaS, and there are already people working on tying
 diskimage-builder elements and heat templates. Given that OpenStack has
 prior art and work in this direction, you should be able to accelerate
 getting to your goals pretty quickly.

diskimage-builder is definitely a primary tool choice for an openstack deployer 
creating vm images, and should certainly be promoted where possible.  I'll add 
an example to the doc.

The spec does try to be agnostic to the actual image creation technology in 
play - organizations using containers or Windows images may have alternative 
preferences about the underlying mechanism by which they generate images.  
Decoupling the image creation from how the image is used is a key goal, 
especially since organizations often want to separate environment preparation 
and development along role lines.

 
 [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes
 
 
 
 
 
 
 ___ 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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Solum] Working group on language packs

2013-11-22 Thread Clint Byrum
Excerpts from Clayton Coleman's message of 2013-11-22 21:43:40 -0800:
 
  On Nov 22, 2013, at 9:54 PM, Monty Taylor mord...@inaugust.com wrote:
  
  
  
  On 11/22/2013 11:34 AM, Clayton Coleman wrote:
  I have updated the language pack (name subject to change) blueprint
  with the outcomes from the face2face meetings, and drafted a
  specification that captures the discussion so far.  The spec is
  centered around the core idea of transitioning base images into
  deployable images (that can be stored in Nova and sent to Glance).
  These are *DRAFT* and are intended for public debate.
  
  https://blueprints.launchpad.net/solum/+spec/lang-pack 
  https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts
  
  Please take this opportunity to review these documents and offer
  criticism and critique via the ML - I will schedule a follow up deep
  dive for those who expressed interest in participation [1] after US
  Thanksgiving.
  
  Hi!
  
  I'd strongly suggest looking at the diskimage-builder project that's
  part of the TripleO program. Someone has already done a POC of turning
  it in to an aaS, and there are already people working on tying
  diskimage-builder elements and heat templates. Given that OpenStack has
  prior art and work in this direction, you should be able to accelerate
  getting to your goals pretty quickly.
 
 diskimage-builder is definitely a primary tool choice for an openstack 
 deployer creating vm images, and should certainly be promoted where possible. 
  I'll add an example to the doc.
 
 The spec does try to be agnostic to the actual image creation technology in 
 play - organizations using containers or Windows images may have alternative 
 preferences about the underlying mechanism by which they generate images.  
 Decoupling the image creation from how the image is used is a key goal, 
 especially since organizations often want to separate environment preparation 
 and development along role lines.

Windows images are special, yes. For those, perhaps chat with the Murano
folk?

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.

I actually think diskimage-builder would be really useful for container
building, as it doesn't make any assumptions about things like having a
kernel. In fact we've discussed the possibility of using lxc to do the
image builds instead of chroot so that the builds would be more
isolated from the build host.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev