Open Stack

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.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
>