[oslo][requirements][release] oslo.db lower-constraints job broken
Hi,
Our stable/stein patches in oslo.db are currently failing the lower-constraints job due to [0]. I assume master has the same problem since there haven't been any changes since branching. It looks like the problem is that psycopg2 < 2.7 doesn't work with postgresql 10, and we're getting 10 now on bionic.
The simple solution is to bump the lower-constraint, but I'm not sure how that's going to work for the stable branch since we can't change requirements there. How do we proceed?
Thanks.
-Ben
On 19-03-22 14:32:01, Ben Nemec wrote:
Hi,
Our stable/stein patches in oslo.db are currently failing the lower-constraints job due to [0]. I assume master has the same problem since there haven't been any changes since branching. It looks like the problem is that psycopg2 < 2.7 doesn't work with postgresql 10, and we're getting 10 now on bionic.
The simple solution is to bump the lower-constraint, but I'm not sure how that's going to work for the stable branch since we can't change requirements there. How do we proceed?
Thanks.
-Ben
lower-constraints are controlled by each project individually. You can raise the minimum version. If you need to raise upper-constraints as well or add a globally known bad version to global-requirements then there'd need to be change in the requirements repo.
On 3/22/19 2:38 PM, Matthew Thode wrote:
On 19-03-22 14:32:01, Ben Nemec wrote:
Hi,
Our stable/stein patches in oslo.db are currently failing the lower-constraints job due to [0]. I assume master has the same problem since there haven't been any changes since branching. It looks like the problem is that psycopg2 < 2.7 doesn't work with postgresql 10, and we're getting 10 now on bionic.
The simple solution is to bump the lower-constraint, but I'm not sure how that's going to work for the stable branch since we can't change requirements there. How do we proceed?
Thanks.
-Ben
lower-constraints are controlled by each project individually. You can raise the minimum version. If you need to raise upper-constraints as well or add a globally known bad version to global-requirements then there'd need to be change in the requirements repo.
But we can't change lower-constraints without also updating the minimum requirement, which means we can't release the stable branch because it would require a feature release.
On 19-03-22 14:40:20, Ben Nemec wrote:
On 3/22/19 2:38 PM, Matthew Thode wrote:
On 19-03-22 14:32:01, Ben Nemec wrote:
Hi,
Our stable/stein patches in oslo.db are currently failing the lower-constraints job due to [0]. I assume master has the same problem since there haven't been any changes since branching. It looks like the problem is that psycopg2 < 2.7 doesn't work with postgresql 10, and we're getting 10 now on bionic.
The simple solution is to bump the lower-constraint, but I'm not sure how that's going to work for the stable branch since we can't change requirements there. How do we proceed?
Thanks.
-Ben
lower-constraints are controlled by each project individually. You can raise the minimum version. If you need to raise upper-constraints as well or add a globally known bad version to global-requirements then there'd need to be change in the requirements repo.
But we can't change lower-constraints without also updating the minimum requirement, which means we can't release the stable branch because it would require a feature release.
There's nothing in the reqs repo that prevents you from updating the minimum in requirements.txt as well (global-requirements does not track versions execpt known bad ones and sometimes a cap). As for requiring a feature release, ya, that could be a problem but the release team would be best to ask about it.
On 3/22/19 2:45 PM, Matthew Thode wrote:
On 19-03-22 14:40:20, Ben Nemec wrote:
On 3/22/19 2:38 PM, Matthew Thode wrote:
On 19-03-22 14:32:01, Ben Nemec wrote:
Hi,
Our stable/stein patches in oslo.db are currently failing the lower-constraints job due to [0]. I assume master has the same problem since there haven't been any changes since branching. It looks like the problem is that psycopg2 < 2.7 doesn't work with postgresql 10, and we're getting 10 now on bionic.
The simple solution is to bump the lower-constraint, but I'm not sure how that's going to work for the stable branch since we can't change requirements there. How do we proceed?
Thanks.
-Ben
lower-constraints are controlled by each project individually. You can raise the minimum version. If you need to raise upper-constraints as well or add a globally known bad version to global-requirements then there'd need to be change in the requirements repo.
But we can't change lower-constraints without also updating the minimum requirement, which means we can't release the stable branch because it would require a feature release.
There's nothing in the reqs repo that prevents you from updating the minimum in requirements.txt as well (global-requirements does not track versions execpt known bad ones and sometimes a cap). As for requiring a feature release, ya, that could be a problem but the release team would be best to ask about it.
Yeah sorry, I should have been more explicit in my first email. My concern is how to fix this without making the stable branch unreleaseable. I already proposed a patch to bump the version on master, but I don't think it's valid for backport. Maybe I should have tagged stable instead (done).
There's nothing in the reqs repo that prevents you from updating the minimum in requirements.txt as well (global-requirements does not track versions execpt known bad ones and sometimes a cap). As for requiring a feature release, ya, that could be a problem but the release team would be best to ask about it.
Yeah sorry, I should have been more explicit in my first email. My concern is how to fix this without making the stable branch unreleaseable. I already proposed a patch to bump the version on master, but I don't think it's valid for backport. Maybe I should have tagged stable instead (done).
Well, in this case we know it's completely broken, so I think that makes some of the decision for us. It's better to do a stable release that will unbreak things than to keep a broken build out there because our process tells us we have to.
Sean
On 3/22/19 3:18 PM, Sean McGinnis wrote:
There's nothing in the reqs repo that prevents you from updating the minimum in requirements.txt as well (global-requirements does not track versions execpt known bad ones and sometimes a cap). As for requiring a feature release, ya, that could be a problem but the release team would be best to ask about it.
Yeah sorry, I should have been more explicit in my first email. My concern is how to fix this without making the stable branch unreleaseable. I already proposed a patch to bump the version on master, but I don't think it's valid for backport. Maybe I should have tagged stable instead (done).
Well, in this case we know it's completely broken, so I think that makes some of the decision for us. It's better to do a stable release that will unbreak things than to keep a broken build out there because our process tells us we have to.
Will the release check ci jobs let us do that? I guess I can get it proposed and we'll figure it out from there.
Backport is at https://review.openstack.org/#/c/645874/
Thanks.
Ben Nemec openstack@nemebean.com writes:
On 3/22/19 3:18 PM, Sean McGinnis wrote:
There's nothing in the reqs repo that prevents you from updating the minimum in requirements.txt as well (global-requirements does not track versions execpt known bad ones and sometimes a cap). As for requiring a feature release, ya, that could be a problem but the release team would be best to ask about it.
Yeah sorry, I should have been more explicit in my first email. My concern is how to fix this without making the stable branch unreleaseable. I already proposed a patch to bump the version on master, but I don't think it's valid for backport. Maybe I should have tagged stable instead (done).
Well, in this case we know it's completely broken, so I think that makes some of the decision for us. It's better to do a stable release that will unbreak things than to keep a broken build out there because our process tells us we have to.
Will the release check ci jobs let us do that? I guess I can get it proposed and we'll figure it out from there.
Backport is at https://review.openstack.org/#/c/645874/
Thanks.
Yeah, the release jobs will allow it. We've had to do things like this before, and as long as we fix stable before master it's not a big deal. You might have to remind us when it comes time for the review, but you can just describe the problem in the commit message and link here.
Ben Nemec openstack@nemebean.com writes:
On 3/22/19 4:23 PM, Doug Hellmann wrote:
as long as we fix stable before master it's not a big deal.
Does that just apply to the release request, or do I need to block the master patch in oslo.db too?
Sorry, I meant "release" not "fix". You should do the backport in the usual way, and just avoid releasing from master until the release is done on the stable branch. That lets us use a feature release version on the stable branch (accurately) and the next release from master will automatically increment past that and leave space for future patch releases.
On 3/22/19 5:11 PM, Doug Hellmann wrote:
Ben Nemec openstack@nemebean.com writes:
On 3/22/19 4:23 PM, Doug Hellmann wrote:
as long as we fix stable before master it's not a big deal.
Does that just apply to the release request, or do I need to block the master patch in oslo.db too?
Sorry, I meant "release" not "fix". You should do the backport in the usual way, and just avoid releasing from master until the release is done on the stable branch. That lets us use a feature release version on the stable branch (accurately) and the next release from master will automatically increment past that and leave space for future patch releases.
Okay, that's what I thought. Just wanted to make sure.
participants (4)
-
Ben Nemec
-
Doug Hellmann
-
Matthew Thode
-
Sean McGinnis