I don't think it affects containers directly. Depending on how you build containers you may have to do nothing (if you use package, for example) or update your pip install to do a different thing (or things).

On 10/30/2017 09:48 PM, arkady.kanev...@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:d...@doughellmann.com]
Sent: Monday, October 30, 2017 2:47 PM
To: openstack-dev <openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to