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
_______________________________________________
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
