Dependency additions to OpenStack SRU exception

James Page james.page at canonical.com
Tue Feb 6 15:17:58 UTC 2024


Hi Andreas

Picking up this thread from Corey.

On Thu, Jan 25, 2024 at 2:40 PM Andreas Hasenack <andreas at canonical.com>
wrote:

> Hi,
>
>
> On Fri, Nov 17, 2023 at 6:36 PM Corey Bryant <corey.bryant at canonical.com>
> wrote:
>
>>
>>
>> On Fri, Nov 17, 2023 at 3:54 PM Andreas Hasenack <andreas at canonical.com>
>> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Nov 17, 2023 at 5:48 PM Corey Bryant <corey.bryant at canonical.com>
>>> wrote:
>>>
>>>> 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
>>>>
>>>
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20240206/0412c68f/attachment.html>


More information about the Ubuntu-release mailing list