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@undercloud ~]$ rpm -qf /usr/bin/dib-run-parts > > dib-utils-0.0.11-1.el7.noarch > > (undercloud) [stack@undercloud ~]$ rpm -qf /bin/dib-run-parts > > dib-utils-0.0.11-1.el7.noarch > > (undercloud) [stack@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@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
