[openstack-dev] [TripleO] fix poor tarball support in source-repositories
Brownell, Jonathan C (Corvallis)
brownell at hp.com
Fri Aug 15 23:13:30 UTC 2014
Looks like a good solution to me. If there are no philosophical objections to it, I'll prepare a patch next week to make this happen.
From: Clint Byrum [mailto:clint at fewbar.com]
Sent: Friday, August 15, 2014 12:58 PM
Subject: Re: [openstack-dev] [TripleO] fix poor tarball support in source-repositories
Excerpts from Brownell, Jonathan C (Corvallis)'s message of 2014-08-15 08:11:18 -0700:
> 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:
> 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.
> 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.
> Personally, I consider the current behavior so egregious that it really needs to be fixed across the board rather than preserving backwards compatibility.
> Do others agree? If not, do you have suggestions as to how to improve this mechanism cleanly without sacrificing backwards compatibility?
How about we make a glob to use, so like this:
mysql tar /usr/local/mysql http://someplace/mysql.tar.gz mysql-5.*
That would result in
mv $tmp/mysql-5.*/* $targetdir
And then we would warn that assuming the glob will be '*' is deprecated, to be changed in a later release.
Users who want your proposed behavior would use . until the default changes. That would result in
mv $tmp/./* $targetdir
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev