We had a trouble report (job 204) and I think the version of dgit was
out of date.  But I'm not sure.

Ideally we would be able to go and examine the image manually by
logging into the builder.  I think that would mean that the report
ought to say which image was in use.

I looked at the report and it says
  podman exec -i 0e0fb97016e4...
That's a container name not an image name.  And I don't think we have
any formal access to to the imgag uuid.

I suggest we:

 * Change the image creation script to put something in the image's
   /etc/environment.  (Empirically, the podman rune produced by
   autopkgtest looks at this.)

 * Have dgit-repos-server run a command to get the information
   by running a command inside the container.

Hello,

I think this is fine if that's the only way Podman lets us do something
like this.

Sean Whitton writes ("Re: Bug#1108243: want way to find image uuid used for a particular t2u job"):

It's even worse, because I doubt we know the actual image uuid at the
point we are doing this setup.

So I think we need to create an intermediate idzentifier.  Something
like:

  * At the start of the image creation script, invent an identifier.
    (How about the date in human-readable format?)
    Print it somewhere so it ends up in the log.

  * During the image creation script, bury *our* identifier in
    /etc/environment.

  * Have dgit-repos-server run a command to get the information
    by running a command inside the container.

  * When the image creation script actually creates the image,
    print its uuid (also to the log).

Then the diagnosis procedure is:

  1. Look at the identifier from the email

  2. The identifier is a date so that will tell you which of the saved
     image creation logs to look at.  You can double-check inside the
     log if you're not sure.

  3. Look later in the script and you'll find the image identifier.

  4. Now you can   podman run -i   or whatever.

This is all quite a faff and we should write it down.

If you know a better way, please do say!

Ian.

Hello,

I don't, but I feel like we should ask people who know more than us
about Podman.  Surely there is analogous problem to this in debugging
big cloud setups (Kubernetes or whatever).  We may not need to be so
creative as what you describe.

Sean and I discussed this IRL.  We've decided that this can probably
be left undone for now, particularly given how nasty the proposedd
approach is.