Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1579381 - CV publish can publish puppet before yum, causing provisioning issues
CV publish can publish puppet before yum, causing provisioning issues
Status: CLOSED ERRATA
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Content Views (Show other bugs)
6.3.1
Unspecified Unspecified
high Severity high (vote)
: 6.3.3
: Unused
Assigned To: Chris Duryee
: FieldEngineering, PrioBumpField, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2018-05-17 09:49 EDT by Chris Duryee
Modified: 2018-08-22 16:07 EDT (History)
5 users (show)

See Also:
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 16:07:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 23672 None None None 2018-05-22 12:17 EDT
Red Hat Product Errata RHBA-2018:2550 None None None 2018-08-22 16:07 EDT

  None (edit)
Description Chris Duryee 2018-05-17 09:49:06 EDT
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 pm-sat@redhat.com 2018-05-22 14:17:47 EDT
Upstream bug assigned to cduryee@redhat.com
Comment 4 pm-sat@redhat.com 2018-06-07 12:17:34 EDT
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 16:01:04 EDT
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 16:07:12 EDT
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

Note You need to log in before you can comment on or make changes to this bug.