[requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
Requesting exception to lower a requirement to resolve a packaging issue. https://review.openstack.org/#/c/650100/
On 19-04-04 14:30:51, Eric K wrote:
Requesting exception to lower a requirement to resolve a packaging issue.
This is more of a stable question, it's late in the cycle but it sounds possibly needed. I think this is fine technically, but not sure about it policy wise. To me it sounds more of CentOS's problem than Openstack's (to be a bit brash). Added the stable tag to the thread. -- Matthew Thode
On 19-04-04 16:51:00, Matthew Thode wrote:
On 19-04-04 14:30:51, Eric K wrote:
Requesting exception to lower a requirement to resolve a packaging issue.
This is more of a stable question, it's late in the cycle but it sounds possibly needed. I think this is fine technically, but not sure about it policy wise. To me it sounds more of CentOS's problem than Openstack's (to be a bit brash). Added the stable tag to the thread.
Adding stable tag -- Matthew Thode
On 4/4/19, 1:51 PM, "Matthew Thode" <mthode@mthode.org> wrote:
On 19-04-04 14:30:51, Eric K wrote:
Requesting exception to lower a requirement to resolve a packaging issue.
This is more of a stable question, it's late in the cycle but it sounds possibly needed. I think this is fine technically, but not sure about it policy wise. To me it sounds more of CentOS's problem than Openstack's (to be a bit brash). Added the stable tag to the thread.
-- Matthew Thode
Thanks Matthew. I'm not so worried about stability because even if it breaks Something it affects only a new (Stein) experimental feature no one is relying on.
On Thu, 2019-04-04 at 15:20 -0800, Eric K wrote:
On 4/4/19, 1:51 PM, "Matthew Thode" <mthode@mthode.org> wrote:
On 19-04-04 14:30:51, Eric K wrote:
Requesting exception to lower a requirement to resolve a packaging issue.
This is more of a stable question, it's late in the cycle but it sounds possibly needed. I think this is fine technically, but not sure about it policy wise. To me it sounds more of CentOS's problem than Openstack's (to be a bit brash). Added the stable tag to the thread.
-- Matthew Thode
Thanks Matthew. I'm not so worried about stability because even if it breaks Something it affects only a new (Stein) experimental feature no one is relying on. congresses lower constraints job https://github.com/openstack/congress/blob/master/tox.ini#L103-L108
is broken the same way as novas was because of the install command that is used https://github.com/openstack/congress/blob/master/tox.ini#L9 so https://review.openstack.org/#/c/650100/ sets the lower constatit to something that is invalid for the gate job which runs on ubuntu. if you look at the output of the job http://logs.openstack.org/00/650100/1/check/openstack-tox-lower-constraints/... we can see its using psycopg2 Collecting psycopg2===2.7.7 (from -c /home/zuul/src/git.openstack.org/openstack/requirements/upper-constraints.txt (line 81)) Downloading http://mirror.ord.rax.openstack.org/pypifiles/packages/37/25/53e8398975aa332... (2.7MB) it is technically true that psycopg2==2.5.1 will work on centos but until this is restored to 2.7 the gate job cannot be fixed. pep-0508 defines a set of markers we can use for packageing https://www.python.org/dev/peps/pep-0508/ the only marker that i know of that contains the disto name is "platform_version" we should be able to do something like psycopg2==2.5.1; platform_version~=CENTOS psycopg2==2.7; but i dont think we should be breaking one distor to fix another when the lower constatint.txt wont be used to build the centos packages anyway lower-constiatns will only be used when installing from pip in which case the distro versions is not relevent unless i have missed something.
On Fri, Apr 5, 2019 at 2:59 AM Sean Mooney <smooney@redhat.com> wrote:
On Thu, 2019-04-04 at 15:20 -0800, Eric K wrote:
On 4/4/19, 1:51 PM, "Matthew Thode" <mthode@mthode.org> wrote:
On 19-04-04 14:30:51, Eric K wrote:
Requesting exception to lower a requirement to resolve a packaging issue.
This is more of a stable question, it's late in the cycle but it sounds possibly needed. I think this is fine technically, but not sure about it policy wise. To me it sounds more of CentOS's problem than Openstack's (to be a bit brash). Added the stable tag to the thread.
-- Matthew Thode
Thanks Matthew. I'm not so worried about stability because even if it breaks Something it affects only a new (Stein) experimental feature no one is relying on. congresses lower constraints job https://github.com/openstack/congress/blob/master/tox.ini#L103-L108
is broken the same way as novas was because of the install command that is used https://github.com/openstack/congress/blob/master/tox.ini#L9
so https://review.openstack.org/#/c/650100/ sets the lower constatit to something that is invalid for the gate job which runs on ubuntu. if you look at the output of the job http://logs.openstack.org/00/650100/1/check/openstack-tox-lower-constraints/...
we can see its using psycopg2 Collecting psycopg2===2.7.7 (from -c /home/zuul/src/git.openstack.org/openstack/requirements/upper-constraints.txt (line 81)) Downloading http://mirror.ord.rax.openstack.org/pypifiles/packages/37/25/53e8398975aa332... (2.7MB)
it is technically true that psycopg2==2.5.1 will work on centos but until this is restored to 2.7 the gate job cannot be fixed.
pep-0508 defines a set of markers we can use for packageing https://www.python.org/dev/peps/pep-0508/
the only marker that i know of that contains the disto name is "platform_version"
we should be able to do something like
psycopg2==2.5.1; platform_version~=CENTOS psycopg2==2.7;
but i dont think we should be breaking one distor to fix another when the lower constatint.txt wont be used to build the centos packages anyway lower-constiatns will only be used when installing from pip in which case the distro versions is not relevent unless i have missed something.
Thank you, Sean. Sorry I'm ignorant re: the lower constraints job. Where can we look-up what the valid lower-constraints are? Specifically, I looked at another earlier patch without the change to psycopg2 version (lower constraint 2.7) but there also it installed 2.7.7. http://logs.openstack.org/63/649763/4/check/openstack-tox-lower-constraints/... https://review.openstack.org/#/c/649763/ Does that mean psycopg2==2.7 is also invalid?
On Fri, Apr 5, 2019 at 2:59 AM Sean Mooney <smooney@redhat.com> wrote:
On Thu, 2019-04-04 at 15:20 -0800, Eric K wrote:
On 4/4/19, 1:51 PM, "Matthew Thode" <mthode@mthode.org> wrote:
On 19-04-04 14:30:51, Eric K wrote:
Requesting exception to lower a requirement to resolve a packaging issue.
This is more of a stable question, it's late in the cycle but it sounds possibly needed. I think this is fine technically, but not sure about it policy wise. To me it sounds more of CentOS's problem than Openstack's (to be a bit brash). Added the stable tag to the thread.
-- Matthew Thode
Thanks Matthew. I'm not so worried about stability because even if it breaks Something it affects only a new (Stein) experimental feature no one is relying on.
congresses lower constraints job https://github.com/openstack/congress/blob/master/tox.ini#L103-L108
is broken the same way as novas was because of the install command that is used https://github.com/openstack/congress/blob/master/tox.ini#L9
so https://review.openstack.org/#/c/650100/ sets the lower constatit to something that is invalid for the gate job which runs on ubuntu. if you look at the output of the job http://logs.openstack.org/00/650100/1/check/openstack-tox-lower-constraints/...
we can see its using psycopg2 Collecting psycopg2===2.7.7 (from -c /home/zuul/src/git.openstack.org/openstack/requirements/upper-constraints.txt (line 81)) Downloading
http://mirror.ord.rax.openstack.org/pypifiles/packages/37/25/53e8398975aa332...
(2.7MB)
it is technically true that psycopg2==2.5.1 will work on centos but until this is restored to 2.7 the gate job cannot be fixed.
pep-0508 defines a set of markers we can use for packageing https://www.python.org/dev/peps/pep-0508/
the only marker that i know of that contains the disto name is "platform_version"
we should be able to do something like
psycopg2==2.5.1; platform_version~=CENTOS psycopg2==2.7;
but i dont think we should be breaking one distor to fix another when the lower constatint.txt wont be used to build the centos packages anyway lower-constiatns will only be used when installing from pip in which case the distro versions is not relevent unless i have missed something.
Thank you, Sean. Sorry I'm ignorant re: the lower constraints job. Where can we look-up what the valid lower-constraints are?
Specifically, I looked at another earlier patch without the change to psycopg2 version (lower constraint 2.7) but there also it installed 2.7.7. http://logs.openstack.org/63/649763/4/check/openstack-tox-lower-constraints/... https://review.openstack.org/#/c/649763/
Does that mean psycopg2==2.7 is also invalid?
On Fri, 2019-04-05 at 12:27 -0700, Eric K wrote: that is a good question. i belive 2.7 shoudl work however when i fixed the lower-constraints evn in https://review.openstack.org/#/c/650441/ i got test failures related to psycopg2 locally. the lower constraints tox env and therefor the gate job has been broken since it was created so you cannot trust any of the lower constraints are correct until we test with them. i have also used docker to try and run the test under centos basically by running sudo docker run --rm -itu root -v $(pwd):/data centos/python-36-centos7 bash then pip installing tox and runnign the lower-constraints job tox -e lower-constraints -r -v it also fails on centos but for differnt reasons then i was seeign with a ubunut based host.
On Thu, Apr 4, 2019 at 11:51 PM Matthew Thode <mthode@mthode.org> wrote:
On 19-04-04 14:30:51, Eric K wrote:
Requesting exception to lower a requirement to resolve a packaging issue.
This is more of a stable question, it's late in the cycle but it sounds possibly needed. I think this is fine technically, but not sure about it policy wise. To me it sounds more of CentOS's problem than Openstack's (to be a bit brash). Added the stable tag to the thread.
To clarify this topic, the approach in RDO is not to provide newer versions of packages which are included in CentOS base repos as it may affect other packages included in the distro *unless is required*. This means we update dependencies included in CentOS for issues actually reported by users or detected by CI but not proactively to match what is in upper-constraints. In the original implementation of the new feature in Congress this was the case (it was breaking CI jobs) so i started the process to update it in RDO in https://review.rdoproject.org/r/#/c/19929/ . According to the feedback from Eric, this is needed just for a experimental feature so i think that doing the import conditional or changing the implementation as done in https://review.openstack.org/#/c/650100/ is good. Anyway, let us know if the update of psycopg2 is needed and i will revive it.
-- Matthew Thode
participants (4)
-
Alfredo Moralejo Alonso
-
Eric K
-
Matthew Thode
-
Sean Mooney