Since the attribute access on a ManagedObjectReference can differ
depending on the SOAP library used in the backend, we and especially
depending projects should not rely on it, because that breaks the
abstraction layer oslo.vmware is supposed to provide. To help
transitioning to a newer backend library, we introduce two methods for
retrieving a ManagedObjectReference's value and type: get_moref_value()
and get_moref_type().
We cannot handle this by just returning our own ManagedObjectReference
object with uniform access, because it's hard to get control of all
morefs returned by the API.
In that spirit, we also change all references inside of oslo_vmware to
using `get_moref_value()` and `get_moref_type()` instead of directly
accessing the attributes.
This is part of phase 1 of
https://specs.openstack.org/openstack/oslo-specs/specs/victoria/oslo-vmware-soap-library-switch.html
Change-Id: I0b0a3d37f6c7d0c750b48596bc3d79b8b2cb0cee
This patch adds the ability to properly translate and raise
VimExceptions when polling the state of the lease.
Change-Id: Ie22808471d4c72e26607e817167e0e2283630b5a
oslo.vmware library does not need to emit localized messages from
vCenter. Explicitly setting the locale to 'en' during session
establishment to avoid UnicodeDecodeError while handling non-
english vCenter messages.
Change-Id: Ifb26a7832c15af3ed3227c94131fe0b22579e889
There are cases when there is no request context set when calling an
async task in vCenter. Don't update the local store in those cases.
Change-Id: Ieef237bd5de0ad1c12afbf57426c29e3ca678dfc
There are various useful log messages which come when polling vCenter
tasks which are missing request context and thus are hard to correlate
to API requests.
This patch fixes this by passing the request context to the async
jobs which poll the vCenter tasks.
Change-Id: I8efbc343e5073d3deb18b5f87c378c271ea4d816
'Waiting for function _invoke_api to return' doesn't give any
information and only makes log files hard to read.
Also reduce logging when polling NFC leases.
Change-Id: I08653a0f529a186405695cbcfb9fc9018c93f856
The operation ID is a random string which can be added in the SOAP
headers of the remote request. vCenter and ESX will append this opID to
every log message associated with the remote request. This allows
administrators to correlate log messages for particular operation across
different systems (OpenStack -> vCenter -> ESX).
There is also addition keyword argument 'skip_op_id' which allows
callers to disable logging the opID if set to True.
Example for correlating logs for CreateVM_Task on devstack, vCenter and
ESX: http://paste.openstack.org/show/592614/
Change-Id: I75cb71c7c58b4ee9cd36fc977eb2a18a911f161f
This patch would print the task name while waiting
for tasks to complete and also update total duration
in seconds on successful completion.
Change-Id: Ia1448cc9baf1cf7abc7d4b14e27e90c86af5583c
invoke_api does not throw any exception when interface goes down and
application loses connectivity with vCenter because default timeout
is set to None which is equivalent to infinity.
This patch set allows any application to pass connection timeout so that
it will wait for the given timeout and then throw an exception.
Closes-Bug: #1564839
Change-Id: I69b099b7caaa4fb0e0067cb83b9468d4aa901cc7
Co-Authored-By: Raghuveer Shenoy <rshenoy@hp.com>
In order to get a better name, let's use oslo_utils reflection to
get function name in RetryDecorator call.
for example:
from oslo_utils import reflection
class Foo(object):
def test_fun(self):
pass
foo = Foo()
print(foo.test_fun.__name__) # "test_fun"
print(reflection.get_callable_name(foo.test_fun)) # "__main__.Foo.test_fun"
Change-Id: Ia7970b564e33ef7eafcd31fd907f4d53db1672f0
With multiple concurrent VM spawning, the service time from compute
service flow to vcenter to trigger soap requests is getting slower.
As VIM adopt requests module to access the vcenter which have default
http pool size set to 10. This need to be configured to be larger
in scale environment.
Change-Id: Ic9e9a87de378151a66187222231eaafd7a402ac5
Closes-Bug: #1479183
Username is logged while establishing vCenter session. This patch
removes username in the log as per OpenStack security guidelines.
See https://goo.gl/aSJids
Change-Id: I50d4c15d3f2213ba1651834ba7b958d8722050b5
In api, session recreation log messages are at WARN level which
can confuse administrators. These messages indicate nothing
unusual and should be at debug level. VIM error while checking
active session within an expired session is also normal and
shouldn't raise a warning.
This patch fixes the log level of these messages.
Change-Id: Ia5f81c20890973888f90a99e87e71cd18e8dd24b
Currently VMwareDriverException is raised for unknown
VIM faults. Sometimes clients may need to handle such
faults. Therefore it is better if we throw
VimFaultException with the fault_list set to the relevant
VIM fault class name.
Change-Id: I97d93ceaa82514d029fff87f1c5ad942895d8940
There are two roots for the current exception hierarchy: VimException
and VMwareDriverException, which is not a good design. This patch
refactors the exception hierarchy to fix this problem.
Summary of changes:
* Change parent of VimException to VMwareDriverException
* Change parent of exceptions corresponding to known VIM faults
to VimException
* Change parent of VimSessionOverLoadException, VimConnectionException,
VimAttributeException and ImageTransferException to
VMwareDriverException.
The guidelines followed for this refactoring are:
* The changes in existing driver code should be NIL.
* The changes in other parts of the library should be minimal.
* Any exception raised by invocation of vim APIs should be a VimException
and any exception raised by pbm APIs should be a PbmException. But this
will result in lot of changes in the library as well as existing clients.
Therefore, we define a single root for these two types of exceptions which
is labeled as VimException.
* Any exception raised by the library should be a child of
VMwareDriverException. Therefore, VimException, VimSessionOverLoadException,
VimConnectionException, VimAttributeException and ImageTransferException
are children of VMwareDriverException. Ideally, VMwareDriverException
should be renamed as ServiceException, but it will result in backward
incompatibility.
Change-Id: Ide1bf891be78766e8670f8446792e3dc9c7ec88f
This reverts commit 1668fef9cabea6a23023aab6b97617b4368b14d6
This is a backwards incompatible change, as we see with the
nova driver code that is expecting a VMwareDriverException
but is now getting back a VimFaultException because the unit
tests in nova were passing an unknown fault class name.
Change-Id: I0f8042c6e47f6eb9802e770ffb7d09bdbe57013b
Closes-Bug: #1459021
Currently VMwareDriverException is raised for unknown
VIM faults. Sometimes clients may need to handle such
faults. Therefore it is better if we throw
VimFaultException with the fault_list set to the relevant
VIM fault class name.
Change-Id: I34f84f3ea3f5f0d6878f1d4438cf25bf22f293fd
Concurrent VIM API invocations after session expiration would result
in concurrent login attempts. In such cases, if a login attempt is
made after a successful one, it would result in InvalidLogin. This
is because vCenter server won't allow login within an active session.
On the other hand, if two or more login attempts reach vCenter at
the same, it would result in session leak-- the last one returned
overwrite any of the previous sessions. This patch prevents the
race condition by making session creation synchronized and checking
for an active session before login attempt. We can also remove the
call to terminate previous session after login since a login is
attempted only if there is no active session.
Change-Id: Ib4ca3553ce14c80ab722092907d797767072741c
Closes-Bug: #1409014
Move the public API out of oslo.vmware to oslo_vmware. Retain the ability
to import from the old namespace package for backwards compatibility
for this release cycle.
bp/drop-namespace-packages
Change-Id: I11cf038c3832a7357ed53363d8ccf143daddd2a2