[openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

Ben Nemec openstack at nemebean.com
Wed Nov 26 17:02:59 UTC 2014

On 11/25/2014 10:58 PM, Ian Wienand wrote:
> Hi,
> My change [1] to enable a consistent tracing mechanism for the many
> scripts diskimage-builder runs during its build seems to have hit a
> stalemate.
> I hope we can agree that the current situation is not good.  When
> trying to develop with diskimage-builder, I find myself constantly
> going and fiddling with "set -x" in various scripts, requiring me
> re-running things needlessly as I try and trace what's happening.
> Conversley some scripts set -x all the time and give output when you
> don't want it.
> Now nodepool is using d-i-b more, it would be even nicer to have
> consistency in the tracing so relevant info is captured in the image
> build logs.
> The crux of the issue seems to be some disagreement between reviewers
> over having a single "trace everything" flag or a more fine-grained
> approach, as currently implemented after it was asked for in reviews.
> I must be honest, I feel a bit silly calling out essentially a
> four-line patch here.

My objections are documented in the review, but basically boil down to
the fact that it's not a four line patch, it's a 500+ line patch that
does essentially the same thing as:

set +e
set -x

in disk-image-create.  You do lose set -e in disk-image-create itself on
debug runs because that's not something we can safely propagate,
although we could work around that by unsetting it before calling hooks.
 FWIW I've used this method locally and it worked fine.

The only drawback is it doesn't allow the granularity of an if block in
every script, but I don't personally see that as a particularly useful
feature anyway.  I would like to hear from someone who requested that
functionality as to what their use case is and how they would define the
different debug levels before we merge an intrusive patch that would
need to be added to every single new script in dib or tripleo going forward.


More information about the OpenStack-dev mailing list