Open Stack

I don't understand why you think the alternative is so hard. Here's how
ironic does it:

        global ironic

        if ironic is None:

            ironic = importutils.import_module('ironicclient')

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"?

Michael



On Thu, Apr 12, 2018 at 10:42 PM, Eric Fried <openstack at fried.cc> 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.
>
> 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 at IBMCN Internet: jichenjc at 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 <mriedemos at gmail.com>
> > To: openstack-dev at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180413/18110e24/attachment.html>