Bug 1579381 - CV publish can publish puppet before yum, causing provisioning issues
Summary: CV publish can publish puppet before yum, causing provisioning issues
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Content Views
Version: 6.3.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: Unspecified
Assignee: Chris Duryee
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-17 13:49 UTC by Chris Duryee
Modified: 2019-06-13 21:26 UTC (History)
5 users (show)

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:
Clone Of:
: 1596348 (view as bug list)
Environment:
Last Closed: 2018-08-22 20:07:12 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 23672 0 Normal Closed CV publish can publish puppet before yum, causing provisioning issues 2020-12-18 15:49:32 UTC
Red Hat Product Errata RHBA-2018:2550 0 None None None 2018-08-22 20:07:47 UTC

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 pm-sat@redhat.com 2018-05-22 18:17:47 UTC
Upstream bug assigned to cduryee@redhat.com

Comment 4 pm-sat@redhat.com 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


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