Resource UUID context

[fwiesel]

These changes store the instance.uuid in the project independent field resource_uuid reserved for that purpose.
The second patch removes the now superfluous instance parameter from all logging calls.

[joker-at-work]

For all the functions and services we haven't marked explicitly, the context is passed through RPC and thus creates a new RequestContext object with the passed data, which will call update_store() in its __init__(), do I understand that correctly?

How confident are you, that you found all the places that need an explicit set of context.resource_id?

What about the following instance= in LOG.*

• https://github.com/sapcc/nova/blob/d76f8f076ef81a90bf877f168b09aea89a683e3b/nova/virt/vmwareapi/driver.py#L1026
• https://github.com/sapcc/nova/blob/d76f8f076ef81a90bf877f168b09aea89a683e3b/nova/virt/vmwareapi/vmops.py#L2944-L2945
• https://github.com/sapcc/nova/blob/d76f8f076ef81a90bf877f168b09aea89a683e3b/nova/virt/vmwareapi/vmops.py#L2953-L2954
• https://github.com/sapcc/nova/blob/d76f8f076ef81a90bf877f168b09aea89a683e3b/nova/virt/vmwareapi/vmops.py#L2956-L2961

I find it funny, that even resource_uuid in the context is a nova-ism that only ends up in the instance variable of the log. Proper way seems to be using resource, but that would need a change in log-format, too, I guess, as it populates the resource key of the log record.

[fwiesel]

For all the functions and services we haven't marked explicitly, the context is passed through RPC and thus creates a new RequestContext object with the passed data, which will call update_store() in its init(), do I understand that correctly?

Exactly, the resource_id is passed through exactly like the request_id (or global_request_id).

How confident are you, that you found all the places that need an explicit set of context.resource_id?

Hmm, not 100%. I am fairly sure to have covered all the places where we work with a single instance, and during the creation of instances, as that is fairly well encapsulated. If there is a lack of coverage, I suspect it to be where we iterate over instances. I didn't pay attention to other drivers.

What about the following instance= in LOG.*

The one with in driver.py is probably creeped in due to rebasing. I'll change that.
The ones in vmops where using vi.instance, and I wasn't 100% if it was the same. On second look, it is the same, so it can be removed.

I find it funny, that even resource_uuid in the context is a nova-ism that only ends up in the instance variable of the log. Proper way seems to be using resource, but that would need a change in log-format, too, I guess, as it populates the resource key of the log record.

Hmm, I didn't notice that, but you are right. But that would also mean passing everywhere to the logger resource=, just to have the uuid in the logs. But that probably reduces my chances of getting the change upstream.

[joker-at-work]

Looks like this broke some tests.

[fwiesel]

I'll fix them, but I am not sure anymore that is the right way.

[joker-at-work]

I'll fix them, but I am not sure anymore that is the right way.

fixing tests or your changes adding the resource_uuid?

[fwiesel]

Fixing the tests is certainly sensible, that is why I do it.

But if the whole approach is sensible. I still think it is stupid to pass an instance (or resource) around just to have the logging right.