Open Stack

On 10/30/2017 11:28 PM, Matthew Thode wrote:
> 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
> 
> Meant to reply from this address, but below is my original response.
> 
> 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 .

Yes, an ironic installation can have all drivers enabled at the same time on the 
same conductor.

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