Open Stack

On 07/06/16 00:51, James E. Blair wrote:
> With DIB caching, it is generally fairly fast to rebuild a similar image
> with 'refreshed' data -- we rely on that for having images with
> up-to-date caches of data to keep our runtime short as well.
>
> However, if there truly are images that are not possible to build in
> DIB, that is unfortunate.  It looks like in this case, the issue is that
> DIB is running puppet which is configured to cause services to start.  I
> am not certain that puppet is the best choice for this -- in fact, we
> are working to remove puppet from our DIB builds.  But if using puppet
> nevertheless, I do think it's a different thing to use puppet to build
> an image versus maintaining a server.
>
> A recent spec[1] to separate out image build workers from the main
> process described how it should be abstracted so that multiple image
> building implementations can co-exist (but in separate processes to keep
> things simpler).  There was an optional section about creating a
> snapshot build worker, but it has not been implemented.
>
> If folks are interested in continuing support for snapshot images, I
> think they could do so using that framework, but so far there has not
> been much interest.  We have based quite a bit of development work on
> the premise that using DIB is the best way to create images for
> nodepool.  I would greatly prefer to reduce the enormous amount of
> complexity in nodepool that currently comes from these two methods
> cohabiting.
>
> [1]http://specs.openstack.org/openstack-infra/infra-specs/specs/nodepool-workers.html
>
> -Jim

Thank you Jim for the full context. I definitely agree the images vs 
snapshot confused me at first and it indeeds sounds easier to just build 
a reference image for the provider.

I am using puppet since that is what we use everywhere else and it I 
wasn't willing to port -and keep in sync- the puppet recipes as dib 
elements.


On 07/06/16 17:53, Jeremy Stanley wrote:
 > Worth checking with the DIB maintainers, but I've heard of work on
 > alternate non-chroot backends for it which would in theory alleviate
 > these concerns.

A non-chroot would solve my specific corner case issue for sure :) Will 
get in touch with them.

Thank you both!

-- 
Antoine Musso