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

2017-11-15 Thread Matthew Thode
On 17-11-15 09:32:33, Dmitry Tantsur wrote:
> On 10/31/2017 12:11 AM, richard.pi...@dell.com wrote:
> > > From: Dmitry Tantsur [mailto:dtant...@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

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

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature
__
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


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

2017-11-15 Thread Dmitry Tantsur

On 10/31/2017 12:11 AM, richard.pi...@dell.com wrote:

From: Dmitry Tantsur [mailto:dtant...@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).





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


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


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

2017-11-15 Thread Dmitry Tantsur
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 
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


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

2017-11-15 Thread Dmitry Tantsur

On 10/30/2017 11:28 PM, Matthew Thode wrote:

On 17-10-30 20:48:37, 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 
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


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


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

2017-10-31 Thread Tony Breeds
On Mon, Oct 30, 2017 at 08:07:10PM -0400, Doug Hellmann wrote:
> Excerpts from Richard.Pioso's message of 2017-10-30 23:11:31 +:
> > 2. And would that be correctly handled?
> 
> Good question. We should test the requirements update script to see.

It does.  I did a quick fictional test:

This:
---
diff --git a/setup.cfg b/setup.cfg
index 6c3242535..01469c39f 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -25,6 +25,11 @@ packages =
 ironic
 ironic_tempest_plugin
 
+[extras]
+redfish1 =
+  sushy>=0.0.9 # Apache-2.0
+redfish2 =
+  sushy>=0.0.10 # Apache-2.0
 [entry_points]
 oslo.config.opts =
 ironic = ironic.conf.opts:list_opts
---
Becomes:
---
 [extras]
 redfish1 =
-  sushy>=0.0.9 # Apache-2.0
+  sushy>=0.1.0 # Apache-2.0
 redfish2 =
-  sushy>=0.0.10 # Apache-2.0
+  sushy>=0.1.0 # Apache-2.0
---

After running the bot

Yours Tony.


signature.asc
Description: PGP signature
__
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


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

2017-10-31 Thread Tony Breeds
On Mon, Oct 30, 2017 at 05:51:49PM +0100, Dmitry Tantsur wrote:
> 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

The biggest impact on the requirements team is the initial review to
validate that the driver library meets all the criteria [1]

There are 11 requirements in driver-requirements.txt 8 would be new.

I haven't done a review but there is a non-zero chance one of these 8
could be rejected.  At that point you're half in/out and that leaves
ironic in an awkward place.

> 2. inability to use ironic release notes to explain driver requirements 
> changes

You can still do this, it's just harder because you don't have a single
point where the updates are happening.  At the moment when a change is
proposed to modify driver-requirements you can reject the change until
it has a release note.  Now you'd need to check at release time if a
release note was added.

We can probably come up with a compromise solution.  Perhaps annotate
global requirements like:
---
# sushy is used by ironic-drivers check for release note
sushy>=0.1.0
---

Then in theory the requirements team could defer the change until it
depends on a merged release note in ironic?  It isn't 100% human proof.

I haven't really thought about it though ...

> 3. any objections from the requirements team?

No objection from me but see the points above.
 
> 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 =
>   ...
> ...

This one please.

Yours Tony.

[1] http://git.openstack.org/cgit/openstack/requirements/tree/README.rst#n265


signature.asc
Description: PGP signature
__
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


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

2017-10-31 Thread Mike Perez
On 17:51 Oct 30, Dmitry Tantsur wrote:
> 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)

I noticed Cinder is doing this with drivers, but in a different file:

http://git.openstack.org/cgit/openstack/cinder/tree/driver-requirements.txt

-- 
Mike Perez


pgpjj5AdeWm9b.pgp
Description: PGP signature
__
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


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

2017-10-31 Thread Pavlo Shchelokovskyy
On Mon, Oct 30, 2017 at 9:46 PM, Doug Hellmann 
wrote:

> 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.
>
>
I also would prefer option 2 (per driver extras), with a catch-all [all]
extra to install all of those in one short command

I have a separate concern about ansible-deploy interface. It obviously
depends on Ansibe, but so does most of upstream infra. I am not sure if
adding  (somehow restricted) Ansible to g-r won't break anything.

Doug
>
> >
> > [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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
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


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

2017-10-30 Thread Doug Hellmann
Excerpts from Richard.Pioso's message of 2017-10-30 23:11:31 +:
> > From: Dmitry Tantsur [mailto:dtant...@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.
> 
> > 2. inability to use ironic release notes to explain driver requirements 
> > changes
> 
> Where could that information move to?
> 
> > 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.

> 2. And would that be correctly handled?

Good question. We should test the requirements update script to see.

Doug

__
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


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

2017-10-30 Thread Richard.Pioso
> From: Dmitry Tantsur [mailto:dtant...@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.

> 2. inability to use ironic release notes to explain driver requirements 
> changes

Where could that information move to?

> 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?
2. And would that be correctly handled?
__
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


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

2017-10-30 Thread Matthew Thode
On 17-10-30 20:48:37, 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 
> 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

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 .

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 (prometheanfire)


signature.asc
Description: PGP signature
__
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


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

2017-10-30 Thread Matthew Thode
On 17-10-30 20:48:37, 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 
> 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

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


signature.asc
Description: PGP signature
__
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


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

2017-10-30 Thread Arkady.Kanevsky
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 
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


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

2017-10-30 Thread Doug Hellmann
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.txt
> [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-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

2017-10-30 Thread Dmitry Tantsur

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev