[all] Dangerous trend toward too many release-independent components
Hi, As I'm packaging Xena in Debian, I've seen more and more components switching to release-independent. This poses a number of problems which I'm really unsure how to address. Let me explain. First of all, once an OpenStack release reaches a distribution stable release, there will be no update of it (ie: no new upstream release), unless there's a security problems, or important bugfixes that cannot be backported individually. At least, that's how Debian works, and why we call our suite "stable" (ie: it doesn't change). However, if a component is declared release-independent, the OpenStack community expects it to be updated for all downward releases. But that's not what's going on in reality. Also, if there's a security fix, we're supposed to get this through an update of a new version, which may include changes not suitable for a distribution update. The danger is that the update may be refused by the Debian Stable release team, for very good reasons (which I agree on). I'm also questioning myself: since we have pinned global requirements, will these new updates be included in the tests of older OpenStack releases? Is this really the case right now? So, while I do understand why it's nicer to set release-independent tags on some components, it is my opinion that this doesn't help stability and poses numerous problems to downstream distributions. Could we limit the number of such release-independent released components to the strict minimum low-profile (ie: with the least amount of code) components, rather than constantly increasing the list? Your thoughts? Cheers, Thomas Goirand (zigo)
Thomas Goirand wrote:
As I'm packaging Xena in Debian, I've seen more and more components switching to release-independent. This poses a number of problems which I'm really unsure how to address. Let me explain.
First of all, once an OpenStack release reaches a distribution stable release, there will be no update of it (ie: no new upstream release), unless there's a security problems, or important bugfixes that cannot be backported individually. At least, that's how Debian works, and why we call our suite "stable" (ie: it doesn't change).
However, if a component is declared release-independent, the OpenStack community expects it to be updated for all downward releases. But that's not what's going on in reality. Also, if there's a security fix, we're supposed to get this through an update of a new version, which may include changes not suitable for a distribution update. The danger is that the update may be refused by the Debian Stable release team, for very good reasons (which I agree on).
I'm also questioning myself: since we have pinned global requirements, will these new updates be included in the tests of older OpenStack releases? Is this really the case right now?
So, while I do understand why it's nicer to set release-independent tags on some components, it is my opinion that this doesn't help stability and poses numerous problems to downstream distributions.
Could we limit the number of such release-independent released components to the strict minimum low-profile (ie: with the least amount of code) components, rather than constantly increasing the list?
Hi Thomas, Those are all good points, and we will discuss them at the release team level. For context, recently the release team has encouraged a number of stale components (stable libraries etc.) to move to release-independent since they were not even seeing one release per cycle. There was no point in forcing releases every cycle that were just changing the branch name in .gitreview. Regards, -- Thierry Carrez (ttx)
On 2021-09-07 11:09:45 +0200 (+0200), Thomas Goirand wrote: [...]
since we have pinned global requirements, will these new updates be included in the tests of older OpenStack releases? Is this really the case right now? [...]
They generally shouldn't, and most of the time can't realistically, have their entries altered in stable branches of the upper-constraints.txt file we use to pin dependency versions. To be able to do so would prevent them from using new features of their own dependencies in master branch development, since those would end up also needing updates in the pinned list of transitive stable branch constraints, which is exactly what we want to avoid. The workaround is to create a stable branch of the repository from the last version which was tagged during the cycle for the release which needs a fix to that independent deliverable backported. Those cases are rare, and basically what you would include as a stable distro package update for that coordinated release series anyway. -- Jeremy Stanley
On 9/7/21 3:39 PM, Jeremy Stanley wrote:
On 2021-09-07 11:09:45 +0200 (+0200), Thomas Goirand wrote: [...]
since we have pinned global requirements, will these new updates be included in the tests of older OpenStack releases? Is this really the case right now? [...]
They generally shouldn't, and most of the time can't realistically, have their entries altered in stable branches of the upper-constraints.txt file we use to pin dependency versions. To be able to do so would prevent them from using new features of their own dependencies in master branch development, since those would end up also needing updates in the pinned list of transitive stable branch constraints, which is exactly what we want to avoid.
The workaround is to create a stable branch of the repository from the last version which was tagged during the cycle for the release which needs a fix to that independent deliverable backported. Those cases are rare, and basically what you would include as a stable distro package update for that coordinated release series anyway.
Hi, Thanks for your insights. Basically, what you're writing above confirm what I thought: the release-independent components are in fact not really release-independent, and are bound to a specific release of OpenStack. Most of the time, they aren't updated in the stable release CI. Therefore, it would probably be wise to try to minimize the amount of release-independent components to reflect this reality. In fact, I was particularly confuse to realize that something like taskflow was declared release-independent since Wallaby. Now, if I'm told that it is loosely coupled with OpenStack, knowing that it's a key component, I'm not sure what I should do. Should I get taskflow updated to 4.6.2 in Wallaby, so I get bugfixes? Or is it safer to just upgrade it for Xena? I took Taskflow as an example (you can reply to me about Taskflow in particular, but that's not the point I'm trying to make). But it could have been something else (deptcollector? oslo.i18n?). What I'm trying to say is that as a downstream consumer, it's from hard to impossible to know what to do for the past OpenStack releases regarding these release-independent components: should I update them or not? It is unrealistic to hope that one can track what component has been updated to a newer version in the stable release CI. Therefore, if possible, I would prefer clearer, easier to track, release-bound components with point release updates (though I understand that it may not be possible if that's too much work and OpenStack is getting understaffed...). Cheers, Thomas Goirand (zigo)
On 2021-09-08 00:46:30 +0200 (+0200), Thomas Goirand wrote: [...]
In fact, I was particularly confuse to realize that something like taskflow was declared release-independent since Wallaby. Now, if I'm told that it is loosely coupled with OpenStack, knowing that it's a key component, I'm not sure what I should do. Should I get taskflow updated to 4.6.2 in Wallaby, so I get bugfixes? Or is it safer to just upgrade it for Xena?
I took Taskflow as an example (you can reply to me about Taskflow in particular, but that's not the point I'm trying to make). But it could have been something else (deptcollector? oslo.i18n?). What I'm trying to say is that as a downstream consumer, it's from hard to impossible to know what to do for the past OpenStack releases regarding these release-independent components: should I update them or not? It is unrealistic to hope that one can track what component has been updated to a newer version in the stable release CI.
Specific examples are great actually, because it at least lets us try to formulate a specific answer and then reason about whether a similar answer can be generally applied to other related scenarios. So let's take taskflow in Wallaby and Xena: The closest thing we have to a recommendation for versions of "outside" dependencies (which is essentially what we treat release-independent deliverables as) is the upper-constraints.txt file on each branch of the openstack/requirements repository. In the case of taskflow, at the moment the stable/wallaby branch upper constraint for taskflow is 4.6.0, which is the version we indicate all OpenStack projects should test their stable/wallaby changes against. That entry was last updated by https://review.opendev.org/773620 which merged to the master branch of openstack/requirements in February, well before the coordinated Wallaby release. Even though the master (upcoming Xena coordinated release) upper-constraints.txt file lists taskflow===4.6.2, we don't test stable branch changes of OpenStack projects with that, only what will eventually become stable/xena once the Xena cycle concludes.
Therefore, if possible, I would prefer clearer, easier to track, release-bound components with point release updates (though I understand that it may not be possible if that's too much work and OpenStack is getting understaffed...).
It seems like what you're asking for is this: https://opendev.org/openstack/requirements/src/branch/stable/wallaby/upper-c... Or rather, that's the closest thing we have to what I think you're requesting. If you follow the commit history of that file, you'll see recent updates for it on the stable/wallaby branch do consist almost entirely of stable point releases of cycle-oriented projects: https://opendev.org/openstack/requirements/commits/branch/stable/wallaby/upp... Does this help narrow the scope of concern to the point where we can better reason about the problems or challenges you're facing? -- Jeremy Stanley
On 9/8/21 1:21 AM, Jeremy Stanley wrote:
On 2021-09-08 00:46:30 +0200 (+0200), Thomas Goirand wrote: [...]
In fact, I was particularly confuse to realize that something like taskflow was declared release-independent since Wallaby. Now, if I'm told that it is loosely coupled with OpenStack, knowing that it's a key component, I'm not sure what I should do. Should I get taskflow updated to 4.6.2 in Wallaby, so I get bugfixes? Or is it safer to just upgrade it for Xena?
I took Taskflow as an example (you can reply to me about Taskflow in particular, but that's not the point I'm trying to make). But it could have been something else (deptcollector? oslo.i18n?). What I'm trying to say is that as a downstream consumer, it's from hard to impossible to know what to do for the past OpenStack releases regarding these release-independent components: should I update them or not? It is unrealistic to hope that one can track what component has been updated to a newer version in the stable release CI.
Specific examples are great actually, because it at least lets us try to formulate a specific answer and then reason about whether a similar answer can be generally applied to other related scenarios. So let's take taskflow in Wallaby and Xena:
The closest thing we have to a recommendation for versions of "outside" dependencies (which is essentially what we treat release-independent deliverables as) is the upper-constraints.txt file on each branch of the openstack/requirements repository. In the case of taskflow, at the moment the stable/wallaby branch upper constraint for taskflow is 4.6.0, which is the version we indicate all OpenStack projects should test their stable/wallaby changes against. That entry was last updated by https://review.opendev.org/773620 which merged to the master branch of openstack/requirements in February, well before the coordinated Wallaby release.
Ok, so your recommendation is that, for each and every component that is marked release-independent, I should be checking the global requirements. I just wrote that this is unrealistic that a human does such a check. If you didn't know, in Debian, Michal Arbet (who co-maintains OpenStack with me together in Debian) wrote this: https://salsa.debian.org/openstack-team/debian/os-version-checker This VersionStatus.py checks for what's in https://releases.openstack.org/, for example in https://releases.openstack.org/xena/index.html for the Xena upcoming release. The result output of the os-version-checker is this page: http://osbpo.debian.net/deb-status/ Thanks to this page, anyone can know the status of OpenStack packaging on all the different branches we maintain. If you look at it right now, you'll notice that we're up-to-date, as we packaged all non-clients and all clients library, but we didn't package new versions of the puppet manifests yet (I'm waiting for the RCs to do that). If you click on the buster-victoria button, and look for Taskflow, you'll see that it's up-to-date. If you click on bullseye-xena, and search for Taskflow, you will ... find nothing! That's because taskflow doesn't appear in https://releases.openstack.org/xena/index.html since it is release-independent. As a result, I'm left with no other choice than being very careful and manually check the global-requirements. Every check that is supposed to be done by a human isn't reliable. It'd be nice if I had a way to automatically check for this. The thing is, the global-requirements is full of information, some of it not relevant to my own use case, and it's hard to check automatically. First of all, because the Python module names as in PyPi, do not necessarily match the package names. Also, because some artifacts are not relevant to Debian. For example, I have no use of many TripleO stuff, and some services are simply not packaged in Debian. In an ideal world, we'd have an API to check for all of this, rather than digging through the release HTML pages.
It seems like what you're asking for is this:
https://opendev.org/openstack/requirements/src/branch/stable/wallaby/upper-c...
Or rather, that's the closest thing we have to what I think you're requesting. If you follow the commit history of that file, you'll see recent updates for it on the stable/wallaby branch do consist almost entirely of stable point releases of cycle-oriented projects:
https://opendev.org/openstack/requirements/commits/branch/stable/wallaby/upp...
Does this help narrow the scope of concern to the point where we can better reason about the problems or challenges you're facing?
Unfortunately, while it is part of the answer, due to what I explained just above, it is very hard to exploit the available data without a real, long effort on our side to fix this. :/ One solution could probably be for *US* (downstream distros) to write some kind of API as I just wrote, and make it available for everyone on releases.openstack.org. Are Red Hat people also interested by such an effort? Any pointer where we should attempt to propose patches? Cheers, Thomas Goirand (zigo)
Le mer. 8 sept. 2021 à 10:29, Thomas Goirand <zigo@debian.org> a écrit :
On 9/8/21 1:21 AM, Jeremy Stanley wrote:
On 2021-09-08 00:46:30 +0200 (+0200), Thomas Goirand wrote: [...]
In fact, I was particularly confuse to realize that something like taskflow was declared release-independent since Wallaby. Now, if I'm told that it is loosely coupled with OpenStack, knowing that it's a key component, I'm not sure what I should do. Should I get taskflow updated to 4.6.2 in Wallaby, so I get bugfixes? Or is it safer to just upgrade it for Xena?
I took Taskflow as an example (you can reply to me about Taskflow in particular, but that's not the point I'm trying to make). But it could have been something else (deptcollector? oslo.i18n?). What I'm trying to say is that as a downstream consumer, it's from hard to impossible to know what to do for the past OpenStack releases regarding these release-independent components: should I update them or not? It is unrealistic to hope that one can track what component has been updated to a newer version in the stable release CI.
Specific examples are great actually, because it at least lets us try to formulate a specific answer and then reason about whether a similar answer can be generally applied to other related scenarios. So let's take taskflow in Wallaby and Xena:
The closest thing we have to a recommendation for versions of "outside" dependencies (which is essentially what we treat release-independent deliverables as) is the upper-constraints.txt file on each branch of the openstack/requirements repository. In the case of taskflow, at the moment the stable/wallaby branch upper constraint for taskflow is 4.6.0, which is the version we indicate all OpenStack projects should test their stable/wallaby changes against. That entry was last updated by https://review.opendev.org/773620 which merged to the master branch of openstack/requirements in February, well before the coordinated Wallaby release.
Ok, so your recommendation is that, for each and every component that is marked release-independent, I should be checking the global requirements. I just wrote that this is unrealistic that a human does such a check.
If you didn't know, in Debian, Michal Arbet (who co-maintains OpenStack with me together in Debian) wrote this:
https://salsa.debian.org/openstack-team/debian/os-version-checker
This VersionStatus.py checks for what's in https://releases.openstack.org/, for example in https://releases.openstack.org/xena/index.html for the Xena upcoming release.
The result output of the os-version-checker is this page:
http://osbpo.debian.net/deb-status/
Thanks to this page, anyone can know the status of OpenStack packaging on all the different branches we maintain. If you look at it right now, you'll notice that we're up-to-date, as we packaged all non-clients and all clients library, but we didn't package new versions of the puppet manifests yet (I'm waiting for the RCs to do that).
If you click on the buster-victoria button, and look for Taskflow, you'll see that it's up-to-date. If you click on bullseye-xena, and search for Taskflow, you will ... find nothing! That's because taskflow doesn't appear in https://releases.openstack.org/xena/index.html since it is release-independent. As a result, I'm left with no other choice than being very careful and manually check the global-requirements.
Every check that is supposed to be done by a human isn't reliable. It'd be nice if I had a way to automatically check for this. The thing is, the global-requirements is full of information, some of it not relevant to my own use case, and it's hard to check automatically. First of all, because the Python module names as in PyPi, do not necessarily match the package names. Also, because some artifacts are not relevant to Debian. For example, I have no use of many TripleO stuff, and some services are simply not packaged in Debian.
In an ideal world, we'd have an API to check for all of this, rather than digging through the release HTML pages.
It seems like what you're asking for is this:
https://opendev.org/openstack/requirements/src/branch/stable/wallaby/upper-c...
Or rather, that's the closest thing we have to what I think you're requesting. If you follow the commit history of that file, you'll see recent updates for it on the stable/wallaby branch do consist almost entirely of stable point releases of cycle-oriented projects:
https://opendev.org/openstack/requirements/commits/branch/stable/wallaby/upp...
Does this help narrow the scope of concern to the point where we can better reason about the problems or challenges you're facing?
Unfortunately, while it is part of the answer, due to what I explained just above, it is very hard to exploit the available data without a real, long effort on our side to fix this. :/
One solution could probably be for *US* (downstream distros) to write some kind of API as I just wrote, and make it available for everyone on releases.openstack.org. Are Red Hat people also interested by such an effort? Any pointer where we should attempt to propose patches?
An API seems quite a good idea I'm ok to give help on this point with my upstream cap and my Red Hat cap. As release manager I added your proposition to our "things to changes" on our release process and tools. I think that it should be discussed first to see how to implement it and how to host it. I think that the technical details would be a transversal decision between the infra team and the release team and the volunteers on this topic. However you should notice that we are near Xena's deadline, and, so, for now, I don't think that we will have the time to work on this topic. Also, although I'm volunteering to help, you should notice that the release team will have another PTL for Y, so, the lead of this topic is at the discretion of my replacant. I think a good starting point could be to design some specs or propose some related goals, so, Thomas, maybe you could start by creating something like that with your expectations. It will allow us to start this topic, share our different feedback and our expectations on it (our different viewpoints, at least from the release team, infra team, and downstream/distros teams). Hopefully it will help us. [1] https://etherpad.opendev.org/p/xena-relmgt-tracking [2] https://governance.openstack.org/tc/goals/
Cheers,
Thomas Goirand (zigo)
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
On 9/8/21 11:31 AM, Herve Beraud wrote:
An API seems quite a good idea
I'm ok to give help on this point with my upstream cap and my Red Hat cap.
As release manager I added your proposition to our "things to changes" on our release process and tools. I think that it should be discussed first to see how to implement it and how to host it. I think that the technical details would be a transversal decision between the infra team and the release team and the volunteers on this topic.
However you should notice that we are near Xena's deadline, and, so, for now, I don't think that we will have the time to work on this topic. Also, although I'm volunteering to help, you should notice that the release team will have another PTL for Y, so, the lead of this topic is at the discretion of my replacant.
I think a good starting point could be to design some specs or propose some related goals, so, Thomas, maybe you could start by creating something like that with your expectations. It will allow us to start this topic, share our different feedback and our expectations on it (our different viewpoints, at least from the release team, infra team, and downstream/distros teams).
Hopefully it will help us.
Hi Herve, Thanks a lot for your enthusiasm, volunteering, and all. I very much agree that it's too late for Xena, though I wasn't even hoping for it that early. This was merely a suggestion. I will try to get my co-maintainer (Michal Arbet) in the loop so we can at least design the blue-print together. I also have to give this some thoughts myself before I can start. Cheers, Thomas Goirand (zigo)
Openstack enter more and more in maintenance mode, with decreasing staffs, and reduced project activity which de facto lead us to this kind of situation, so this is a rational proposition. Automation and tooling is a big part of the solution to this problem. Great, thanks for the future blue-print. Do not hesitate to ping us either on IRC or by replying to this thread. Le mer. 8 sept. 2021 à 13:28, Thomas Goirand <zigo@debian.org> a écrit :
On 9/8/21 11:31 AM, Herve Beraud wrote:
An API seems quite a good idea
I'm ok to give help on this point with my upstream cap and my Red Hat cap.
As release manager I added your proposition to our "things to changes" on our release process and tools. I think that it should be discussed first to see how to implement it and how to host it. I think that the technical details would be a transversal decision between the infra team and the release team and the volunteers on this topic.
However you should notice that we are near Xena's deadline, and, so, for now, I don't think that we will have the time to work on this topic. Also, although I'm volunteering to help, you should notice that the release team will have another PTL for Y, so, the lead of this topic is at the discretion of my replacant.
I think a good starting point could be to design some specs or propose some related goals, so, Thomas, maybe you could start by creating something like that with your expectations. It will allow us to start this topic, share our different feedback and our expectations on it (our different viewpoints, at least from the release team, infra team, and downstream/distros teams).
Hopefully it will help us.
Hi Herve,
Thanks a lot for your enthusiasm, volunteering, and all.
I very much agree that it's too late for Xena, though I wasn't even hoping for it that early. This was merely a suggestion.
I will try to get my co-maintainer (Michal Arbet) in the loop so we can at least design the blue-print together. I also have to give this some thoughts myself before I can start.
Cheers,
Thomas Goirand (zigo)
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud
On 2021-09-08 11:31:31 +0200 (+0200), Herve Beraud wrote: [...]
An API seems quite a good idea
I'm ok to give help on this point with my upstream cap and my Red Hat cap.
As release manager I added your proposition to our "things to changes" on our release process and tools. I think that it should be discussed first to see how to implement it and how to host it. I think that the technical details would be a transversal decision between the infra team and the release team and the volunteers on this topic. [...]
Note that an API in this sense can just be a consumable data structure. The amount of release metadata associated with a coordinated release of OpenStack isn't exactly tiny, but it's not so large it couldn't just be serialized into some sort of structured data file which tools can consume. The upper-constraints.txt redirector on the releases site provides one such example, though its not rich enough in detail for the described use case as far as I can tell. The series deliverable files in the releases repo are another such example, but they probably have a little too much detail and at the same time, as pointed out, don't associate independent deliverable releases with release cycles (the crux of the issue which is raised here).
I think a good starting point could be to design some specs or propose some related goals, so, Thomas, maybe you could start by creating something like that with your expectations. It will allow us to start this topic, share our different feedback and our expectations on it (our different viewpoints, at least from the release team, infra team, and downstream/distros teams). [...]
Which then begs the question, where should such a design specification document be proposed/reviewed? The release team doesn't have a specs repo, but also it might be sufficient to attempt to use this mailing list to hammer out a clearer explanation of the data people are looking for and the methods they would be comfortable employing to obtain it. -- Jeremy Stanley
On 9/9/21 3:09 PM, Jeremy Stanley wrote:
On 2021-09-08 11:31:31 +0200 (+0200), Herve Beraud wrote: [...]
An API seems quite a good idea
I'm ok to give help on this point with my upstream cap and my Red Hat cap.
As release manager I added your proposition to our "things to changes" on our release process and tools. I think that it should be discussed first to see how to implement it and how to host it. I think that the technical details would be a transversal decision between the infra team and the release team and the volunteers on this topic. [...]
Note that an API in this sense can just be a consumable data structure. The amount of release metadata associated with a coordinated release of OpenStack isn't exactly tiny, but it's not so large it couldn't just be serialized into some sort of structured data file which tools can consume.
Yes, that's more or less what I was thinking. Something like: curl -X GET http://releases.openstack.org/api/release/xena { "release-name": "xena", "components": { "oslo.config": { "version": "8.7.1", "release-date": "Thu Jul 15 10:19:24 2021 +0000", }, "oslo.db": { "version": "11.0.0", "release-date": "Mon Aug 23 10:23:24 2021 +0000", }, ... } } That'd be a way more reliable to parse than the HTML page like we do right now...
The series deliverable files in the releases repo are another such example, but they probably have a little too much detail and at the same time, as pointed out, don't associate independent deliverable releases with release cycles (the crux of the issue which is raised here).
Where's the "series deliverable files" that you're talking about?
Which then begs the question, where should such a design specification document be proposed/reviewed? The release team doesn't have a specs repo, but also it might be sufficient to attempt to use this mailing list to hammer out a clearer explanation of the data people are looking for and the methods they would be comfortable employing to obtain it.
Same over here: where should we propose such specs? Cheers, Thomas Goirand (zigo)
On 2021-09-09 17:12:01 +0200 (+0200), Thomas Goirand wrote:
On 9/9/21 3:09 PM, Jeremy Stanley wrote: [...]
The series deliverable files in the releases repo are another such example, but they probably have a little too much detail and at the same time, as pointed out, don't associate independent deliverable releases with release cycles (the crux of the issue which is raised here).
Where's the "series deliverable files" that you're talking about? [...]
https://opendev.org/openstack/releases/src/branch/master/deliverables Perhaps unsurprisingly, those pages of HTML you're parsing from the releases site are built from structured data (YAML) in the openstack/releases Git repository using a Python library also maintained in that same repo, and continuously published with Zuul jobs similar to how we publish other documentation. This Sphinx extension is a convenient window into most of it: https://opendev.org/openstack/releases/src/branch/master/doc/source/_exts/de... -- Jeremy Stanley
On 2021-09-08 10:27:50 +0200 (+0200), Thomas Goirand wrote: [...]
Ok, so your recommendation is that, for each and every component that is marked release-independent, I should be checking the global requirements. I just wrote that this is unrealistic that a human does such a check.
I'm not saying that a human needs to check it, in fact that file is machine-readable (it's used as input to pip but it's quite trivial to parse). What I said is that it's what we have now, and probably the closest thing we have to what you're asking for. It's a list of what exact versions of dependencies we test the software with, nothing more. We effectively freeze and branch that list whenever a new coordinated release of OpenStack happens, and then only adjust it to reflect stable point releases of our cycle-based deliverables. Any independent release deliverables in there are still basically frozen, treated just like any other "external" dependency of OpenStack. If it helps, we also maintain a redirector service which routes URLs like https://releases.openstack.org/constraints/upper/wallaby to a raw download of the correct file. We also make sure the codename for the cycle currently in progress is supported, so that you can begin using it in preparation for the next coordinated release.
If you didn't know, in Debian, Michal Arbet (who co-maintains OpenStack with me together in Debian) wrote this: [...] Thanks to this page, anyone can know the status of OpenStack packaging on all the different branches we maintain. If you look at it right now, you'll notice that we're up-to-date, as we packaged all non-clients and all clients library, but we didn't package new versions of the puppet manifests yet (I'm waiting for the RCs to do that).
That's very cool!
If you click on the buster-victoria button, and look for Taskflow, you'll see that it's up-to-date. If you click on bullseye-xena, and search for Taskflow, you will ... find nothing! That's because taskflow doesn't appear in https://releases.openstack.org/xena/index.html since it is release-independent. As a result, I'm left with no other choice than being very careful and manually check the global-requirements. [...]
wget -qO- https://releases.openstack.org/constraints/upper/wallaby \ | grep -i ^taskflow= wget -qO- https://releases.openstack.org/constraints/upper/xena \ | grep -i ^taskflow= Its not ideal, no, but it's fairly straightforward (not that I would do it in shell script, but parsing that with the re module in Python's stdlib is trivial, or you could use something like the packaging.requirements parser from python3-packaging). As an aside, parsing HTML is very fiddly, you might consider directly consuming the structured data maintained in the openstack/releases repository as it's far easier to script (it's YAML). I believe the openstack_releases Python package even provides modules for parsing those. -- Jeremy Stanley
participants (4)
-
Herve Beraud
-
Jeremy Stanley
-
Thierry Carrez
-
Thomas Goirand