Re: Dependency additions to OpenStack SRU exception
Hi, As a list of 46 packages this is rather large and non-trivial to review. Presumably we'll want to group them by upstream (are all managed by the OpenStack umbrella upstream, or are there exceptions?) and then take a view on them as a whole. On Fri, Jul 14, 2023 at 11:44:04AM -0400, Corey Bryant wrote: > python-ovsdbapp This one was in the queue and so I reviewed it independently as requested as a one-off microrelease update SRU. I ended up rejecting it as there was what looked like a behavioural change with no explanation as to why it is required, and most other upstream bugfixes did not come with tests. Details at: https://bugs.launchpad.net/charm-neutron-api/+bug/2007919/comments/19 I'm noting this in this thread for the record in case this has any bearing on the larger view. Robie signature.asc Description: PGP signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Dependency additions to OpenStack SRU exception
Hi Robie, Thanks for taking a look. On Wed, Aug 30, 2023 at 9:34 AM Robie Basak wrote: > Hi, > > As a list of 46 packages this is rather large and non-trivial to review. > Presumably we'll want to group them by upstream (are all managed by the > OpenStack umbrella upstream, or are there exceptions?) and then take a > view on them as a whole. > All of the packages in this list fall under the OpenStack umbrella upstream. The source can be found at: https://opendev.org/explore/repos All of these packages were specifically chosen because they are dependencies of the existing packages in our SRU exception list. > > On Fri, Jul 14, 2023 at 11:44:04AM -0400, Corey Bryant wrote: > > python-ovsdbapp > > This one was in the queue and so I reviewed it independently as > requested as a one-off microrelease update SRU. I ended up rejecting it > as there was what looked like a behavioural change with no explanation > as to why it is required, and most other upstream bugfixes did not come > with tests. Details at: > https://bugs.launchpad.net/charm-neutron-api/+bug/2007919/comments/19 > > I'm noting this in this thread for the record in case this has any > bearing on the larger view. > For the behavioral change [1], I think there is minimal regression potential as the change is limited to an exception path where sleeps and reconnects were determined to be unnecessary. I'd have appreciated it if they would have provided a bug reference for the commit to provide more context, however with that said, it seems they are making a code improvement here for performance reasons and they found it to be useful enough to backport to stable branches. [1] https://opendev.org/openstack/ovsdbapp/commit/ab3e0cb0d0865417efbf103f44954573a5ba92ac It is certainly not ideal to have missing unit tests. It's important to consider that we perform testing above and beyond the unit tests that are run as part of our package builds. The regression testing that we have in place for OpenStack is run for all stable releases. For that we deploy a full OpenStack cloud and then run tempest integration tests that exercise all of the packages and the cloud solution as a whole. I think we have a solid history of limiting regression potential for OpenStack users in our stable releases and that remains very important to us. One issue we have is that individual backports of bug fixes for all of these packages doesn't scale well. Another issue is that we have clouds that are running with outdated code that is missing available bug fixes. With code that is running 5 or even up to 10 years in production, providing these bug fixes to our users is important. Would it be useful to the SRU team if we were to pre-test our stable point releases in a PPA and post the results to accompany new stable release requests? Corey -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Dependency additions to OpenStack SRU exception
On Fri, Sep 1, 2023 at 10:51 AM Corey Bryant wrote: > Hi Robie, > > Thanks for taking a look. > > On Wed, Aug 30, 2023 at 9:34 AM Robie Basak > wrote: > >> Hi, >> >> As a list of 46 packages this is rather large and non-trivial to review. >> Presumably we'll want to group them by upstream (are all managed by the >> OpenStack umbrella upstream, or are there exceptions?) and then take a >> view on them as a whole. >> > > All of the packages in this list fall under the OpenStack umbrella > upstream. The source can be found at: https://opendev.org/explore/repos > All of these packages were specifically chosen because they are > dependencies of the existing packages in our SRU exception list. > > >> >> On Fri, Jul 14, 2023 at 11:44:04AM -0400, Corey Bryant wrote: >> > python-ovsdbapp >> >> This one was in the queue and so I reviewed it independently as >> requested as a one-off microrelease update SRU. I ended up rejecting it >> as there was what looked like a behavioural change with no explanation >> as to why it is required, and most other upstream bugfixes did not come >> with tests. Details at: >> https://bugs.launchpad.net/charm-neutron-api/+bug/2007919/comments/19 >> >> I'm noting this in this thread for the record in case this has any >> bearing on the larger view. >> > > For the behavioral change [1], I think there is minimal regression > potential as the change is limited to an exception path where sleeps and > reconnects were determined to be unnecessary. I'd have appreciated it if > they would have provided a bug reference for the commit to provide more > context, however with that said, it seems they are making a code > improvement here for performance reasons and they found it to be useful > enough to backport to stable branches. > [1] > https://opendev.org/openstack/ovsdbapp/commit/ab3e0cb0d0865417efbf103f44954573a5ba92ac > > It is certainly not ideal to have missing unit tests. It's important to > consider that we perform testing above and beyond the unit tests that are > run as part of our package builds. The regression testing that we have in > place for OpenStack is run for all stable releases. For that we deploy a > full OpenStack cloud and then run tempest integration tests that exercise > all of the packages and the cloud solution as a whole. > > I think we have a solid history of limiting regression potential for > OpenStack users in our stable releases and that remains very important to > us. One issue we have is that individual backports of bug fixes for all of > these packages doesn't scale well. Another issue is that we have clouds > that are running with outdated code that is missing available bug fixes. > With code that is running 5 or even up to 10 years in production, providing > these bug fixes to our users is important. > > Would it be useful to the SRU team if we were to pre-test our stable point > releases in a PPA and post the results to accompany new stable release > requests? > > Corey > Hello Robie and SRU team, I wanted to check in on this and see if there is anything I can do to help this review any easier. Please let me know if I can help in any way. Thanks, Corey -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Dependency additions to OpenStack SRU exception
Hi Corey, On Fri, Sep 1, 2023 at 11:52 AM Corey Bryant wrote: > Hi Robie, > > Thanks for taking a look. > > On Wed, Aug 30, 2023 at 9:34 AM Robie Basak > wrote: > >> Hi, >> >> As a list of 46 packages this is rather large and non-trivial to review. >> Presumably we'll want to group them by upstream (are all managed by the >> OpenStack umbrella upstream, or are there exceptions?) and then take a >> view on them as a whole. >> > > All of the packages in this list fall under the OpenStack umbrella > upstream. The source can be found at: https://opendev.org/explore/repos > All of these packages were specifically chosen because they are > dependencies of the existing packages in our SRU exception list. > Could you also check the reverse dependencies of these packages in the Ubuntu Archive, to see what, if anything, other than openstack, might be using them? If we start updating them to new upstream versions, albeit still within a stable release track, we might be affecting their rdeps. And given the example from Robie below on python-ovsdbapp, when he analyzed python-ovsdbapp, do you think you would be able to highlight usptream changes in behavior, if they exist, in the future SRUs? In general, MREs should not have those, of course. > On Fri, Jul 14, 2023 at 11:44:04AM -0400, Corey Bryant wrote: >> > python-ovsdbapp >> >> This one was in the queue and so I reviewed it independently as >> requested as a one-off microrelease update SRU. I ended up rejecting it >> as there was what looked like a behavioural change with no explanation >> as to why it is required, and most other upstream bugfixes did not come >> with tests. Details at: >> https://bugs.launchpad.net/charm-neutron-api/+bug/2007919/comments/19 >> >> I'm noting this in this thread for the record in case this has any >> bearing on the larger view. >> > > For the behavioral change [1], I think there is minimal regression > potential as the change is limited to an exception path where sleeps and > reconnects were determined to be unnecessary. I'd have appreciated it if > they would have provided a bug reference for the commit to provide more > context, however with that said, it seems they are making a code > improvement here for performance reasons and they found it to be useful > enough to backport to stable branches. > [1] > https://opendev.org/openstack/ovsdbapp/commit/ab3e0cb0d0865417efbf103f44954573a5ba92ac > > It is certainly not ideal to have missing unit tests. It's important to > consider that we perform testing above and beyond the unit tests that are > run as part of our package builds. The regression testing that we have in > place for OpenStack is run for all stable releases. For that we deploy a > full OpenStack cloud and then run tempest integration tests that exercise > all of the packages and the cloud solution as a whole. > > I think we have a solid history of limiting regression potential for > OpenStack users in our stable releases and that remains very important to > us. One issue we have is that individual backports of bug fixes for all of > these packages doesn't scale well. Another issue is that we have clouds > that are running with outdated code that is missing available bug fixes. > With code that is running 5 or even up to 10 years in production, providing > these bug fixes to our users is important. > > Would it be useful to the SRU team if we were to pre-test our stable point > releases in a PPA and post the results to accompany new stable release > requests? > I don't think that would be very useful for SRU purposes, because the tests would have to be run again once the packages are in proposed. You can of course run them before, to get a feeling on how a particular update would behave. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Dependency additions to OpenStack SRU exception
On Thu, Nov 16, 2023 at 4:31 PM Andreas Hasenack wrote: > Hi Corey, > > On Fri, Sep 1, 2023 at 11:52 AM Corey Bryant > wrote: > >> Hi Robie, >> >> Thanks for taking a look. >> >> On Wed, Aug 30, 2023 at 9:34 AM Robie Basak >> wrote: >> >>> Hi, >>> >>> As a list of 46 packages this is rather large and non-trivial to review. >>> Presumably we'll want to group them by upstream (are all managed by the >>> OpenStack umbrella upstream, or are there exceptions?) and then take a >>> view on them as a whole. >>> >> >> All of the packages in this list fall under the OpenStack umbrella >> upstream. The source can be found at: https://opendev.org/explore/repos >> All of these packages were specifically chosen because they are >> dependencies of the existing packages in our SRU exception list. >> > > Could you also check the reverse dependencies of these packages in the > Ubuntu Archive, to see what, if anything, other than openstack, might be > using them? If we start updating them to new upstream versions, albeit > still within a stable release track, we might be affecting their rdeps. > > Hi Andreas, Thanks for taking a look. I've put a full list of rdepends here: https://github.com/coreycb/reverse-depends/blob/main/reverse-depends It is mostly OpenStack packages, but I did find a few non-openstack packages: fence-agents-compute (Depends: python3-novaclient) fence-agents-openstack (Depends: python3-novaclient) fence-agents-ironic (Depends: python3-openstackclient) jeepyb (Depends: python3-swiftclient) prometheus-openstack-exporter (Depends: python3-cinderclient, python3-keystoneclient, python3-neutronclient, python3-novaclient, python3-swift) python3-novnc (Depends: python3-oslo.config, Reverse Depends: nova-novncproxy, qemu-web-desktop) It is worth noting that OpenStack stable releases cannot include incompatible API changes. And given the example from Robie below on python-ovsdbapp, when he analyzed > python-ovsdbapp, do you think you would be able to highlight usptream > changes in behavior, if they exist, in the future SRUs? In general, MREs > should not have those, of course. > > I'm hesitant to do this because I think it would get noisy. In my experience, bug fixes often change behavior, but not in an incompatible way. Would it be useful to provide a summary of commits included in a stable release? We might be able to include that in the debian/changelog even. In some cases, such as neutron, I probably would not want to do that because the number of commits (sometimes 50+) could pollute the changelog, but I think in general it could be useful to end users. Thanks, Corey > > >> On Fri, Jul 14, 2023 at 11:44:04AM -0400, Corey Bryant wrote: >>> > python-ovsdbapp >>> >>> This one was in the queue and so I reviewed it independently as >>> requested as a one-off microrelease update SRU. I ended up rejecting it >>> as there was what looked like a behavioural change with no explanation >>> as to why it is required, and most other upstream bugfixes did not come >>> with tests. Details at: >>> https://bugs.launchpad.net/charm-neutron-api/+bug/2007919/comments/19 >>> >>> I'm noting this in this thread for the record in case this has any >>> bearing on the larger view. >>> >> >> For the behavioral change [1], I think there is minimal regression >> potential as the change is limited to an exception path where sleeps and >> reconnects were determined to be unnecessary. I'd have appreciated it if >> they would have provided a bug reference for the commit to provide more >> context, however with that said, it seems they are making a code >> improvement here for performance reasons and they found it to be useful >> enough to backport to stable branches. >> [1] >> https://opendev.org/openstack/ovsdbapp/commit/ab3e0cb0d0865417efbf103f44954573a5ba92ac >> >> It is certainly not ideal to have missing unit tests. It's important to >> consider that we perform testing above and beyond the unit tests that are >> run as part of our package builds. The regression testing that we have in >> place for OpenStack is run for all stable releases. For that we deploy a >> full OpenStack cloud and then run tempest integration tests that exercise >> all of the packages and the cloud solution as a whole. >> >> I think we have a solid history of limiting regression potential for >> OpenStack users in our stable releases and that remains very important to >> us. One issue we have is that individual backports of bug fixes for all of >> these packages doesn't scale well. Another issue is that we have clouds >> that are running with outdated code that is missing available bug fixes. >> With code that is running 5 or even up to 10 years in production, providing >> these bug fixes to our users is important. >> >> Would it be useful to the SRU team if we were to pre-test our stable >> point releases in a PPA and post the results to accompany new stable >> release requests? >> > > I don't think that would be very useful for SRU purposes, beca
Re: Dependency additions to OpenStack SRU exception
Hi, On Fri, Nov 17, 2023 at 5:48 PM Corey Bryant wrote: > On Thu, Nov 16, 2023 at 4:31 PM Andreas Hasenack > wrote: > >> Hi Corey, >> >> On Fri, Sep 1, 2023 at 11:52 AM Corey Bryant >> wrote: >> >>> Hi Robie, >>> >>> Thanks for taking a look. >>> >>> On Wed, Aug 30, 2023 at 9:34 AM Robie Basak >>> wrote: >>> Hi, As a list of 46 packages this is rather large and non-trivial to review. Presumably we'll want to group them by upstream (are all managed by the OpenStack umbrella upstream, or are there exceptions?) and then take a view on them as a whole. >>> >>> All of the packages in this list fall under the OpenStack umbrella >>> upstream. The source can be found at: https://opendev.org/explore/repos >>> All of these packages were specifically chosen because they are >>> dependencies of the existing packages in our SRU exception list. >>> >> >> Could you also check the reverse dependencies of these packages in the >> Ubuntu Archive, to see what, if anything, other than openstack, might be >> using them? If we start updating them to new upstream versions, albeit >> still within a stable release track, we might be affecting their rdeps. >> >> > Hi Andreas, > > Thanks for taking a look. > > I've put a full list of rdepends here: > https://github.com/coreycb/reverse-depends/blob/main/reverse-depends > Thanks for this! > It is mostly OpenStack packages, but I did find a few non-openstack > packages: > > fence-agents-compute (Depends: python3-novaclient) > fence-agents-openstack (Depends: python3-novaclient) > fence-agents-ironic (Depends: python3-openstackclient) > jeepyb (Depends: python3-swiftclient) > prometheus-openstack-exporter (Depends: python3-cinderclient, > python3-keystoneclient, python3-neutronclient, python3-novaclient, > python3-swift) > python3-novnc (Depends: python3-oslo.config, Reverse Depends: > nova-novncproxy, qemu-web-desktop) > Interesting, fence-agents are part of the HA stack and looked after by the server team. The rdep on novaclient suggests it could also be relying on command-line options to the /usr/bin/nova tool. I suppose incompatible changes in the command-line arguments are also strictly not allowed? > > It is worth noting that OpenStack stable releases cannot include > incompatible API changes. > > And given the example from Robie below on python-ovsdbapp, when he >> analyzed python-ovsdbapp, do you think you would be able to highlight >> usptream changes in behavior, if they exist, in the future SRUs? In >> general, MREs should not have those, of course. >> >> > I'm hesitant to do this because I think it would get noisy. In my > experience, bug fixes often change behavior, but not in an incompatible way. > > Would it be useful to provide a summary of commits included in a stable > release? We might be able to include that in the debian/changelog even. In > some cases, such as neutron, I probably would not want to do that because > the number of commits (sometimes 50+) could pollute the changelog, but I > think in general it could be useful to end users. > We wouldn't want something like this in d/changelog, no. We would be relying on you do perform this check, and highlight what you think could be an incompatible change, or significant change in behavior. Would that work? -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Dependency additions to OpenStack SRU exception
On Fri, Nov 17, 2023 at 3:54 PM Andreas Hasenack wrote: > Hi, > > On Fri, Nov 17, 2023 at 5:48 PM Corey Bryant > wrote: > >> On Thu, Nov 16, 2023 at 4:31 PM Andreas Hasenack >> wrote: >> >>> Hi Corey, >>> >>> On Fri, Sep 1, 2023 at 11:52 AM Corey Bryant >>> wrote: >>> Hi Robie, Thanks for taking a look. On Wed, Aug 30, 2023 at 9:34 AM Robie Basak wrote: > Hi, > > As a list of 46 packages this is rather large and non-trivial to > review. > Presumably we'll want to group them by upstream (are all managed by the > OpenStack umbrella upstream, or are there exceptions?) and then take a > view on them as a whole. > All of the packages in this list fall under the OpenStack umbrella upstream. The source can be found at: https://opendev.org/explore/repos All of these packages were specifically chosen because they are dependencies of the existing packages in our SRU exception list. >>> >>> Could you also check the reverse dependencies of these packages in the >>> Ubuntu Archive, to see what, if anything, other than openstack, might be >>> using them? If we start updating them to new upstream versions, albeit >>> still within a stable release track, we might be affecting their rdeps. >>> >>> >> Hi Andreas, >> >> Thanks for taking a look. >> >> I've put a full list of rdepends here: >> https://github.com/coreycb/reverse-depends/blob/main/reverse-depends >> > > Thanks for this! > > >> It is mostly OpenStack packages, but I did find a few non-openstack >> packages: >> >> fence-agents-compute (Depends: python3-novaclient) >> fence-agents-openstack (Depends: python3-novaclient) >> fence-agents-ironic (Depends: python3-openstackclient) >> jeepyb (Depends: python3-swiftclient) >> prometheus-openstack-exporter (Depends: python3-cinderclient, >> python3-keystoneclient, python3-neutronclient, python3-novaclient, >> python3-swift) >> python3-novnc (Depends: python3-oslo.config, Reverse Depends: >> nova-novncproxy, qemu-web-desktop) >> > > Interesting, fence-agents are part of the HA stack and looked after by the > server team. The rdep on novaclient suggests it could also be relying on > command-line options to the /usr/bin/nova tool. I suppose incompatible > changes in the command-line arguments are also strictly not allowed? > > That is correct, incompatible changes to the the CLI are not allowed. > >> >> It is worth noting that OpenStack stable releases cannot include >> incompatible API changes. >> >> And given the example from Robie below on python-ovsdbapp, when he >>> analyzed python-ovsdbapp, do you think you would be able to highlight >>> usptream changes in behavior, if they exist, in the future SRUs? In >>> general, MREs should not have those, of course. >>> >>> >> I'm hesitant to do this because I think it would get noisy. In my >> experience, bug fixes often change behavior, but not in an incompatible way. >> >> Would it be useful to provide a summary of commits included in a stable >> release? We might be able to include that in the debian/changelog even. In >> some cases, such as neutron, I probably would not want to do that because >> the number of commits (sometimes 50+) could pollute the changelog, but I >> think in general it could be useful to end users. >> > > We wouldn't want something like this in d/changelog, no. We would be > relying on you do perform this check, and highlight what you think could be > an incompatible change, or significant change in behavior. Would that work? > > Yes, that makes sense. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Dependency additions to OpenStack SRU exception
Hi, On Fri, Nov 17, 2023 at 6:36 PM Corey Bryant wrote: > > > On Fri, Nov 17, 2023 at 3:54 PM Andreas Hasenack > wrote: > >> Hi, >> >> On Fri, Nov 17, 2023 at 5:48 PM Corey Bryant >> wrote: >> >>> On Thu, Nov 16, 2023 at 4:31 PM Andreas Hasenack >>> wrote: >>> Hi Corey, On Fri, Sep 1, 2023 at 11:52 AM Corey Bryant < corey.bry...@canonical.com> wrote: > Hi Robie, > > Thanks for taking a look. > > On Wed, Aug 30, 2023 at 9:34 AM Robie Basak > wrote: > >> Hi, >> >> As a list of 46 packages this is rather large and non-trivial to >> review. >> Presumably we'll want to group them by upstream (are all managed by >> the >> OpenStack umbrella upstream, or are there exceptions?) and then take a >> view on them as a whole. >> > > All of the packages in this list fall under the OpenStack umbrella > upstream. The source can be found at: > https://opendev.org/explore/repos > All of these packages were specifically chosen because they are > dependencies of the existing packages in our SRU exception list. > Could you also check the reverse dependencies of these packages in the Ubuntu Archive, to see what, if anything, other than openstack, might be using them? If we start updating them to new upstream versions, albeit still within a stable release track, we might be affecting their rdeps. >>> Hi Andreas, >>> >>> Thanks for taking a look. >>> >>> I've put a full list of rdepends here: >>> https://github.com/coreycb/reverse-depends/blob/main/reverse-depends >>> >> >> Thanks for this! >> >> >>> It is mostly OpenStack packages, but I did find a few non-openstack >>> packages: >>> >>> fence-agents-compute (Depends: python3-novaclient) >>> fence-agents-openstack (Depends: python3-novaclient) >>> fence-agents-ironic (Depends: python3-openstackclient) >>> jeepyb (Depends: python3-swiftclient) >>> prometheus-openstack-exporter (Depends: python3-cinderclient, >>> python3-keystoneclient, python3-neutronclient, python3-novaclient, >>> python3-swift) >>> python3-novnc (Depends: python3-oslo.config, Reverse Depends: >>> nova-novncproxy, qemu-web-desktop) >>> >> >> Interesting, fence-agents are part of the HA stack and looked after by >> the server team. The rdep on novaclient suggests it could also be relying >> on command-line options to the /usr/bin/nova tool. I suppose incompatible >> changes in the command-line arguments are also strictly not allowed? >> >> jeepyb seems to be under the openstack umbrella ( https://opendev.org/explore/repos?sort=recentupdate&language=&q=jeepyb&only_show_relevant=false), it's just not in the list of packages that are tested together with an openstack release, right? I think this is the remaining question mark: what can be done to make sure these rdeps listed above don't break when the openstack packages get a new upstream version? Are you recommending that the API and command-line stability promises are sufficient? -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Dependency additions to OpenStack SRU exception
Hi Andreas Picking up this thread from Corey. On Thu, Jan 25, 2024 at 2:40 PM Andreas Hasenack wrote: > Hi, > > > On Fri, Nov 17, 2023 at 6:36 PM Corey Bryant > wrote: > >> >> >> On Fri, Nov 17, 2023 at 3:54 PM Andreas Hasenack >> wrote: >> >>> Hi, >>> >>> On Fri, Nov 17, 2023 at 5:48 PM Corey Bryant >>> wrote: >>> On Thu, Nov 16, 2023 at 4:31 PM Andreas Hasenack wrote: > Hi Corey, > > On Fri, Sep 1, 2023 at 11:52 AM Corey Bryant < > corey.bry...@canonical.com> wrote: > >> Hi Robie, >> >> Thanks for taking a look. >> >> On Wed, Aug 30, 2023 at 9:34 AM Robie Basak >> wrote: >> >>> Hi, >>> >>> As a list of 46 packages this is rather large and non-trivial to >>> review. >>> Presumably we'll want to group them by upstream (are all managed by >>> the >>> OpenStack umbrella upstream, or are there exceptions?) and then take >>> a >>> view on them as a whole. >>> >> >> All of the packages in this list fall under the OpenStack umbrella >> upstream. The source can be found at: >> https://opendev.org/explore/repos >> All of these packages were specifically chosen because they are >> dependencies of the existing packages in our SRU exception list. >> > > Could you also check the reverse dependencies of these packages in the > Ubuntu Archive, to see what, if anything, other than openstack, might be > using them? If we start updating them to new upstream versions, albeit > still within a stable release track, we might be affecting their rdeps. > > Hi Andreas, Thanks for taking a look. I've put a full list of rdepends here: https://github.com/coreycb/reverse-depends/blob/main/reverse-depends >>> >>> Thanks for this! >>> >>> It is mostly OpenStack packages, but I did find a few non-openstack packages: fence-agents-compute (Depends: python3-novaclient) fence-agents-openstack (Depends: python3-novaclient) fence-agents-ironic (Depends: python3-openstackclient) jeepyb (Depends: python3-swiftclient) prometheus-openstack-exporter (Depends: python3-cinderclient, python3-keystoneclient, python3-neutronclient, python3-novaclient, python3-swift) python3-novnc (Depends: python3-oslo.config, Reverse Depends: nova-novncproxy, qemu-web-desktop) >>> >>> Interesting, fence-agents are part of the HA stack and looked after by >>> the server team. The rdep on novaclient suggests it could also be relying >>> on command-line options to the /usr/bin/nova tool. I suppose incompatible >>> changes in the command-line arguments are also strictly not allowed? >>> >>> > jeepyb seems to be under the openstack umbrella ( > https://opendev.org/explore/repos?sort=recentupdate&language=&q=jeepyb&only_show_relevant=false), > it's just not in the list of packages that are tested together with an > openstack release, right? > > I think this is the remaining question mark: what can be done to make sure > these rdeps listed above don't break when the openstack packages get a new > upstream version? Are you recommending that the API and command-line > stability promises are sufficient? > The OpenStack project uses some pretty strong standards for semantic versioning: https://docs.openstack.org/pbr/latest/user/semver.html which gives us as a distribution a clear signal from the upstream development and release team when behaviour has changed. Public API in this instance refers to the REST API, Python API and command line interface for any tools as well. Typically we see regular patch version updates (bug fixes only), with occasional minor version updates (signalling backwards compatible changes in Public API's). A major version update would only be associated with a whole new release of OpenStack, which is definitely outside of the scope of any SRU related activity. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
