Open Stack

On Wed, Mar 15, 2017 at 04:22:37PM -0500, Ben Nemec wrote:
> While looking through the dib v2 changes after the feature branch was merged
> to master, I noticed this commit[1], which bring dib-run-parts back into dib
> itself.  Unfortunately I missed the original proposal to do this, but I have
> some concerns about the impact of this change.
> 
> Originally the split was done so that dib-run-parts and one of the
> os-*-config projects (looks like os-refresh-config) that depends on it could
> be included in a stock distro cloud image without pulling in all of dib.
> Note that it is still present in the requirements of orc: https://github.com/openstack/os-refresh-config/blob/master/requirements.txt#L5
> 
> Disk space in a distro cloud image is at a premium, so pulling in a project
> like diskimage-builder to get one script out of it was not acceptable, at
> least from what I was told at the time.
> 
> I believe this was done so a distro cloud image could be used with Heat out
> of the box, hence the heat tag on this message.  I don't know exactly what
> happened after we split out dib-utils, so I'm hoping someone can confirm
> whether this requirement still exists.  I think Steve was the one who made
> the original request.  There were a lot of Steves working on Heat at the
> time though, so it's possible I'm wrong. ;-)

I don't think I'm the Steve you're referring to, but I do have some
additional info as a result of investigating this bug:

https://bugs.launchpad.net/tripleo/+bug/1673144

It appears we have three different versions of dib-run-parts on the
undercloud (and, presumably overcloud nodes) at the moment, which is a
pretty major headache from a maintenance/debugging perspective.

However we resolve this, *please* can we avoid permanently forking the
tool, as e.g in that bug, where do I send the patch to fix leaking
profiledir directories?  What package needs an update?  What is installing
the script being run that's not owned by any package?

Yes, I know the answer to some of those questions, but I'm trying to point
out duplicating this script and shipping it from multiple repos/packages is
pretty horrible from a maintenance perspective, especially for new or
casual contributors.

If we have to fork it, I'd suggest we should rename the script to avoid the
confusion I outline in the bug above, e.g one script -> one repo -> one
package?

Thanks!

Steve