Heads up! Influence of our recent Mock/Proxy changes on Lago jobs
Anton Marchukov
amarchuk at redhat.com
Fri Dec 23 19:43:19 UTC 2016
>
> I did not query Sandro about why he did the update the way he did. He
> knows far more then I do about the various build processes of the
> various packages and oVirt, an I tend to trust his judgement.
>
But we should (CCing Sandro). I do not see any mistrust here. Even if we
can make our infra behave abnormal way there is no warranty that such RPM
will not get wild (or be prevented from going out). We cannot clear caches
of all of our users. I even not sure how repoman will behave when oVirt
releases are composed in this case, it does not compare RPM content and
assumes that they are immutable as designed.
So makes sense to check this.
This can take time, every maintainer has his own (bad) habits, and not
> everyone will agree to do what we want (Some downright regard oVirt as
> a "downstream" consumer and refuse to do anything that they regard as
> oVirt-specific!).
>
This is correct. So sounds like we need to send an announcement that RPM
versions are supposed to change when content change and see who have issues
with this and try to analyse why and help if needed.
In the meantime we need to be resilient to such issues if we can. We
> can`t just let everything fail while we try to "fix the world".
>
Meantime if we need to support this we have to disable caching for
everything minus repos we know follow the rules. But I would insist that
this is not normal situation and we need to have an idea of how we notify
people to fix it and how we can help.
And we are not fixing the world. yum is there for a long time and world is
ok. It is just we have problem in our stuff we need to fix so we can use
all the systems the world designed for us.
> Also, next time around, we could be seeing similar caching issues with
> a non-yum/rpm file, so its good to have a deep understanding of the
> data paths into our system.
>
Afaik we have a configuration on proxy server that caches only immutable
content for yum repos? So this is indeed an interesting discovery!
Anton.
--
Anton Marchukov
Senior Software Engineer - RHEV CI - Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20161223/706b27e3/attachment.html>
More information about the Infra
mailing list