Bug 2031096

Created redmine issue https://projects.theforeman.org/issues/34127 from this bug

I can reproduce very reliably now, on few various sets of repos included (everytime BaseOS+App+Suppl(+some others)).

When I run *one* CV publish, I can reproduce easily. When I run *multiple* similar CV publishes, I can *not* reproduce.

That is interesting clue (and horrifying - how parallel CV publish can affect another one???). Concurrent CV publishes sounds like a workaround (very strange one).

Upstream bug assigned to aruzicka

Upstream bug assigned to aruzicka

I can *not* reproduce it on Sat6.9. Tried 50ish times, on "the customer reproducer setup", with "reordered" repos in the CV (cf https://bugzilla.redhat.com/show_bug.cgi?id=1917076#c16), no way.

Until the reproducer depends also on some config (that is set on my 6.8 but not on my 6.9), or there is a tricky race condition else-where, it sounds that 6.9 fixes the bug.

I tried to spot a bugfix in 6.9 or 6.9.z errata that might affect this, but neither BZ sounds really applicable.

Most "applicable" BZs:
- https://pulp.plan.io/issues/7898
  - this improves speed in 6.9, which can impact the expected concurrency bug. But alone, no real change in behavour. Still maybe worth trying to patch 6.8 and test?
- https://bugzilla.redhat.com/show_bug.cgi?id=1952609
  - Caps Sync speed improvement / similar to previous, if it ever applies to Sat

(In reply to Pavel Moravec from comment #9)
> I can *not* reproduce it on Sat6.9. Tried 50ish times, on "the customer
> reproducer setup", with "reordered" repos in the CV (cf
> https://bugzilla.redhat.com/show_bug.cgi?id=1917076#c16), no way.

We 8can8 reproduce on 6.9.6, but *different* errata and their content appears in the CV.

So far minimalistic reproducer (on 6.9.6):
- RHEL8 BaseOS + AppStream + Supplementary repos
- exclude errata issued after 2021-10-01

Publish the CV, and see e.g.:

zgrep -c "issued date=\"2021-1[0-2]" /var/lib/pulp/published/yum/master/yum_distributor/1-cv_03094967_BaseOS_App_Suppl-v10_0-a667af9c-7005-4ca0-9d4d-8d3434c51803/1639171203.43/repodata/43e53782a597d447acb29a7c6f7f00115f5662e8a68854b838af2f99aabb0d97-updateinfo.xml.gz

returns 20 errata issued after the cut-off date :-/

Since 6.9 provides *less* errors than 6.8, there is assumed some 6.8->6.9 improvement.

Attempting to backporting to 6.8 fixes of:

https://projects.theforeman.org/issues/30827
https://projects.theforeman.org/issues/30828
https://bugzilla.redhat.com/show_bug.cgi?id=1952609
https://pulp.plan.io/issues/7898

(particular patch applied: http://pastebin.test.redhat.com/1015289)

that I evaluated as perspective diff between 6.8 and 6.9, this has *not* helped anyhow (so far, in 1 test run).


I haven't touched libsolv that differs between the versions (6.8 has 0.7.4-4, 6.9 has 0.7.17-1), that should be tried as well.

The original request was revealed as "unsupported" CV set-up, where demanding the contradicting requirements (exclude filters vs. concurrently applied dependency to add some stuff) within one CV can lead to generally unpredictable results.

WebUI(*) should protect using such "unsupported" settings combinations, where we can't guarantee proper outcome of combination of selected features (include filters vs. exclude filters vs. dependency solving). This is requested as a HF over Sat6.8.

(thinking about technical implementation and user experience: it can be hard to "recalculate" currently set-up configuration, whenever user modifies anything in WebUI - there are multiple such places where we had to run that check. Rather we should add that check just before publish or promote action, to warn (or strictly disallow?) the user to publish/promote content for which the user requests contradicting/unsupported set of requirements (e.g. exclude filters and depsolving). This approach will aslo allow the user to "play" with the CV setting like "now I enable depsolving and then remove exclude filters, before I will publish".)

This HF work should be aligned with the doc change in the same area: https://bugzilla.redhat.com/show_bug.cgi?id=2034804

Unanswered questions:
- should we _warn_ or totally disallow such setups? (I lean to the warning, just in case a customer really wants to (e.g. experiment with) use some setup)
- and what about hammer and API? Should be the change in WebUI only, or in our API that WebUI uses?
- is such warning/prohibition required also for CV promote? As that does not calculate a new content, it just copies some already existing stuff


I am changing BZ Subject to reflect this change of BZ scope.

I don't have strong preferences what combinations should be strictly disallowed (if any) or what combinations should be followed by warning message. Simply, the current status (barely any warning, no prohibition even when we expect dependency issues) is insufficient. Even after the December's lesson from "exclude newest errata and enable depsolving => source of troubles", I dont feel confident enough to state when we shall warn and when/if to disallow something. I am leaving the particular decisions to more knowledgable devels, here.

I don't think I'll add the warning to the API, because the only way to do that would be with a --force option which would be a breaking API change.

Also, per your earlier question, we shouldn't need a warning for promotion as well.  Content isn't being copied there.

I'll be adding this extra warning first to upstream because dep solving cannot 100% guarantee a successful yum update even for Pulp 3.

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/34127 has been resolved.

This issue is specific to Satellite 6.9 and below, which are now EOL. As such, I am closing this issue as fixed by the current release.