<html><body><p><font size="2">Thanks for Michael for raising this question and detailed information from Clark</font><br><br><font size="2">As indicated in the mail, xen, vmware etc might already have this kind of requirements (and I guess might be more than that) ,</font><br><font size="2">can we accept z/VM requirements first by following other existing ones then next I can create a BP later to indicate this kind </font><br><font size="2">of change request by referring to Clark's comments and submit patches to handle it ? Thanks</font><br><br><font size="2">Best Regards! <br><br>Kevin (Chen) Ji ¼Í ³¿<br><br>Engineer, zVM Development, CSTL<br>Notes: Chen CH Ji/China/IBM@IBMCN Internet: jichenjc@cn.ibm.com<br>Phone: +86-10-82451493<br>Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC </font><br><br><img width="16" height="16" src="cid:1__=8FBB08FEDFA26EFD8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Matt Riedemann ---04/12/2018 08:46:25 AM---On 4/11/2018 5:09 PM, Michael Still wrote: >"><font size="2" color="#424282">Matt Riedemann ---04/12/2018 08:46:25 AM---On 4/11/2018 5:09 PM, Michael Still wrote: ></font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Matt Riedemann <mriedemos@gmail.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">openstack-dev@lists.openstack.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">04/12/2018 08:46 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [openstack-dev] [Nova][Deployers] Optional, platform specific, dependancies in requirements.txt</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">On 4/11/2018 5:09 PM, Michael Still wrote:<br>> <br>> </font></tt><tt><font size="2"><a href="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=">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=</a></font></tt><tt><font size="2"> proposes adding a z/VM specific <br>> dependancy to nova's requirements.txt. When I objected the counter <br>> argument is that we have examples of windows specific dependancies <br>> (os-win) and powervm specific dependancies in that file already.<br>> <br>> I think perhaps all three are a mistake and should be removed.<br>> <br>> My recollection is that for drivers like ironic which may not be <br>> deployed by everyone, we have the dependancy documented, and then loaded <br>> at runtime by the driver itself instead of adding it to <br>> requirements.txt. This is to stop pip for auto-installing the dependancy <br>> for anyone who wants to run nova. I had assumed this was at the request <br>> of the deployer community.<br>> <br>> So what do we do with z/VM? Do we clean this up? Or do we now allow <br>> dependancies that are only useful to a very small number of deployments <br>> into requirements.txt?<br><br>As Eric pointed out in the review, this came up when pypowervm was added:<br><br></font></tt><tt><font size="2"><a href="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=">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=</a></font></tt><tt><font size="2"><br><br>And you're asking the same questions I did in there, which was, should <br>it go into test-requirements.txt like oslo.vmware and <br>python-ironicclient, or should it go under [extras], or go into <br>requirements.txt like os-win (we also have the xenapi library now too).<br><br>I don't really think all of these optional packages should be in <br>requirements.txt, but we should just be consistent with whatever we do, <br>be that test-requirements.txt or [extras]. I remember caring more about <br>this back in my rpm packaging days when we actually tracked what was in <br>requirements.txt to base what needed to go into the rpm spec, unlike <br>Fedora rpm specs which just zero out requirements.txt and depend on <br>their own knowledge of what needs to be installed (which is sometimes <br>lacking or lagging master).<br><br>I also seem to remember that [extras] was less than user-friendly for <br>some reason, but maybe that was just because of how our CI jobs are <br>setup? Or I'm just making that up. I know it's pretty simple to install <br>the stuff from extras for tox runs, it's just an extra set of <br>dependencies to list in the tox.ini.<br><br>Having said all this, I don't have the energy to help push for <br>consistency myself, but will happily watch you from the sidelines.<br><br>-- <br><br>Thanks,<br><br>Matt<br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></font></tt><tt><font size="2"><a href="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=">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=</a></font></tt><tt><font size="2"><br><br></font></tt><br><br><BR>
</body></html>