On 04/12/2018 07:42 AM, Eric Fried wrote:
+1
This sounds reasonable to me. I'm glad the issue was raised, but IMO it
shouldn't derail progress on an approved blueprint with ready code.
The one thing I will note, because we're dealing with it in
oslo.messaging right now, is that there's no clear path to removing a
requirement from the unconditional list and moving it to extras. There
isn't really a deprecation method for requirements where we can notify
users that they'll need to start installing things with [zvm] or
whatever added as extras.
Our current approach in oslo.messaging is to leave the existing
requirements and add new ones as extras. It's not perfect (someone
using kafka doesn't need the rabbit deps, but they'll still get them),
but it's a step in the right direction.
Jichen, would you please go ahead and file that blueprint template (no
need to write a spec yet) and link it in a review comment on the bottom
zvm patch so we have a paper trail? I'm thinking something like
"Consistent platform-specific and optional requirements" -- that leaves
us open to decide *how* we're going to "handle" them.
Thanks,
efried
On 04/12/2018 04:13 AM, Chen CH Ji wrote:
Thanks for Michael for raising this question and detailed information
from Clark
As indicated in the mail, xen, vmware etc might already have this kind
of requirements (and I guess might be more than that) ,
can we accept z/VM requirements first by following other existing ones
then next I can create a BP later to indicate this kind
of change request by referring to Clark's comments and submit patches to
handle it ? Thanks
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
District, Beijing 100193, PRC
Inactive hide details for Matt Riedemann ---04/12/2018 08:46:25 AM---On
4/11/2018 5:09 PM, Michael Still wrote: >Matt Riedemann ---04/12/2018
08:46:25 AM---On 4/11/2018 5:09 PM, Michael Still wrote: >
From: Matt Riedemann <mriede...@gmail.com>
To: openstack-dev@lists.openstack.org
Date: 04/12/2018 08:46 AM
Subject: Re: [openstack-dev] [Nova][Deployers] Optional, platform
specific, dependancies in requirements.txt
------------------------------------------------------------------------
On 4/11/2018 5:09 PM, Michael Still wrote:
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_523387&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg&s=CNosrTHnAR21zOI52fnDRfTqu2zPiAn2oW9f67Qijo4&e=
proposes
adding a z/VM specific
dependancy to nova's requirements.txt. When I objected the counter
argument is that we have examples of windows specific dependancies
(os-win) and powervm specific dependancies in that file already.
I think perhaps all three are a mistake and should be removed.
My recollection is that for drivers like ironic which may not be
deployed by everyone, we have the dependancy documented, and then loaded
at runtime by the driver itself instead of adding it to
requirements.txt. This is to stop pip for auto-installing the dependancy
for anyone who wants to run nova. I had assumed this was at the request
of the deployer community.
So what do we do with z/VM? Do we clean this up? Or do we now allow
dependancies that are only useful to a very small number of deployments
into requirements.txt?
As Eric pointed out in the review, this came up when pypowervm was added:
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_438119_5_requirements.txt&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg&s=iyKxF-CcGAFmnQs8B7d5u2zwEiJqq8ivETmrgB77PEg&e=
And you're asking the same questions I did in there, which was, should
it go into test-requirements.txt like oslo.vmware and
python-ironicclient, or should it go under [extras], or go into
requirements.txt like os-win (we also have the xenapi library now too).
I don't really think all of these optional packages should be in
requirements.txt, but we should just be consistent with whatever we do,
be that test-requirements.txt or [extras]. I remember caring more about
this back in my rpm packaging days when we actually tracked what was in
requirements.txt to base what needed to go into the rpm spec, unlike
Fedora rpm specs which just zero out requirements.txt and depend on
their own knowledge of what needs to be installed (which is sometimes
lacking or lagging master).
I also seem to remember that [extras] was less than user-friendly for
some reason, but maybe that was just because of how our CI jobs are
setup? Or I'm just making that up. I know it's pretty simple to install
the stuff from extras for tox runs, it's just an extra set of
dependencies to list in the tox.ini.
Having said all this, I don't have the energy to help push for
consistency myself, but will happily watch you from the sidelines.
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg&s=2FioyzCRtztysjjEqCrBTkpQs_wwfs3Mt2wGDkrft-s&e=
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
