Open Stack

Excerpts from William M Edmonds's message of 2015-07-28 18:34:29 -0400:
> 
> > 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...

I replied on both patches, but I'll repeat it here for a broader
audience:

Please set up an "extras" entry for each backend instead of just
removing the dependencies.  That will signal to users that you know
what dependencies there are for a backend, but that they are optional,
and still allow someone to do the equivalent of "pip install
glance[vmware]" or "pip install glance[swift]" to get those
dependencies.  Nova and oslo.versionedobjects have examples in their
setup.cfg if you need a template.

I didn't mention in the reviews, but this will also make integration
tests in our gate easier, since you can put ".[vmware]" or ".[swift]" in
the tox.ini to pull in those dependencies.

Doug

> 
> [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]
> >