settingsLogin | Registersettings

[openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

0 votes

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?

[1] https://github.com/openstack/ironic/blob/master/driver-requirements.txt
[2] https://github.com/openstack/python-ironicclient/blob/master/setup.cfg#L115


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 1, 2017 in openstack-dev by Dmitry_Tantsur (18,080 points)   2 3 4

13 Responses

0 votes

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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 15, 2017 by Dmitry_Tantsur (18,080 points)   2 3 4
0 votes

On 10/31/2017 12:11 AM, Richard.Pioso@dell.com wrote:

From: Dmitry Tantsur [mailto:dtantsur@redhat.com]

Cons:
1. more work for both the requirements team and the vendor teams

Please elaborate on the additional work you envision for the vendor teams.

Any requirements updates with have to be submitted to the requirements repo. It
may take longer (may not).

  1. inability to use ironic release notes to explain driver requirements changes

Where could that information move to?

I think it's a generic question, to be honest. We don't inform operators of
requirements changes via release notes. I don't have an easy answer.

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?

Overall, a big +1. I prefer the second approach.

A couple of questions ...

  1. If two (2) hardware types have the same requirement, would they both
    enter it in their lists?

Yes

  1. And would that be correctly handled?

Tony checked it (see his response to this thread) - yes.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 15, 2017 by Dmitry_Tantsur (18,080 points)   2 3 4
0 votes

On 17-11-15 09:32:33, Dmitry Tantsur wrote:
On 10/31/2017 12:11 AM, Richard.Pioso@dell.com wrote:

From: Dmitry Tantsur [mailto:dtantsur@redhat.com]

Cons:
1. more work for both the requirements team and the vendor teams

Please elaborate on the additional work you envision for the vendor teams.

Any requirements updates with have to be submitted to the requirements repo.
It may take longer (may not).

We (requirements) are prety good about being on top of reviews :P

  1. inability to use ironic release notes to explain driver requirements changes

Where could that information move to?

I think it's a generic question, to be honest. We don't inform operators of
requirements changes via release notes. I don't have an easy answer.

Should each driver have it's own release notes then? Not sure if that'd help.

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?

Overall, a big +1. I prefer the second approach.

A couple of questions ...

  1. If two (2) hardware types have the same requirement, would they both
    enter it in their lists?

Yes

  1. And would that be correctly handled?

Tony checked it (see his response to this thread) - yes.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Matthew Thode (prometheanfire)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Nov 15, 2017 by prometheanfire_at_ge (6,880 points)   1 3 5
...