[execution-environments] Report receptor unit_id in API for manual debugging

[AlanCoding]

ISSUE TYPE

• Feature Idea

SUMMARY

The API should give the unit_id for a job, or otherwise document how the user can figure out the unit_id from other fields.

If use case is that an error happens and a user or support personnel need to shell into the server and manually run receptorctl commands to poke at what happened. Ping @gamuniz

These commands follow the pattern of:

• receptorctl work status {unit_id}
• receptorctl work cancel {unit_id}
• receptorctl work release {unit_id}

Although the user shouldn't ever have need to call cancel or release... things can always go wrong!

[kdelee]

@ryanpetrello @AlanCoding what is the PR related to this?

[AlanCoding]

@kdelee #9892 which is merged now

[kdelee]

@AlanCoding @shanemcd I notice this only on container group jobs. Is that expected? I'm still not 100% up to date on if receptor is used at all when jobs are ran locally on the tower nodes

[ryanpetrello]

This should be available both on container group jobs, and normal instance group runs.

[kdelee]

Hmm, nevermind, must have gotten confused. I am seeing it on regular jobs now.

I'll sprinkle in some assertions about this being populated on different types of jobs, but seeing as it is mostly a debugging tool, I'm going to close this