You may have noticed a giant patch series up:
It's a big beastie, so I thought a synopsis of what's going would be
useful. Also, there's a pile of patches towards the end that we want to
squash before landing but which have been pushed up in smaller patches
because reading it all as one patch would be unpossible - but reworking
the unittest mocks for each step would be wasted energy.
Any of the patches in this email that are green from Zuul are ready for
The easy patches:
These next patches are easy because they're just mechanical - nothing
really will have changed in SDK because of them.
https://review.openstack.org/#/c/518128 - Merge shade and
os-client-config into the tree
You can't see the whole picture in gerrit. This merges in shade and
os-client-config, including their entire git history. Most of that merge
got pushed up to a throwaway branch so that the review in gerrit would
be a single patch containing the merge. It's best to just grab the repo
at that branch and take a look.
It's also important to note here that I'm pretty sure openstack.cloud is
not actually where shade wants to live and that openstack.config needs a
refactor - but we can do that after this stack, as the stack is too big
https://review.openstack.org/#/c/518129/ - Merge in recent fixes from
the shade repo
Merges patches that already landed in shade between the time I made the
first merge commit and proposed it. No need to actually review the
https://review.openstack.org/#/c/518130 - Add jobs for Zuul v3
Adds functional zuulv3 native test jobs that match what shade was doing.
These run both shade and sdk's functional tests (they're one set of tests)
https://review.openstack.org/#/c/518946 - Fix magnum functional test
Fixes the previous one.
https://review.openstack.org/#/c/518131 - Handle glance image pagination
https://review.openstack.org/#/c/518132 - Fix regression for
https://review.openstack.org/#/c/518133 - Support filtering servers in
list_servers using arbitrary parameters
Patches landed in shade in the interim. No need to review content.
Once those are landed we're ready for some fun:
https://review.openstack.org/#/c/518799 - Migrate to testtools for
Reworks the functional base class to use the testtools based functional
base class from shade, along with the logger fakes and whatnot. The
biggest change here is the move to using setUp/tearDown instead of
This patch is annoyingly large, but it's also important so that we have
one consistent approach to these things across the combined codebase.
https://review.openstack.org/#/c/519029 - Rework config and rest layers
The squahsed/rollup patch. It can be viewed broken out by looking at the
other patches that have https://review.openstack.org/#/c/518799 as a parent.
This is where all of the invasive breaking-changes happen. Most notably
stepping away from Profile, Session and Authenticator in favor of using
openstack.config/os-client-config and the Adapter class from
keystoneauth so that we can rely on ksa for discovery and whatnot. It
also adds a pure-rest interface on each service, removes the plugin
entrypoints structure and and renames 4 of the service objects to match
their official service-type (although it also keeps aliases so that
shouldn't cause too much carnage for people)
Removal of profile/authenticator is the biggest user-visible breaking
change, and it's not ACTUALLY removed in this patch (although it was at
one point) We have to keep Profile around long enough to remove its use
from OSC - including osc3, since OSC is used to set up resources as part
of devstack. It might be worthwhile to consider fleshing out the
backwards compat for allowing profiles to be passed in for a short time
since it's there now.
There's still a little more plumbing to do before we can start working
on using this layer under the shade code - most notably we need to plumb
in the task manager ... but to my knowledge this stack works with Dean's
OSC4 branch so we should be in good shape.
https://review.openstack.org/#/c/501438 - Add notes about moving forward
A document with some thoughts - some of which are a good idea and some
not - about next steps and what we need to get done.
Thanks for the patience in reading these ... they're SUPER long. In many
cases it's about letting the test suites let us know they're ok.
OpenStack Development Mailing List (not for usage questions)