Dependency additions to OpenStack SRU exception

Corey Bryant corey.bryant at canonical.com
Fri Nov 17 20:48:08 UTC 2023


On Thu, Nov 16, 2023 at 4:31 PM Andreas Hasenack <andreas at canonical.com>
wrote:

> Hi Corey,
>
> On Fri, Sep 1, 2023 at 11:52 AM Corey Bryant <corey.bryant at canonical.com>
> wrote:
>
>> Hi Robie,
>>
>> Thanks for taking a look.
>>
>> On Wed, Aug 30, 2023 at 9:34 AM Robie Basak <robie.basak at ubuntu.com>
>> 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, 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20231117/1c6e887e/attachment.html>


More information about the Ubuntu-release mailing list