Xen deployments don't support qcow2 images which is what the
glance v2 API code in nova defaults to, so basically you can't
create a snapshot of a volume-backed instance with glance v2 and
Xen right now.
This change uses the glance v2 image schema to determine the
disk_format to use based on some rules:
1. Look for a preferred disk_format using an ordered list.
2. If we still can't figure it out, just use the first
supported disk_format available.
Change-Id: Ifaa150fda393e2b49114e30dd5e30e5bf52b4ed1
Closes-Bug: #1616938
generate_uuid method returns uuid as str so there is no need
to typecast it to str again.
TrivialFix
Change-Id: I1c9cb410a175249467c4934d6820f55a63aaed6a
This code has no unit tests, and all of its config options were
deprecated in Newton. As pointed out by Matt Riedemann, it's time for
this code to be removed if nobody has stepped up to make sure it is well
tested and functional. This also removes the last dependency on boto.
Change-Id: I60a304f242ce342d16b6465559b04194041ff240
internal_id attribute column from instances table is no
longer used. This commit removes internal_id from object
layer.
In the later release, this can be removed from schema
by adding migration script.
Change-Id: Ia285a16a8fab38a61959df847d30bce2d60ad081
Closes-Bug: #1441242
The oslo_db base class does not handle proper logging capture. This
inserts the correct capture before we setup those classes to prevent
leakage into the raw stdout stream which makes it confusing to read
test results.
Change-Id: If44c399e29373d2ef6bce6e1df5f96ed2caab462
This migration was added in mitaka and should have been done either in
mitaka or newton. Newton had some migrations that came after it which
were higher-visibility and should have forced everyone to have done
this by now.
Because of the nature of the migration, there isn't really an easy or
efficient way to validate that they have done this like we have done
for some other migrations.
Change-Id: Idb033e9e52b149372308eabb19c5774e10c56156
This makes the online_data_migrations command for nova-manage a little
more verbose in what it is doing. Each time it is run, it will show you
all the migrations that need running and how many records remain for
each. Basically, you run this until you see all zeroes.
Change-Id: I78c6312ec8e226a6ef9185382b6180f246f8fe84
The nova-manage tests used a large mix of output capture
techniques. monkey patching sys.stdout inside a test. Doing a direct
symbol replace of sys.stdout. Sometimes doing nothing, which meant the
output was going all the way to the test buffer.
This standardizes a model of doing creating a self.output during class
setup where output is expected, which is fixture monkey patched to
replace sys.stdout. It brings some consistency to the output handling,
as well as removes a large number of leaked through stdout lines that
were confusing in the test output stream.
Change-Id: Iff630e74bb86349c9ed9ae6b85c177948710f7c1
The db migration tests use a bunch of setup inside oslo_db that is
only exported as a base test class. This means that none of these do
the standard setup that the rest of the Nova tests do, including
things like logging capture.
Long term, the relationship between nova and oslo_db needs to be fixed
so that these are available as fixtures, not just base class. However,
in the short term we can setup logging correctly before initializing
the rest of the test class to keep these from scrambling the test
output.
Change-Id: I3c663d276cffa6146ac8f45bde7d70f7aece0c89
The way the hacking tests _run_check works, it ends up evaluating
python code in a context where all of our stdout capture has been
undone. The pep8 check_all method *also* prints out the errors found,
not only accumulating them for later. We can patch out the method
doing that to keep this from leaking through the test output, which
only causes confusion.
Change-Id: I9be4801352c4977504d95123d01bcbe309f22347
Our logging fixture sets up logging in a way that we need to capture
things during tests. However, some of our tests do things like call
back into main functions, which then call logging setup again, and
unwind everything we're doing (including debug message testing).
This patches out oslo_log setup after the fixture runs, thus ignoring
calls to it in the future. It removes a couple of scary looking stack
traces from the test stream that shouldn't be there.
Change-Id: Ie1b7d4370f20597961a841c5bc0a1ad7cc42b2ef
Support for specifying the scheduler driver via a full classpath was
deprecated in Mitaka, and with this patch is removed in Ocata.
Change-Id: I72e392aafa886ba19c874f1e0a0c95f6d1757ab9
This is the standardized way of explaining why an option was removed.
The 'deprecated_group' arguments are also removed as they name the same
group that the option is currently in thus making them superfluous.
Change-Id: I3040441470f0e2f2e53d26b980a0b6a48e41b1ea
Implements: blueprint centralize-config-options-ocata
Following OpenStack Style Guidelines[1]:
http://docs.openstack.org/developer/hacking/#unit-tests-and-assertraises
[H203] Unit test assertions tend to give better messages for more specific assertions.
As a result, assertIsNone(...) is preferred over assertEqual(None, ...) and assertIs(..,None)
Change-Id: I8881abed6e7962d1516323725e194937bce1346f
os_vif.initialize() was previously executed during module load. This
means it was entirely possible that it was run before things like
logging were actually set up in the expected way. Move this back into
execution time instead of load time to ensure that logging is actually
setup.
Changes need to be made to tests which make assumptions about os_vif
objects to manually initialize os_vif when it will be used. os_vif
objects can't be created until it is initialized, so some delayed
object creation is also done in test_vif.py.
Closes-Bug: #1615676
Change-Id: I89fe5c5b3d762f3a3238b587685df85d15ee56c4
Matt Riedemann