Open Stack

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.

Thanks!

Steve