Open Stack

> 
> The approach being proposed by Pete is something that is equally
> applicable to DIB, I think. I believe that he makes a valid observation
> and our current element design may in fact be bad.
>  
> The invocation of DIB[1] is
> 
>     ${PATH_DISKIMAGEBUILDER}/bin/disk-image-create -a amd64 -o "${VM}" \
>         -x ${QEMU_IMG_OPTIONS} ${DISTRO} ${EXTRA_ELEMENTS} vm
>         heat-cfntools \
>         cloud-init-datasources ${DISTRO}-guest ${DISTRO}-${SERVICE_TYPE}
> 
> Observe that we include the ${DISTRO} element, and we prefix ${DISTRO}
> into the name of the guest and the database to get, for example,
> 
> 	... ubuntu ubuntu-guest ubuntu-mysql
> 
> The minimal set of bash and data files could be used instead and we won't
> have this matrix of datastore-by-distro proliferation that you speak of.
> That's why I believe that this solution is equally applicable to DIB.
> 
> [1] trove-integration/scripts/files/functions_qemu
> 

Ah, yep - the typical pattern for elements which are not distro elements
is to not make the distro part of the element name and then have the
element itself use the provided tools as much as possible to perform
tasks in a distro-agnostic fashion (see the package-installs element for
an example tool).

Thanks,
Greg