Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1579381

Summary: CV publish can publish puppet before yum, causing provisioning issues
Product: Red Hat Satellite Reporter: Chris Duryee <cduryee>
Component: Content ViewsAssignee: Chris Duryee <cduryee>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 6.3.1CC: andrew.schofield, jhutar, kabbott, pcreech, rplevka
Target Milestone: UnspecifiedKeywords: FieldEngineering, PrioBumpField, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tfm-rubygem-katello-3.7.0.rc1-0.1.rc1,tfm-rubygem-katello-3.4.5.75-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1596348 (view as bug list) Environment:
Last Closed: 2018-08-22 20:07:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Chris Duryee 2018-05-17 13:49:06 UTC 
Description of problem:

Let's say you have an application called MyApp, and you have a puppet module called "myapp" that says "install MyApp rpm version 15". The yum repo with the MyApp rpm and the puppet module that says "install myapp 15" are in the same CV.

Now it is time to go to myapp 16. You update the myapp yum repo with the new RPM and update the puppet module to say "install MyApp rpm version 16". You then publish a new CV version and promote it.

Puppet modules update pretty quickly, but yum repos can take longer. During this time, it's possible for new systems to get the latest version of the myapp puppet module, attempt to download myapp 16 from the yum repo, and fail.

Puppet code can reference rpms but not vice versa, so we probably want the puppet publishes to happen after the yum publishes. That way, any yum deps should already be in place when the updated puppet module lands.

Note that the gap between puppet and yum publish times is lower in 6.3 than 6.2 which gives a smaller window for this bug. However the bug still exists.

Version-Release number of selected component (if applicable): 6.2.14 but can happen with 6.3.1
Comment 3 Satellite Program 2018-05-22 18:17:47 UTC 
Upstream bug assigned to cduryee
Comment 4 Satellite Program 2018-06-07 16:17:34 UTC 
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/23672 has been resolved.
Comment 6 Roman Plevka 2018-08-02 20:01:04 UTC 
VERIFIED
on sat6.3.3-2

- one can see the subtasks are reorganized now by looking into a dynflow execution plan.
- no regression to our automation was detected
- i also tried the following:

#1 I defined a simple module which ensures the latest version of a package from a yum repo.

#2 I registered a managed host to a CV that doesn't have any relevant puppet nor yum repos exposed.

#3 then I published a new version of the CV with added the puppet module + yum repo.
at the same time i executed the following loop on a host to keep it applying the catalog compiled on satellite during the whole process of a cv publish:

<pre>
# while :
  do if [[ $(curl -sku admin:changeme https://sat6.com/foreman_tasks/api/tasks/e0f67bbe-76df-4ba1-b200-fbdeaab39343 | grep "state\":\"running") ]]; then puppet agent --test;
    fi
    sleep 10;
  done
</pre>

output:
<pre>
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for lora-sellai.foo.com
Info: Applying configuration version '1533230095'
Notice: Finished catalog run in 0.10 seconds
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
...
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for lora-sellai.foo.com
Info: Applying configuration version '1533230365'
Notice: Finished catalog run in 0.07 seconds
^C
# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for lora-sellai.foo.com
Info: Applying configuration version '1533239975'
Notice: /Stage[main]/Walrus/Package[walrus]/ensure: created
Notice: Finished catalog run in 4.25 seconds

</pre>

- there wasn't any iteration where the updated module would be triggerred without the appropriate yum repo being available.
- running the puppet again after the publish task finished, one can see the module got properly picked up and successfully installed the package from the new repo
Comment 8 errata-xmlrpc 2018-08-22 20:07:12 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:2550