Excerpts from William M Edmonds's message of 2015-07-28 18:34:29 -0400: > > > From: Flavio Percoco <fla...@redhat.com> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <openstack-dev@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:edmon...@us.ibm.com] > > >Sent: Monday, July 27, 2015 10:42 PM > > >To: openstack-dev@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
