[openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?
Matthew Thode
mthode at mthode.org
Mon Oct 30 22:00:41 UTC 2017
On 17-10-30 20:48:37, Arkady.Kanevsky at dell.com wrote:
> The second seem to be better suited for per driver requirement handling and per HW type per function.
> Which option is easier to handle for container per dependency for the future?
>
>
> Thanks,
> Arkady
>
> -----Original Message-----
> From: Doug Hellmann [mailto:doug at doughellmann.com]
> Sent: Monday, October 30, 2017 2:47 PM
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?
>
> Excerpts from Dmitry Tantsur's message of 2017-10-30 17:51:49 +0100:
> > Hi all,
> >
> > So far driver requirements [1] have been managed outside of global-requirements.
> > This was mostly necessary because some dependencies were not on PyPI.
> > This is no longer the case, and I'd like to consider managing them
> > just like any other dependencies. Pros:
> > 1. making these dependencies (and their versions) more visible for
> > packagers 2. following the same policies for regular and driver
> > dependencies 3. ensuring co-installability of these dependencies with
> > each other and with the remaining openstack 4. potentially using
> > upper-constraints in 3rd party CI to test what packagers will probably
> > package 5. we'll be able to finally create a tox job running unit
> > tests with all these dependencies installed (FYI these often breaks in
> > RDO CI)
> >
> > Cons:
> > 1. more work for both the requirements team and the vendor teams 2.
> > inability to use ironic release notes to explain driver requirements
> > changes 3. any objections from the requirements team?
> >
> > If we make this change, we'll drop driver-requirements.txt, and will
> > use setuptools extras to list then in setup.cfg (this way is supported
> > by g-r) similar to what we do in ironicclient [2].
> >
> > We either will have one list:
> >
> > [extras]
> > drivers =
> > sushy>=a.b
> > python-dracclient>=x.y
> > python-prolianutils>=v.w
> > ...
> >
> > or (and I like this more) we'll have a list per hardware type:
> >
> > [extras]
> > redfish =
> > sushy>=a.b
> > idrac =
> > python-dracclient>=x.y
> > ilo =
> > ...
> > ...
> >
> > WDYT?
>
> The second option is what I would expect.
>
> Doug
>
> >
> > [1]
> > https://github.com/openstack/ironic/blob/master/driver-requirements.tx
> > t [2]
> > https://github.com/openstack/python-ironicclient/blob/master/setup.cfg
> > #L115
> >
>
> __________________________________________________________________________
> 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
The first question I have is if ALL the drivers are suposed to be co-installable
with eachother. If so, adding them to requirements sounds fine, as long as each
one follows https://github.com/openstack/requirements/#for-new-requirements .
As far as the format, I prefer option 2 (the breakout option). I'm not sure if
the bot will need an update, but I suspect not as it tries to keep ordering iirc.
--
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171030/92dee24c/attachment.sig>
More information about the OpenStack-dev
mailing list