Open Stack

Excerpts from Clark Boylan's message of 2017-03-16 10:16:37 -0700:
> On Thu, Mar 16, 2017, at 09:46 AM, Steven Hardy wrote:
> > On Thu, Mar 16, 2017 at 10:30:48AM -0500, Gregory Haynes wrote:
> > > On Thu, Mar 16, 2017, at 05:18 AM, Steven Hardy wrote:
> > > > 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.
> > > > 
> > > 
> > > I looked at the bug and I think there may only be two different
> > > versions? The versions in /bin and /usr/bin seem to come from the same
> > > package (so I hope they are the same version). I don't understand what
> > > is going on with the ./lib version but that seems like either a local
> > > package / checkout or something else non-dib related.
> > > 
> > > Two versions is certainly less than ideal, though :).
> > 
> > No I think there are four versions, three unique:
> > 
> > (undercloud) [stack at undercloud ~]$ rpm -qf /usr/bin/dib-run-parts
> > dib-utils-0.0.11-1.el7.noarch
> > (undercloud) [stack at undercloud ~]$ rpm -qf /bin/dib-run-parts
> > dib-utils-0.0.11-1.el7.noarch
> > (undercloud) [stack at undercloud ~]$ rpm -qf
> > /usr/lib/python2.7/site-packages/diskimage_builder/lib/dib-run-parts
> > diskimage-builder-2.0.1-0.20170314023517.756923c.el7.centos.noarch
> > (undercloud) [stack at undercloud ~]$ rpm -qf /usr/local/bin/dib-run-parts
> > file /usr/local/bin/dib-run-parts is not owned by any package
> > 
> > /usr/bin/dib-run-parts and /bin/dib-run-parts are the same file, owned by
> > dib-utils
> > 
> > /usr/lib/python2.7/site-packages/diskimage_builder/lib/dib-run-parts is
> > owned by diskimage-builder
> > 
> > /usr/local/bin/dib-run-parts is the mystery file presumed from image
> > building
> > 
> > But the exciting thing from a rolling-out-bugfixes perspective is that
> > the
> > one actually running via o-r-c isn't either of the packaged versions
> > (doh!)
> > so we probably need to track down which element is installing it.
> > 
> > This is a little OT for this thread (sorry), but hopefully provides more
> > context around my concerns about creating another fork etc.
> > 
> > > > 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.
> > > > 
> > > 
> > > I agree. You answered my previous question of whether os-refresh-config
> > > is still in use (sounds like it definitely is) so this complicates
> > > things a bit.
> > > 
> > > > 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?
> > > 
> > > I really like this idea of renaming the script in dib which should
> > > clarify the source of each script and prevent conflicts, but this still
> > > leaves the fork-related issues. If we go the route of just keeping the
> > > current state (of there being a fork) I think we should do the rename.
> > > 
> > > The issue I spoke of (complications with depending on dib-utils when
> > > installing dib in a venv) I think came from a combination of this
> > > dependency and not requiring a package install (you used to be able to
> > > ./bin/disk-image-create without installation). Now that we require
> > > installation this may be less of an issue.
> > > 
> > > So the two reasonable options seem to be: 
> > > * Deal with the forking cost. Not the biggest cost when you notice
> > > dib-utils hasn't had a commit in over 3 months and that one was a robot
> > > commit to add some github flair.
> > > * Switch back to dib-utils in the other repo. I'm starting to prefer
> > > this slightly given that it seems there's a valid use case for it to
> > > live externally and our installation story has become a lot more clean.
> > > AFAIK this shouldn't prevent us from making the script more portable,
> > > but please correct me if there's something I'm missing.
> > 
> > Yeah if there's a way to just use one version, e.g dib-utils I guess,
> > then
> > that would be preferable I think.
> 
> I don't have all the history here, but why not just use regular
> run-parts? Then anything that needs to can continue to use dib-utils
> until such a time that they too can switch to run-parts.

At the time we wrote dib-run-parts, it didn't really exist in
Fedora/CentOS/RHEL.

$ dpkg -S $(which run-parts)
debianutils: /bin/run-parts