On 16 August 2014 03:11, Brownell, Jonathan C (Corvallis)
<brown...@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 <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

OpenStack-dev mailing list

Reply via email to