<div dir="ltr">I don't understand why you think the alternative is so hard. Here's how ironic does it:<div><br></div><div>
<span></span>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12px;line-height:normal;font-family:"Courier New";color:rgb(244,244,244);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures"><span class="gmail-Apple-converted-space"> </span>global ironic</span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12px;line-height:normal;font-family:"Courier New";color:rgb(244,244,244);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures"><span class="gmail-Apple-converted-space"> </span>if ironic is None:</span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12px;line-height:normal;font-family:"Courier New";color:rgb(244,244,244);background-color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures"><span class="gmail-Apple-converted-space"> </span>ironic = importutils.import_module('ironicclient')</span></p>
<br></div><div>Is avoiding three lines of code really worth making future cleanup harder? Is a three line change really blocking "an approved blueprint with ready code"?<br><br></div><div>Michael</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 12, 2018 at 10:42 PM, Eric Fried <span dir="ltr"><<a href="mailto:openstack@fried.cc" target="_blank">openstack@fried.cc</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1<br>
<br>
This sounds reasonable to me. I'm glad the issue was raised, but IMO it<br>
shouldn't derail progress on an approved blueprint with ready code.<br>
<br>
Jichen, would you please go ahead and file that blueprint template (no<br>
need to write a spec yet) and link it in a review comment on the bottom<br>
zvm patch so we have a paper trail? I'm thinking something like<br>
"Consistent platform-specific and optional requirements" -- that leaves<br>
us open to decide *how* we're going to "handle" them.<br>
<br>
Thanks,<br>
efried<br>
<span class=""><br>
On 04/12/2018 04:13 AM, Chen CH Ji wrote:<br>
> Thanks for Michael for raising this question and detailed information<br>
> from Clark<br>
><br>
> As indicated in the mail, xen, vmware etc might already have this kind<br>
> of requirements (and I guess might be more than that) ,<br>
> can we accept z/VM requirements first by following other existing ones<br>
> then next I can create a BP later to indicate this kind<br>
> of change request by referring to Clark's comments and submit patches to<br>
> handle it ? Thanks<br>
><br>
> Best Regards!<br>
><br>
> Kevin (Chen) Ji 纪 晨<br>
><br>
> Engineer, zVM Development, CSTL<br>
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: <a href="mailto:jichenjc@cn.ibm.com">jichenjc@cn.ibm.com</a><br>
> Phone: +86-10-82451493<br>
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian<br>
> District, Beijing 100193, PRC<br>
><br>
</span><span class="">> Inactive hide details for Matt Riedemann ---04/12/2018 08:46:25 AM---On<br>
> 4/11/2018 5:09 PM, Michael Still wrote: >Matt Riedemann ---04/12/2018<br>
> 08:46:25 AM---On 4/11/2018 5:09 PM, Michael Still wrote: ><br>
><br>
> From: Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>><br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
> Date: 04/12/2018 08:46 AM<br>
> Subject: Re: [openstack-dev] [Nova][Deployers] Optional, platform<br>
> specific, dependancies in requirements.txt<br>
><br>
</span>> ------------------------------<wbr>------------------------------<wbr>------------<br>
<div><div class="h5">><br>
><br>
><br>
> On 4/11/2018 5:09 PM, Michael Still wrote:<br>
>><br>
>><br>
> <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=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__review.<wbr>openstack.org_-23_c_523387&d=<wbr>DwIGaQ&c=jf_iaSHvJObTbx-<wbr>siA1ZOg&r=8sI5aZT88Uetyy_<wbr>XsOddbPjIiLSGM-sFnua3lLy2Xr0&<wbr>m=<wbr>212PUwLYOBlJZ3BiZNuJIFkRfqXoBP<wbr>JDcWYCDk7vCHg&s=<wbr>CNosrTHnAR21zOI52fnDRfTqu2zPiA<wbr>n2oW9f67Qijo4&e=</a> proposes<br>
> 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>
> <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=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__review.<wbr>openstack.org_-23_c_438119_5_<wbr>requirements.txt&d=DwIGaQ&c=<wbr>jf_iaSHvJObTbx-siA1ZOg&r=<wbr>8sI5aZT88Uetyy_XsOddbPjIiLSGM-<wbr>sFnua3lLy2Xr0&m=<wbr>212PUwLYOBlJZ3BiZNuJIFkRfqXoBP<wbr>JDcWYCDk7vCHg&s=iyKxF-<wbr>CcGAFmnQs8B7d5u2zwEiJqq8ivETmr<wbr>gB77PEg&e=</a><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>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <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=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__lists.<wbr>openstack.org_cgi-2Dbin_<wbr>mailman_listinfo_openstack-<wbr>2Ddev&d=DwIGaQ&c=jf_<wbr>iaSHvJObTbx-siA1ZOg&r=<wbr>8sI5aZT88Uetyy_XsOddbPjIiLSGM-<wbr>sFnua3lLy2Xr0&m=<wbr>212PUwLYOBlJZ3BiZNuJIFkRfqXoBP<wbr>JDcWYCDk7vCHg&s=<wbr>2FioyzCRtztysjjEqCrBTkpQs_<wbr>wwfs3Mt2wGDkrft-s&e=</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
</div></div>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<span class="">><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
</span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div>