<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/openstack/nova.git/nova/virt/vmwareapi/session.py, branch master</title>
<subtitle>opendev.org: openstack/nova.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/openstack/nova.git/'/>
<entry>
<title>VMware: StableMoRefProxy for moref recovery</title>
<updated>2022-04-29T08:14:39+00:00</updated>
<author>
<name>Fabian Wiesel</name>
<email>fabian.wiesel@sap.com</email>
</author>
<published>2022-03-05T13:53:18+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/openstack/nova.git/commit/?id=56055ede03fff633020e0f34fa4da5c8457a89c6'/>
<id>56055ede03fff633020e0f34fa4da5c8457a89c6</id>
<content type='text'>
The vmwareapi driver uses Managed-Object references throughout the code
with the assumption that they are stable. It is however a database id,
which may change during the runtime of the compute node. e.g. If an
instance is unregistered and re-registerd in the vcenter, the moref will
change. By wrapping a moref in a proxy object, with an additional method
to resolve the openstack object to a moref, we can hide those changes
from a caller.

MoRef implementation with closure - should ease the transition to stable
mo-refs One simply has to pass the search function as a closure to the
MoRef instance, and the very same method will be called when an
exception is raised for the stored reference.

Stable Volume refs - The connection_info['data'] contains the
managed-object reference (moref) as well as the uuid of the volume.
When the moref become invalid for some reason, we can recover it by
searching for the volume-uuid as the `config.instanceUuid` attribute
of the shadow-vm.

Stable VM Ref - By encapsulating all the parameters 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.

Use refs as index for fakedb -  It was previously using the object-id
to lookup an object, meaning that you couldn't pass a newly created
Managed-object-reference like you could over the vmware-api. Now the
lookup happens over the ref-id string, and in turn some functions
were refactored to take that into account.

Partial-Bug: #1962771

Change-Id: I2a3ddf95b7fe07630855b06e732f8764efb13e91
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The vmwareapi driver uses Managed-Object references throughout the code
with the assumption that they are stable. It is however a database id,
which may change during the runtime of the compute node. e.g. If an
instance is unregistered and re-registerd in the vcenter, the moref will
change. By wrapping a moref in a proxy object, with an additional method
to resolve the openstack object to a moref, we can hide those changes
from a caller.

MoRef implementation with closure - should ease the transition to stable
mo-refs One simply has to pass the search function as a closure to the
MoRef instance, and the very same method will be called when an
exception is raised for the stored reference.

Stable Volume refs - The connection_info['data'] contains the
managed-object reference (moref) as well as the uuid of the volume.
When the moref become invalid for some reason, we can recover it by
searching for the volume-uuid as the `config.instanceUuid` attribute
of the shadow-vm.

Stable VM Ref - By encapsulating all the parameters 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.

Use refs as index for fakedb -  It was previously using the object-id
to lookup an object, meaning that you couldn't pass a newly created
Managed-object-reference like you could over the vmware-api. Now the
lookup happens over the ref-id string, and in turn some functions
were refactored to take that into account.

Partial-Bug: #1962771

Change-Id: I2a3ddf95b7fe07630855b06e732f8764efb13e91
</pre>
</div>
</content>
</entry>
<entry>
<title>VMware: Split out VMwareAPISession</title>
<updated>2022-04-23T12:54:56+00:00</updated>
<author>
<name>Fabian Wiesel</name>
<email>fabian.wiesel@sap.com</email>
</author>
<published>2022-03-05T09:29:11+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/openstack/nova.git/commit/?id=03fd208c562214476019ff2d7cc38f95c06e1348'/>
<id>03fd208c562214476019ff2d7cc38f95c06e1348</id>
<content type='text'>
The VMwareAPISession 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.

Partial-Bug: #1962771

Change-Id: I4094b6031872bd3b5c871b9a82c7e01280a3352d
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The VMwareAPISession 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.

Partial-Bug: #1962771

Change-Id: I4094b6031872bd3b5c871b9a82c7e01280a3352d
</pre>
</div>
</content>
</entry>
</feed>
