Deployment problems now returned with instance_group

[selzoc]

What is this change about?

This will allow for display/sorting of problems via this value in the CLI.

Please provide contextual information.

In support of the bosh recover work (story), which asks users for desired problem resolutions on a per-instance-group basis. Prior to this change, there was no way for the CLI to have the value of the instance group of a problem.

bosh create-recovery-plan PR

How should this change be described in bosh release notes?

List problems endpoint now returns the instance group of each problem.

Does this PR introduce a breaking change?

No

[nouseforaname]

lgtm

[jpalermo]

Is "unknown job" already used somewhere? I know we've eliminated most external conflation of the original job => instance group rename even though a lot of the internal code still had the old names.

[selzoc]

@jpalermo I don't think so - in fact there's a db constraint that the job name not be null for an instance. However, I just mirrored the logic that's in the description functions, which all have job = @instance.job || 'unknown job'.

[jpalermo]

It's not "great" that we're spreading misinformation. If a user gets back an "unknown job" message at some point, it feels actively unhelpful since "job" here refers to the 2015 notion of a job rather than "unknown instance group" which might give them a clue.

But I've no idea if this is ever even supposed to happen or it's just the exception case that will never occur. If it does surface to users at some point, we should probably go around and update the strings to be helpful.

[beyhan]

I agree with @jpalermo that we should go for unknown instance group here because unknown job is confusing.

[selzoc]

I would propose a follow-on issue to cleanse the codebase for uknown job then, as it's out of the scope of this PR.

@jpalermo afaict, this will never occur.