[TripleO] openvswitch is broken - avoid rechecks in the next couple hours

Wesley Hayutin whayutin at redhat.com
Fri Feb 15 21:27:35 UTC 2019


On Fri, Feb 15, 2019 at 1:21 PM Alex Schultz <aschultz at redhat.com> wrote:

> On Fri, Feb 15, 2019 at 10:49 AM Jeremy Stanley <fungi at yuggoth.org> wrote:
> >
> > On 2019-02-15 08:23:31 +0000 (+0000), Sorin Sbarnea wrote:
> > > Is there something we can do to prevent this in the future?
> > >
> > > Unrelated to openvswitch itself, it happened with other packages
> > > too and will happen again.
> > [...]
> >
> > As in how to prevent distros from updating their packages in ways
> > which require some adjustments in our software? That's a big part of
> > why our CI system works the way it does: so we know as soon as
> > possible when we need to make modifications to keep our software
> > compatible with distributions we care about. Hiding or deferring
> > such failures just means that we get to spend more time ignoring our
> > users who are getting regular updates from their operating system
> > and are suddenly unable to use our software on it.
>
> So it's not necessarily hiding it if you can be notified a head of
> time and it doesn't disrupt the world.  Yes we need to fix it, no we
> shouldn't completely break the world on updates if possible.  Being
> able to track these changes earlier in testing is one way that we can
> get ahead of the upcoming changes and get fixes in sooner.  I know in
> tripleo we use the centos continous release repo + periodic to try and
> find these things before it breaks the world. I'm not sure of the
> specifics of this change and as to why the continuous release
> repository didn't help in this instance.  As a practice I believe we
> generally don't like pinning things on master specifically for this
> reason however we do need to be aware of the risks to the system as a
> whole and how can we mitigate the potential breakages to allow
> development to continue while still allowing updates to function as
> intended.
>
> Thanks,
> -Alex
>

It's my observation, not a fact that the rt repo is not a staging area for
every update.
The rt repo is well populated in advance of a minor update, but for updates
in the same release I think it's very much hit or miss.

http://mirror.centos.org/centos/7/rt/x86_64/Packages/?C=M;O=D


>
> > --
> > Jeremy Stanley
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190215/a3999462/attachment.html>


More information about the openstack-discuss mailing list