[openstack-dev] [TripleO] fix poor tarball support in source-repositories

Robert Collins robertc at robertcollins.net
Tue Aug 19 00:06:25 UTC 2014

On 16 August 2014 03:11, Brownell, Jonathan C (Corvallis)
<brownell at hp.com> wrote:
> The current DIB element support for downloading tarballs via "source-repository" allows an entry in the following form:
> <name> tar <targetdir> <url>
> Today, this feature is currently used only by the mysql DIB element. You can see how it's used here:
> https://github.com/openstack/tripleo-image-elements/blob/master/elements/mysql/source-repository-mysql
> However, the underlying diskimage-builder implementation of tarball handling is rather odd and inflexible. After downloading the file (or retrieving from cache) and unpacking into a tmp directory, it performs:
> mv $tmp/*/* $targetdir
> This does work as long as the tarball follows a structure where all its files/directories are contained within a single directory, but it fails if the tarball contains no subdirectories. (Even worse is when it contains some files and some subdirectories, in which case the files are lost and the contents of all subdirs get lumped together in the output folder.)
> Since this tarball support is only used today by the mysql DIB element, I would love to fix this in both diskimage-builder and tripleo-image-element by changing to simply:
> mv $tmp/* $targetdir
> And then manually tweaking the directory structure of $targetdir from a new install.d script in the mysql element to restore the desired layout.

As Derekh says, this would tie tarball use to the element code, which
is overly tight coupling.

> However, it's important to note that this will break backwards compatibility if tarball support is used in its current fashion by users with private DIB elements.

And we're committing to not doing that.

> Personally, I consider the current behavior so egregious that it really needs to be fixed across the board rather than preserving backwards compatibility.

I presume the current behaviour is breaking something for you?

> Do others agree? If not, do you have suggestions as to how to improve this mechanism cleanly without sacrificing backwards compatibility?

We could make a heuristic (there is a patch up already to do that for
dib) that looks at the unpacked content to decide what to do.


Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

More information about the OpenStack-dev mailing list