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 :). > 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. > > Thanks! > > Steve > Cheers, - Greg __________________________________________________________________________ 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