[openstack-dev] [glance][all] glance_store drivers deprecation/stabilization: Volunteers needed
flavio at redhat.com
Thu Dec 10 13:46:09 UTC 2015
As some of you know, there's a proposal (still a rough draft) for
refactoring the glance_store API. This library is the home for the
store drivers used by Glance to save or access the image data.
As other drivers in OpenStack, this library is facing the issue of
having unmaintained, untested and incomplete implementations of stores
that are, hypotetically, being used in production environments.
In order to guarantee some level of stability and, more important,
maintenance, the Glance team is looking for volunteers to sign up as
maintainers/keepers of the existing drivers.
Unfortunately, given the fact that our team is not as big as we would
like and that we don't have the knowledge to provide support for every
single driver, the Glance team will have to deprecate, and later
remove, the drivers that will remain without a maintainer.
Each driver will have to have a voting CI job running (maintained by
the driver maintainer) that will have to run Glance's functional tests
to ensure the API features are also supported by the driver.
There are 2 drivers I belive shouldn't fall into this category and
that should be maintained by the Glance community itself. These
Please, find the full list of drivers here and feel free to sign up
as volunteer in as many drivers as your time permits to maintain.
Please, provide all the information required as the lack of it will
result in the candidacy not being valid. As some sharp eyes will
notice, the Swift driver is not in the list above. The reason for that
is that, although it's a key piece of OpenStack, not everyone in the
Glance community knows the code of that driver well-enough and there
are enough folks that know it that could perhaps volunteer as
maintainers/reviewers for it. Furthermore, adding the swift driver
there would mean we should probably add the Cinder one as well as it's
part of OpenStack just like Swift. We can extend that list later. For
now, I'd like to focus on bringing some stability to the library.
The above information, as soon as it's complete or the due date is
reached, will be added to glance_store's docs so that folks know where
to find the drivers maintainers and who to talk to when things go
Here's an attempt to schedule some of this work (please refer to
this tag[0.1] and this soon-to-be-approved review[0.2] to have more
info w.r.t the deprecation times and backwards compatibility
- By mitaka 2 (Jan 16-22), all drivers should have a maintainer.
Drivers without one, will be marked as deprecated in Mitaka.
- By N-2 (schedule still not available), all drivers that were marked
as deprecated in Mitaka will be removed.
- By N-1 (schedule still not available), all drivers should have
support for the main storage capabilities, which are READ_ACCESS,
WRITE_ACCESS, and DRIVER_REUSABLE. Drivers that won't have support
for the main set of capabilities will be marked as deprecated and
then removed in O-1 (except for the HTTP one, which the team has
agreed on keeping as a read-only driver).
- By N-2 (schedule still not available), all drivers need to have a
voting gate. Drivers that won't have voting gates will be marked as
deprecated and then removed in O-1.
Although glance_store has intermediate releases, the above is being
planned based on the integrated release to avoid sudden "surprises"
on already released OpenStack versions.
Note that the above plan requires that the ongoing effort for setting
up a gate based on functional tests for glance_store will be
completed. There's enough time to get all this done for every driver.
In addition to the above, I'd like to note that we need to do this
*before* the refactor so that we can provide a minimum guarantee
that it won't break the existing contract. Furthermore, maintainers of
this drivers will be asked to help migrating their drivers to the new
API but that will follow a different schedule that needs to be
discussed in the spec itself.
This is, obviously, a multi-release effort that will require syncing
with future PTLs of the project.
One more thing. Note that the above work shouldn't distract the team
from the priorities we've scheduled for Mitaka. The requested
work/info should be simple enough to provide and work on without
distracting us. I'll take care of following-up and pinging some folks
Please, provide your feedback and/or concerns on the above plan,
More information about the OpenStack-dev