mordred Queens shade PTL candidacy
Change-Id: I1bacc2a5ea98a2027ce2faa93ce072a466c8aaaf
This commit is contained in:
parent
7000770a70
commit
2af2687f35
52
candidates/queens/Shade/mordred.txt
Normal file
52
candidates/queens/Shade/mordred.txt
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
I would like to be the PTL of the shade project for another cycle.
|
||||||
|
|
||||||
|
Over the past few years the shade project has grown from a utility library
|
||||||
|
containing some logic needed by the Infrastructure team and Ansible for
|
||||||
|
interacting with OpenStack clouds to a rich SDK that serves the general needs
|
||||||
|
of humans who want to use OpenStack.
|
||||||
|
|
||||||
|
This past cycle we (mostly) accomplished two main goals that were not exciting
|
||||||
|
features but which are immensely important nonetheless. We ported our unittests
|
||||||
|
to use requests-mock instead of mocking out individual python client libraries,
|
||||||
|
and we replaced our use of the python client libraries with direct REST calls
|
||||||
|
based on keystoneauth. This was rather mind-numbing and I fear we may have
|
||||||
|
eaten the brains of a few wonderful contributors - but it means that our
|
||||||
|
dependency chain is much slimmer so inclusion in distros and alongside apps
|
||||||
|
should be less costly.
|
||||||
|
|
||||||
|
We still need to finish converting the last keystoneclient calls and to
|
||||||
|
transition the Ironic calls. TheJulia did WAY too good of a job writing tests
|
||||||
|
when implemeting Ironic support originally, so it may take a little while to
|
||||||
|
finish that one.
|
||||||
|
|
||||||
|
Over the next cycle we need to update our REST layer to incorporate the recent
|
||||||
|
changes made in keystoneauth related to service and version discovery. This
|
||||||
|
largely means removing code, which is always pleasant. Once that's done we'll
|
||||||
|
be in a position to start using microversions as appropriate.
|
||||||
|
|
||||||
|
Glance has landed experimental support for the new Image upload process, and
|
||||||
|
we need to add detection and implementation of that to our Image upload system
|
||||||
|
so that we'll use it when it's available.
|
||||||
|
|
||||||
|
There is some very important work we need to do deep in the guts related to
|
||||||
|
caching and batching of calls. We have a system for this that is designed to
|
||||||
|
ensure that large-scale systems such as Nodepool can operate effectively, but
|
||||||
|
it's proving costly for smaller users and needs to be optimized.
|
||||||
|
|
||||||
|
I recently suggested merging the work of the python-openstacksdk team into
|
||||||
|
shade. If we decide as a larger OpenStack community that this is a direction
|
||||||
|
we want to go, we'll need to do a decent amount of plumbing to ensure that's
|
||||||
|
as smooth as possible for both sets of users.
|
||||||
|
|
||||||
|
Finally, I think if we don't make some forward progress on the oaktree gRPC
|
||||||
|
federation API that samueldmq will be very unhappy with me. We've been
|
||||||
|
explicitly putting off working on that to ensure we get the RESTification work
|
||||||
|
done. This next cycle I expect to make real progress on that so that we can
|
||||||
|
at least have a proof point to look at so we can discuss a real thing rather
|
||||||
|
than a theory.
|
||||||
|
|
||||||
|
I'm proud of what we've done so far, and I think there is a ton we can continue
|
||||||
|
to do to serve OpenStack End Users well.
|
||||||
|
|
||||||
|
Thank you for your consideration,
|
||||||
|
Monty
|
Loading…
Reference in New Issue
Block a user