This removes use of some service calls in the conductor by xenapi's
host.py module and replaces them with object usage. Existing tests
are sufficient to confirm the same behavior remains.
Related to blueprint virt-objects-juno
Change-Id: I908cca4fa1d297c5c9b1d84ae7ebe7452a30ba12
This patch optimizes validate_networks so that it only queries neutron
when needed. Previously, this method would perform an additional net_list,
list_ports, and show_quota regardless if a request contains only
port_ids. If a request only contains port ids we do not need to check neutron
for quota as these ports are already allocated.
Change-Id: Ia7abc7d95b663f165fc95385dda3bab13b7a43e6
Closes-bug: #1291565
Moves the inner function "execute_create_vm" from the spawn method
to vm_util. Additionally, return the vm_ref after VM creation so
an extra call to retrieve the vm_ref does not need to take place
after the fact.
partial blueprint vmware-spawn-refactor
Co-authored-by: Tracy Jones <tjones@vmware.com>
Change-Id: I67c3c8c14b6c01b160611cc001d51f1da29ffb24
The root cause of the slow agent tests was not mocking this method:
compute_utils.add_instance_fault_from_exc
This cleans up the tests to share a bit more code, and ensures they
actually check that the appropriate exception is raised.
This change adds a log message to report errors that could occur in
running systems that also helped identify this issue in the unit tests.
test_spawn_fails_agent_not_implemented was a duplicate test and has been
removed.
Change-Id: I6fd31520fffd5e888ce0c2b58af2715f0d929ce1
Closes-Bug: #1279317
To actually check if a call was made, we should use
assert_called_once_with. assert_called_once is just a auto-spec'd
method and hence does not really check anything.
Change-Id: I21064dfca2a281683ee3b6ed4926f471bb74dbfa
The vCenter cluster will have multiple hosts.
The cluster does not have a uptime feature.
Returning uptime of one of the host/longest
running host, can be misleading to the user.
Hence raising NotImplementedError
Closes-Bug:#1313375
Change-Id: I70e5ab35b8944abd7b874762de2af5b01d6a7313
Removes the local method 'wrap_check_security_groups_policy' to
the module neutron_driver.py - This method is already defined
in compute_api.
Change-Id: I008326f7b77515a0fc878befe45fe705420835ad
Closes-Bug: #1314548
Our translation policy
(https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation) calls
for not translating debug level logs. This is to help prioritize log
translation. Furthermore translation has a performance overhead, even if
the log isn't used (since nova doesn't support lazy translation yet).
Change-Id: Id270b6c7e020679c3e2e3931300e82ea3489e942
Our translation policy
(https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation) calls
for not translating debug level logs. This is to help prioritize log
translation. Furthermore translation has a performance overhead, even if
the log isn't used (since nova doesn't support lazy translation yet).
Change-Id: Idb346d04f24cbbc19b6e41af6e4782ac1c49d3b8
The fake networks use a pre-serialized timestamp in str(datetime)
format which which doesn't give us the opportunity to test the
serialization code properly and isn't the format use in practice.
Use real dateime objects instead.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: I5cbe722fb59cdd326b4c75dcfea14f206d71f668
The stubbed out volumes methods returns a volume object with a
pre-serialized datetime object which doesn't give us the opportunity
to test the serialization code properly. Use a real object instead.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: Ie54a3deaf1c32f3e57d03737e9ea1e9dd66a98d8
We format these timestamps using timeutils.isotime() in the cloudpipe
API extension, so we should check that in the API sample tests rather
than using the generic timestamp regexp.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: I52543f68a512da4064a905e2efa453425ce36dae
We format these timestamps using timeutils.isotime() in the limits
view builder, so we should check that in the API sample tests rather
than using the generic timestamp regexp.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: I14bf2eccec38f271eec8d97e8dca6d46f9d93cb3
We format these timestamps using timeutils.isotime() in the server
view builder, so we should check that in the API sample tests rather
than using the generic timestamp regexp.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: Id55f13d8163249275220151dd88c67b47e6176c9
The 2011-01-01T01:02:03Z is seen throughout the images API sample
tests because it is hard-coded in the fake image service. In some
of the API templates, we include the timestamp rather than matching
against a regexp but in many we don't. Let's consistently match
against the actual timestamp we know to expect.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: I727c0aabac0e32b435068c37d535daa8c983364c
It's unusual to include a '+00:00' offset in an ISO8601 timestamp
rather than just using the 'Z' suffix. It's also very weird for our
API to be returning timestamps which aren't in UTC.
Let's make these timestamps consistent with other timestamps by
using UTC always and representing that with a 'Z' suffix. Also,
enforce this in the API sample tests by using a new 'isotime' regexp.
A small number of the extensions in the API sample templates
specified the exact timestamp, so templatize those before regenerating
the API samples for GET /extensions.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: Idf429e55e4ae13738ac531a25ce54b20d395410d
In a subsequent commit, I make a change which requires regenerating
this API sample but doing so shows up a bunch of unrelated changes.
This commit simply regenerates the API sample without any functional
changes to highlight the non-functional sample changes.
Change-Id: I5fafff90f20af17d787039568245f598e500405e
Dan Smith