Open Stack

On 06/06/16 01:21, Jeremy Stanley wrote:
> Use Diskimage Builder in Nodepool
> ---------------------------------
>
> http://specs.openstack.org/openstack-infra/infra-specs/specs/dib-nodepool.html
>
> As I understand it, this is complete except for TripleO's images
> (yes, irony since DIB is itself a TripleO team project). We'd like
> to be able to deprecate and eventually remove snapshot support in
> nodepool, so I think this stays on the priority list until TripleO
> is no longer an issue (fixed or switched to being a third-party CI
> system).

Hello,

Sorry if I come late in the party, I rely on Nodepool snapshot feature 
to polish up images. I have even hit a wall recently attempting to use 
puppet to provision a service that can not always be done in a chroot or 
be to slow to do at instance boot time.

If I understand the spec properly, snapshotting would no more be needed 
to have a proper image, but you might still want to keep it to polish it 
up in the context of the image (ie within an instance).  If that is 
heavy enough, it is lighter to do it once in a snapshot than on each 
instance booting.


Andreas Florath and Greg Haynes pointed out that upstart / init scripts 
in a chroot is usually a no/no
https://review.openstack.org/#/c/322305/

That could be done on first boot of an instance but when using puppet 
you would bring up a class that install various packages among the 
service.  That in turns means redundant operations occurring for each 
instance boot, consume extra disk on compute nodes and push back the 
delay before a node is ready in Jenkins/Nodepool.


For the context:

Wikimedia has an OpenStack cluster with images that are not suitable for 
CI for a variety of reasons.  I have thus used DIB to create an image 
from scratch that has all the material.  Right now the snapshot part is 
merely to update and dist-upgrade, refresh the git mirrors and refresh 
puppet.   But I would definitely have a use case to bring on services at 
snapshot time instead of at instance boot, merely because their set of 
dependencies is long and heavy to install.

My aim is really to have the instance to spin on as fast as possible, 
currently less than a minute between Nodepool asking for an instance and 
it being ready/added to Jenkins. A reason is our cluster and pool are 
smalls, our jobs are mostly sub minutes jobs and we have disk constraints.


Good to see you are going to provision your own images. Would surely 
make life easier for OpenStack 3rd parties which might well just load 
those references images instead of buidling their own, and I am sure one 
can wrap them with Vagrant for developers usage.



-- 
Antoine Musso