Open Stack

Hi,


On Thu, Feb 2, 2023 at 12:18 PM Sean Mooney <smooney at redhat.com> wrote:

> On Thu, 2023-02-02 at 16:19 +1100, Tony Breeds wrote:
> > On Wed, 1 Feb 2023 at 04:06, Elvira Garcia Ruiz <egarciar at redhat.com>
> wrote:
> > >
> > > Hi Neutrinos!
> > >
> > > RDO folks proposed that, in order to be able to correctly build CI
> > > gates for testing, it would be nice if we tried to update the
> > > neutron-distgit requirement file when we want to update the minimal
> > > version of a dependency before merging it on our repository.
> > > This would allow them to realize whether they need or not to update
> > > any Fedora package. In order to do that, we just need to send a small
> > > commit to their repository [0]. You can use your GitHub account for
> > > the login.
> >
> > Hello,
> >     Actually I think this falls on RDO's shoulders to handle.  There
> > are, or at least were,  jobs in RDO that watch the requirements repo
> > for constraint updates and ensure that they're reflected in RDO
> > packaging.  It shouldn't be too hard to trigger a similar change to
> > the specfile when requirements.txt is updated.
> >
> > Said job could even vote -1 if it encountered a situation where the
> > minimum specified in requirements.txt is newer than the current
> > version available in RDO. As a bonus it wouldn't even be Neutron
> > specific!
> as a thrid party job sure it should not be able to block the patch form
> merging.
> >
> > It'd be kinda cool to see other distros do similar.
> ya i dont think it would be correct to give RDO special treatment
> its ment to be a downstream/midstream repackging of the upstrream code base
> it should not impact the upstream developpment and i do not agree that we
> should have to bump the
> RDO dist-gits before bumping merging a change to any project.
>

Yes, I fully agree


>
> there is automation to sync uperrconstraits to rdo in some form which
> proposes patches
> to rdo whne a new lib version is released.


Yes, there is that automation and that fixes most of the cases for minimal
required versions, as when the change in the requirements.txt is merged,
the version is already in RDO. This process has some corner cases and
dependencies which delays the updates in some cases as it happened in this
particular case. Said this, there are different levels of validation in RDO
which catch those cases (as it happened this time).


> im sure similar automation could be done for the requirements
> file if there is a min version bump.


Yes, actually there may be several approaches to implement this such as
triggering third party jobs to check changes in requirements.txt or
enabling automatic package requirements generation from requirements.txt.
Each one has its own problems and require to manage different types of
exceptions. Anyway, it's something we are still investigating. The fact
that we try to follow upper-constraints as close as possible fixes many
(not all) of the cases related to changes in requirements.txt so we didn't
implement automation on requirements.txt yet.


> but i dont think any of this should fall on upstream developers
> or core teams to do.
>

Yes. Note that some upstream neutron developers are also maintainers of the
neutron packages in RDO, which may have been misleading about the
destination for this message but you are right, this is up to RDO (core and
package maintainers), not upstream neutron.

Best regards,

Alfredo

>
> > Yours Tony.
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230202/061d9cda/attachment.htm>