search

redhat-openstack / tripleo-quickstart

Ansible roles for setting up TripleO virtual environments and building images
16 stars 15 forks source link

image building: decouple I.B. playbook setup/config from quickstart proper #51

Closed halcyondude closed 8 years ago

halcyondude commented 8 years ago

Presently the image building playbooks are reusing too much of the libvirt / networking setup & config from the quickstart roles. For example there's no need to set up overcloud network(s) to build the images. In addition it makes the build image workflows prone to breaking on setup/config, for reasons unrelated to image building. Finally it increases the amount of time needed to build an image. As we explore ways to leverage tripleo-quickstart's appliance based undercloud in (potentially) in more projects for CI, being able to quickly, simply, and cleanly build images will increasingly become important. I've got some deltas locally to address this, testing now. Planning to post a review shortly.

larsks commented 8 years ago

My vote is to just fork a new repository that contains only the image building components so that it's completely separate from the rest of the quickstart.

On the other hand:

Presently the image building playbooks are reusing too much of the libvirt / networking setup & config from the quickstart roles

Do we need any of the libvirt roles for the image building? I see we'll pulling them in from the playbooks/build-image.yml playbook, but I don't think they're actually referenced in any of the image roles. I don't see any use of the virt* modules or of virsh anywhere under playbooks/roles/images.

halcyondude commented 8 years ago

yeah...my "prototype" is just to nuke the ref's from the build-image.yml. The actual build image role pulls in the basic libvirt setup (install libvirt packages, but not networking config).

Want me to just post what I have now? Seems to work :)

I would like to avoid a fork if at all possible. It's handy to have a single project for building images, and the scripts that use (and love) them.

halcyondude commented 8 years ago

re: why libvirt is needed at all, we leverage qemu-img (and friends) to generate the actual binaries.

larsks commented 8 years ago

re: why libvirt is needed at all, we leverage qemu-img (and friends) to generate the actual binaries.

qemu-img doesn't require any support from libvirt. On the other hand, the various virt-* tools (like virt-customize) do require libvirt to be installed and running, but don't require any of the network configuration (at all) from our libvirt/ roles.

Simply pulling in the parts/libvirt role ought to be sufficient. That installs libvirt and ensures that the service is started.

halcyondude commented 8 years ago

{nod} - I'm somewhat new to all of this, during virt-customize / virt-sparsify looking at process trees it fires up qemu-img. Thanks for making the distinction. BTW I like the new factoring of tasks (parts) that went in recently. +1

If you're cool with it I'll make sure this works completely (locally) and post a review.

larsks commented 8 years ago

If you're cool with it I'll make sure this works completely (locally) and post a review.

I am always in favor of posting a review :).

halcyondude commented 8 years ago

WIP - testing it still: https://review.gerrithub.io/#/c/266692/

halcyondude commented 8 years ago

Removed WIP tag. Integrated feedback and ready for review. https://review.gerrithub.io/#/c/266692/

halcyondude commented 8 years ago

merged