Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor vmref resolution #268

Draft
wants to merge 8 commits into
base: stable/rocky-m3
Choose a base branch
from

Conversation

fwiesel
Copy link
Member

@fwiesel fwiesel commented Nov 5, 2021

This set of changes moves out the resolution of get_vm_ref in case of failed search by uuid in the search-index to the cluster-level.

I'll try to break out some patches in smaller pull-requests.

@fwiesel fwiesel force-pushed the refactor_vmref_resolution branch from 3507803 to d56371d Compare December 27, 2021 08:13
Currently, the code relies on passing instance to each log call
as a keyword parameter. The issue there is, that it is not done
necessarily 100% consistently, which causes difficulty to match
the log messages with the instance at time. Also it requires at
some places the caller to pass the instance purely for logging
purposes.

Finally, this allows olso.log to remove nova specific code
to handle the instance/instance_uuid, but use the generic
resource_uuid from the context.

Change-Id: I3aade880d3cf5edb0d866b6b72fdeec8a0ae0679
The resource_id is now set automatically, so no need
to set it explicitly.

Change-Id: Ia2b9ed0167a6420b7441401c5f4614b2ce305962
Especially 'host' was fairly common name and potentially
conflicting with the use of variables of the same name

Change-Id: Idf3920e5e94c5aef904781bc365fc310496346cd
When importing an image, and having a duplicate name
we were going through all the VMs in the vcenter to find matching one.
This can be potentially 100k ones, while it is rather likely that it
is in the same location we are trying to import.
We now search in the folder, and failing that in the datastore.
As the name is specific for the datastore, it would should only fail,
if someone uses the same naming convention and place it somewhere else.

Change-Id: I9e1c55d560d36768037f4036b546b80eaa21ed32
Previously, the functions were often taking an optional vm_ref
argument, and would resolve the vm_ref from the instance itself, if not.
In other places, the instance was only passed for logging purposes.

By only taking a vm_ref as argument and relying on the resource_id being
logged, we reduce the variability in the interface.
This breaks mostly vm_ref_cache_heal_from_instance functor, which is
solved in a different way in a another patch.

Change-Id: Ifb4b4caacbacbbc44236d942c6e08489ed41ec43
The object is not only used by the driver,
but in practically all modules of vmwareapi.

It reduces a bit the scope of the driver module
itself

Change-Id: I76e446945c312e5b4fea54d04335d7d20ef3829d
The _wait_for_task doesn't add over the existing wait_for_task function,
and the call_method is clearly a public function used all over the place
Remove the first, and rename the second accordingly

Change-Id: I020fd565a4f68f2498f2bf5e6537391d81f325b9
By encapsulating all the paramters for searching for
the vm-ref again, we can move the retry logic to the
session object, where we can try to recover the vm-ref
should it result in a ManagedObjectNotFound exception

Change-Id: Id382cadd685a635cc7a4a83f69b58075521c8771
@fwiesel fwiesel force-pushed the refactor_vmref_resolution branch from d56371d to f8699bb Compare December 27, 2021 08:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant