[openstack-dev] [glance] Removing python-swiftclient from requirements.txt

William M Edmonds edmondsw at us.ibm.com
Tue Jul 28 22:34:29 UTC 2015


> From: Flavio Percoco <flavio at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 07/28/2015 07:36 AM
> Subject: Re: [openstack-dev] [glance] Removing python-swiftclient
> from requirements.txt
>
> On 28/07/15 09:15 +0000, Kuvaja, Erno wrote:
> >I do agree, we don’t depend or are cleaning the other clients out
> of the glance
> >dependencies as well and I think swift should not be there either.
> >
> >
> >
> >The default store is filesystem store and if something is depending on
the
> >actual store clients it should be either glance_store or deployer (well
for
> >example our gate) glance itself should not have hard dependencies for
‘em.
>
> Agreed!
>
> William, would it be possible for you to spend some more time and
> create a single patch that removes all non-required dependencies?
>
> Cheers,
> Flavio
>

This all started when I opened a bug [1] saying we needed to pull out
oslo.vmware. Louis quickly threw up a patch [2] to remove that, but it was
pointed out that swiftclient falls into the same category. So I created a
separate patch to remove swiftclient [3]. Looking over what else is in
requirements.txt and running a few searches, it looks like we may also be
able to remove greenlet, kombu, and posix-ipc. Does anyone know if any of
those (greenlet?) are needed for some reason other than a direct import? In
which case I can add a comment to clarify that while I'm removing the
others.

I'd originally included the removal of oslo.vmware in [3], but I pulled
that out thinking we could go ahead and merge [2] while we were having this
discussion. But that didn't seem to fly, so I guess we want to make all
these changes together under [3] and abandon [2]? Or should we go ahead and
merge [2] while we're figuring out whether to remove greenlet, kombu, and
posix-ipc as well under [3]?

Just to be clear, it sounds to me like Flavio and Erno agree we should pull
swiftclient out of requirements.txt immediately. I'd like to see a reply
from Ian and Louis to round things out, make sure we're all on the same
page and we won't be fighting over this in the review...

[1] https://launchpad.net/bugs/1475737
[2] https://review.openstack.org/#/c/203200/
[3] https://review.openstack.org/#/c/203242/

> >
> >
> >
> >-          Erno
> >
> >
> >
> >From: William M Edmonds [mailto:edmondsw at us.ibm.com]
> >Sent: Monday, July 27, 2015 10:42 PM
> >To: openstack-dev at lists.openstack.org
> >Subject: [openstack-dev] [glance] Removing python-swiftclient from
> >requirements.txt
> >
> >
> >
> >python-swiftclient is only needed by operators that are using the swift
> >backend, so it really doesn't belong in requirements.txt. Listing it in
> >requirements forces all operators to install it, even if they're not
going to
> >use the swift backend. When I proposed a change [1] to move this from
> >requirements to test-requirements (would still be needed there
> because of tests
> >using the swift backend), others raised concerns about the impact this
could
> >have on operators who use the swift backend today and would be upgrading
to
> >Liberty. I believe everyone agreed this should not be in
> requirements, but the
> >fact is that it has been, so operators may have (incorrectly) been
> depending on
> >that during upgrades. If we remove it in Liberty, and there are changes
in
> >Liberty that require a newer version of swiftclient, how would
> those operators
> >know that they need to upgrade swiftclient?
> >
> >The optional dependencies spec [2] could definitely help here. I
> don't think we
> >should have to wait for that, though. This is an issue we obviously
already
> >have today for other backends, which indicates folks can deal with it
without
> >an optional dependencies implementation.
> >
> >This would be a new concern for operators using the default swift
backend,
> >though. So how do we get the message out to those operators? And dowe
need to
> >put out a message about this change in Liberty and then wait until
Mitaka to
> >actually remove this, or can we go ahead and remove in Liberty?
> >
> >[1] https://review.openstack.org/#/c/203242
> >[2] http://specs.openstack.org/openstack/oslo-specs/specs/liberty/
> >optional-deps.html
> >
> >-Matthew
> >
>
>
>__________________________________________________________________________
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> @flaper87
> Flavio Percoco
> [attachment "attdy18a.dat" deleted by William M Edmonds/Raleigh/IBM]
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150728/ddef31d6/attachment.html>


More information about the OpenStack-dev mailing list