[openstack-dev] [dib][heat] dib-utils/dib-run-parts/dib v2 concern
cboylan at sapwetik.org
Thu Mar 16 17:16:37 UTC 2017
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, 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
> (undercloud) [stack at undercloud ~]$ rpm -qf /bin/dib-run-parts
> (undercloud) [stack at undercloud ~]$ rpm -qf
> (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
> /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
> But the exciting thing from a rolling-out-bugfixes perspective is that
> one actually running via o-r-c isn't either of the packaged versions
> 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,
> 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.
More information about the OpenStack-dev