[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