[zaqar][requirements][tc][triple-o][tripleo] jsonschema 3.x and python-zaqarclient
Hi,
For a while the requirements team is trying to go through the process of removing the upper cap on jsonschema to allow the update to jsonschema 3.x. The update for that is becoming more urgent as more and more other (non-OpenStack) projects are going with requiring jsonschema >= 3, so we need to move forward as well to keep co-installability and be able to consume updates of packages to versions that depend on jsonschema >= 3.
The current blocker seems to be tripleo-common / os-collect-config depending on python-zaqarclient, which has a broken gate since the merge of:
http://specs.openstack.org/openstack/zaqar-specs/specs/stein/remove-pool-gro...
on the server side, which was done here:
https://review.opendev.org/#/c/628723/
The python-zaqarclient functional tests have not been correspondingly adjusted, and are failing for more than 5 months meanwhile, in consequence many patches for zaqarclient, including the one uncapping jsonschema are piling up. It looks like no real merge activity happened since
https://review.opendev.org/#/c/607553/
which is a bit more than 6 months ago. How should we move forward? doing a release of zaqarclient using some implementation of an API that got removed server side doesn't seem to be a terribly great idea, plus that we still need to merge either one of my patches (one that makes functional testing non-voting or the brutal "lets drop all tests that fail" patch). On the other side, I don't know how feasible it is for Triple-O to drop the dependency on os-collect-config or os-collect-config to drop the dependency on zaqar.
Any suggestion on how to move forward?
TIA, Dirk
On Fri, Aug 9, 2019 at 2:18 PM Dirk Müller dirk@dmllr.de wrote:
Hi,
For a while the requirements team is trying to go through the process of removing the upper cap on jsonschema to allow the update to jsonschema 3.x. The update for that is becoming more urgent as more and more other (non-OpenStack) projects are going with requiring jsonschema >= 3, so we need to move forward as well to keep co-installability and be able to consume updates of packages to versions that depend on jsonschema >= 3.
The current blocker seems to be tripleo-common / os-collect-config depending on python-zaqarclient, which has a broken gate since the merge of:
http://specs.openstack.org/openstack/zaqar-specs/specs/stein/remove-pool-gro...
on the server side, which was done here:
https://review.opendev.org/#/c/628723/
The python-zaqarclient functional tests have not been correspondingly adjusted, and are failing for more than 5 months meanwhile, in consequence many patches for zaqarclient, including the one uncapping jsonschema are piling up. It looks like no real merge activity happened since
https://review.opendev.org/#/c/607553/
which is a bit more than 6 months ago. How should we move forward? doing a release of zaqarclient using some implementation of an API that got removed server side doesn't seem to be a terribly great idea, plus that we still need to merge either one of my patches (one that makes functional testing non-voting or the brutal "lets drop all tests that fail" patch). On the other side, I don't know how feasible it is for Triple-O to drop the dependency on os-collect-config or os-collect-config to drop the dependency on zaqar.
Any suggestion on how to move forward?
I'm going to reach out to the PTL who seems to be active as the last proposed change was 5 days ago by them.
TIA, Dirk
On Fri, Aug 9, 2019 at 12:20 PM Dirk Müller dirk@dmllr.de wrote:
Hi,
For a while the requirements team is trying to go through the process of removing the upper cap on jsonschema to allow the update to jsonschema 3.x. The update for that is becoming more urgent as more and more other (non-OpenStack) projects are going with requiring jsonschema >= 3, so we need to move forward as well to keep co-installability and be able to consume updates of packages to versions that depend on jsonschema >= 3.
The current blocker seems to be tripleo-common / os-collect-config depending on python-zaqarclient, which has a broken gate since the merge of:
http://specs.openstack.org/openstack/zaqar-specs/specs/stein/remove-pool-gro...
on the server side, which was done here:
https://review.opendev.org/#/c/628723/
The python-zaqarclient functional tests have not been correspondingly adjusted, and are failing for more than 5 months meanwhile, in consequence many patches for zaqarclient, including the one uncapping jsonschema are piling up. It looks like no real merge activity happened since
https://review.opendev.org/#/c/607553/
which is a bit more than 6 months ago. How should we move forward? doing a release of zaqarclient using some implementation of an API that got removed server side doesn't seem to be a terribly great idea, plus that we still need to merge either one of my patches (one that makes functional testing non-voting or the brutal "lets drop all tests that fail" patch). On the other side, I don't know how feasible it is for Triple-O to drop the dependency on os-collect-config or os-collect-config to drop the dependency on zaqar.
Do you have an example of what the issue with tripleo/os-collect-config is? It looks like os-collect-config has support for using zaqarclient as a notification mechanism for work but I don't think it's currently used. That being said, can we just fix whatever issue is? I don't see os-collect-config using pool_group anywhere
Any suggestion on how to move forward?
TIA, Dirk
Hi Alex,
Am Mo., 12. Aug. 2019 um 19:29 Uhr schrieb Alex Schultz aschultz@redhat.com:
Do you have an example of what the issue with tripleo/os-collect-config is? It looks like os-collect-config has support for using zaqarclient as a notification mechanism for work but I don't think it's currently used.
it depends on it (has it in its requirements.txt) so if its not used, maybe we can remove it?
That being said, can we just fix whatever issue is? I don't see os-collect-config using pool_group anywhere
sure, lets see if we can fix zaqarclient and release a new version. hao wang recently started responding to this (in a private conversation), so I'll give him and the team a few days to sort the issues out.
Greetings, Dirk
On Tue, Aug 13, 2019 at 3:30 AM Dirk Müller dirk@dmllr.de wrote:
Hi Alex,
Am Mo., 12. Aug. 2019 um 19:29 Uhr schrieb Alex Schultz < aschultz@redhat.com>:
Do you have an example of what the issue with tripleo/os-collect-config
is? It looks like os-collect-config has support for using zaqarclient as a notification mechanism for work but I don't think it's currently used.
it depends on it (has it in its requirements.txt) so if its not used, maybe we can remove it?
Well code exists that calls zaqarclient, I just don't know if anyone has deployed the functionality.
That being said, can we just fix whatever issue is? I don't see
os-collect-config using pool_group anywhere
sure, lets see if we can fix zaqarclient and release a new version. hao wang recently started responding to this (in a private conversation), so I'll give him and the team a few days to sort the issues out.
Ok let us know if you have any specific issues with os-collect-config and we can take a look.
Thanks
Greetings, Dirk
participants (3)
-
Alex Schultz
-
Dirk Müller
-
Mohammed Naser