Bug 1267521 - Medium is not updated after OS is changed on client
Medium is not updated after OS is changed on client
Status: NEW
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Content Management (Show other bugs)
6.1.2
All Linux
medium Severity medium (vote)
: GA
: --
Assigned To: satellite6-bugs
Katello QA List
: Triaged
Depends On: 1426373 1155704 1261667
Blocks: 1122832 1296845
  Show dependency treegraph
 
Reported: 2015-09-30 05:26 EDT by Peter Vreman
Modified: 2017-12-13 02:59 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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)
showing selection of synced content (49.88 KB, image/png)
2017-02-07 11:02 EST, Justin Sherrill
no flags Details

  None (edit)
Description Peter Vreman 2015-09-30 05:26:53 EDT
Description of problem:
The Medium is not updated after the OS is updated through a facts import. This in the end will break any futher host updates, e.g. changing puppet environment with the for that change unrelated error:

curl -K /opt/hoici/etc/sat6/curl-hoici.conf "-HContent-Type: application/json" "-d{\"per_page\":9999,\"host\":{\"environment_id\":51}}" -XPUT https://localhost/api/v2/hosts/2
{"error": {"id":2,"errors":{"medium_id":["Hilti/Library/Red_Hat_Server/Red_Hat_Enterprise_Linux_6_Server_Kickstart_x86_64_6_5 does not belong to RedHat 6.7 operating system"]},"full_messages":["Medium Hilti/Library/Red_Hat_Server/Red_Hat_Enterprise_Linux_6_Server_Kickstart_x86_64_6_5 does not belong to RedHat 6.7 operating system"]}}

It can be reproduced by faking the RedHat release in /etc/redhat-release and uploading facts

#
# Initial situation where the OS is on 6.5 that matches the current associated medium 6.5 kickstart
#

vrempet@li-lc-1589 ~
$ sudo sed 's+release [0-9]\.[0-9]+release 6.5+' -i /etc/redhat-release

vrempet@li-lc-1589 ~
$ facter -p | grep oper
operatingsystem => RedHat
operatingsystemmajrelease => 6
operatingsystemrelease => 6.5

vrempet@li-lc-1589 ~
$ sudo puppet agent -t --tags=factsonly
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/hilti_oracle.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/hilti_provisioning.rb
Info: Loading facts in /var/lib/puppet/lib/facter/hilti_hardware.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/hilti_os.rb
Info: Caching catalog for li-lc-1589.hag.hilti.com
Info: Applying configuration version '1443604200'
Notice: Finished catalog run in 2.44 seconds


[crash] root@li-lc-1578:~# curl -K /opt/hoici/etc/sat6/curl-hoici.conf "-HContent-Type: application/json" "-d{\"per_page\":9999}" -XGET https://localhost/api/v2/hosts/2 | jq . | egrep '(operating|medium)'
  "medium_name": "Hilti/Library/Red_Hat_Server/Red_Hat_Enterprise_Linux_6_Server_Kickstart_x86_64_6_5",
  "medium_id": 7,
  "operatingsystem_name": "RedHat 6.5",
  "operatingsystem_id": 2,


#
# Now fake that the OS is upgraded to 6.7 and notice that the medium is not updated to match the 6.7 kickstart
#
  
vrempet@li-lc-1589 ~
$ sudo sed 's+release [0-9]\.[0-9]+release 6.7+' -i /etc/redhat-release

vrempet@li-lc-1589 ~
$ facter -p | grep oper
operatingsystem => RedHat
operatingsystemmajrelease => 6
operatingsystemrelease => 6.7

vrempet@li-lc-1589 ~
$ sudo puppet agent -t --tags=factsonly
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/hilti_oracle.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/hilti_provisioning.rb
Info: Loading facts in /var/lib/puppet/lib/facter/hilti_hardware.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/hilti_os.rb
Info: Caching catalog for li-lc-1589.hag.hilti.com
Info: Applying configuration version '1443604200'
Notice: Finished catalog run in 2.54 seconds

  
[crash] root@li-lc-1578:~# curl -K /opt/hoici/etc/sat6/curl-hoici.conf "-HContent-Type: application/json" "-d{\"per_page\":9999}" -XGET https://localhost/api/v2/hosts/2 | jq . | egrep '(operating|medium)'
  "medium_name": "Hilti/Library/Red_Hat_Server/Red_Hat_Enterprise_Linux_6_Server_Kickstart_x86_64_6_5",
  "medium_id": 7,
  "operatingsystem_name": "RHEL Server 6.7",
  "operatingsystem_id": 3,

#
# Now try to update the comment when the host is managed
#
[crash] root@li-lc-1578:~# curl -K /opt/hoici/etc/sat6/curl-hoici.conf "-HContent-Type: application/json" "-d{\"per_page\":9999,\"host\":{\"managed\":true,\"comment\":\"foobar\"}}" -XPUT https://localhost/api/v2/hosts/2
{
  "error": {"id":2,"errors":{"medium_id":["Hilti/Library/Red_Hat_Server/Red_Hat_Enterprise_Linux_6_Server_Kickstart_x86_64_6_5 does not belong to RedHat 6.7 operating system"]},"full_messages":["Medium Hilti/Library/Red_Hat_Server/Red_Hat_Enterprise_Linux_6_Server_Kickstart_x86_64_6_5 does not belong to RedHat 6.7 operating system"]}
}


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Query OS and Medium through API or hammer of host A
2. On the host A change the OS in /etc/redhat-release
3. Query OS and Medium through API or hammer of host A
4. Change the 

Actual results:
The medium ID is not changed

Expected results:
The medium ID is updated to match the new OS ID

Additional info:
Comment 2 Christian Horn 2016-01-19 10:28:12 EST
This situation was reproduced by a colleague.  Details from a specialist looking at the environment: 

Looks like when your host system was updated to 7.2 and puppet updated satellite with new facts, satellite itself didn't update the associated media for the host in the db. The host record in the db has a wrong association of OS and media. So, bz1267521 is a perfect match. However, I would advise to use variables (like $minor) in media path to avoid further problems with upgrades.

foreman=# select operatingsystem_id,medium_id,name from hosts where name like 'test01%';
 operatingsystem_id | medium_id |           name            
--------------------+-----------+---------------------------
                  2 |         7 | test01.subdomain.example.com
(1 row)
 
foreman=# select * from operatingsystems where id = 2;
 id | major |  name  | minor | nameindicator |         created_at         |        updated_at         | release_name |  type  | description | hosts_count | hostgroups_count | password_hash |   title    
----+-------+--------+-------+---------------+----------------------------+---------------------------+--------------+--------+-------------+-------------+------------------+---------------+------------
  2 | 7     | RedHat | 2     |               | 2015-11-19 19:07:09.039974 | 2016-01-15 13:33:20.23418 |              | Redhat |             |           2 |                0 | MD5           | RedHat 7.2
(1 row)
 
 
foreman=# select * from media where id = 7;
 id |                                        name                                        |                                                   path                                                   |         created_at         |      
 updated_at         | media_path | config_path | image_path | os_family
----+------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------+----------------------------+-------
--------------------+------------+-------------+------------+-----------
  7 | ACME/Library/Red_Hat_Server/Red_Hat_Enterprise_Linux_7_Server_Kickstart_x86_64_7_1 | http://sat61.subdomain.example.com/pulp/repos/ACME/Library/content/dist/rhel/server/7/7.1/x86_64/kickstart/ | 2015-07-13 11:56:30.599173 | 2015-0
7-28 12:15:02.94173 |            |             |            | Redhat
(1 row)

Does this help us to create a solution?
Comment 4 Peter Vreman 2016-12-27 05:14:55 EST
The change in BZ1155704 to add 'ignore_facts_for_operatingsystem' does not solve my use case.
Currently I use the facts of the operatingsystem to give me the info what the current installed operatingsystem is.

I think the it needs a bit more rework then the, in my opinion workaround to ignore facts.

It is more the situation of ist and soll situation when used in the Satellite scenario:
- The target operatingsystem is defined by the ActivationKey through the ContentView and release_version variable.
- The current operatingsystem is retrieve from the clients through the operatingsystem fact.

The use of the ActivationKeys and ContentViews is the major the difference how i as a Satellite with Content Management user uses Foreman and how a standalone Foreman (pupept and provisioning only) installation works.
Comment 5 Steven Mercurio 2017-02-02 18:13:24 EST
I also have an issue with ANYTHING changing the operating system item defined for any host other than a change of hostgroup.  What if I have:

RHEL Server 7.3
RHEL Server 7.3a
RHEL Server 7.3b
RHEL Server 7.3c

and I have different partition tables and templates defined for each one?  After puppet runs it changes the OS to:

RHEL Server 7.3

then my templates and settings are all wrong.

I opened case#: 01785121  around this also.
Comment 9 Justin Sherrill 2017-02-07 11:02 EST
Created attachment 1248446 [details]
showing selection of synced content
Comment 10 Tomer Brisker 2017-02-09 08:33:33 EST
Steven - would the fix for BZ1155704 which will allow preventing OS updates based on puppet facts be sufficient for your use case?
Comment 11 Tomer Brisker 2017-02-12 03:40:28 EST
Clearing needinfo as comment on the other bug indicates this is the issue.
Comment 12 Peter Vreman 2017-02-13 07:55:10 EST
The synced content selection is UI only. With the API this is not available.

The synced content shall be a persistent toggle that forces the use of the sync content for both API and UI.
Comment 14 Marek Hulan 2017-04-06 04:22:52 EDT
Steven, in your case I think BZ 1155704 helps. Just disable OS updating if you don't want anything to touch it.
Comment 15 Marek Hulan 2017-04-06 04:26:54 EDT
oops sorry, I see it was already suggested in comment 10

So my understanding is that this BZ now only tracks problem with using synced content through API.
Comment 16 Peter Vreman 2017-04-06 10:42:03 EDT
For a related case about broken template rendering i analysed the issue a bit more.

I checked the sources an also found a difference in handling between katello and foreman. katello uses a kickstart_repository_id and foreman the medium_id.

See below update from the UI that contians a kickstart_repository_id instead of meidum_id:

2017-03-16 11:47:45 [app] [I] Parameters: {"utf8"=>"✓", "authenticity_token"=>"=", "hostgroup"=>{"parent_id"=>"125", "name"=>"Test-6.8-ci", "lifecycle_environment_id"=>"3", "content_view_id"=>"408", "environment_id"=>"505", "content_source_id"=>"1", "puppet_ca_proxy_id"=>"1", "puppet_proxy_id"=>"1", "openscap_proxy_id"=>"", "puppetclass_ids"=>["", "28"], "domain_id"=>"", "subnet_id"=>"", "realm_id"=>"", "architecture_id"=>"1", "operatingsystem_id"=>"1", "kickstart_repository_id"=>"20696", "ptable_id"=>"61", "group_parameters_attributes"=>{"0"=>{"name"=>"ks_kernel_opts", "value"=>"[FILTERED]", "hidden_value"=>"[FILTERED]", "_destroy"=>"false", "id"=>"225"}, "1"=>{"name"=>"kt_activation_keys", "value"=>"[FILTERED]", "hidden_value"=>"[FILTERED]", "_destroy"=>"false", "id"=>"224"}}, "location_ids"=>["", "4"], "organization_ids"=>["", "3"], "id"=>"126"}, "media_selector"=>"synced_content", "kt_activation_keys"=>"hg-crash::AWS::IPS::Test-6.8-ci", "id"=>"126-crash-AWS-IPS-Test-6-8-ci"}

In my CI script i use API calls to explicitly set the medium_id.

Please look at the integration of katello / foreman where the katello is overriden the UI parts, without taking care of API and Hammer, to show the Sync Content.
Comment 17 Peter Vreman 2017-04-10 04:47:08 EDT
Also the parameter kickstart_repository in the puppet ENC is empty when the media is not correctly updated.

See below an example of a server that is upgraded from 6.8 to 6.9. The 'kickstart_repository:' field is empty:

[crash/LI] root@li-lc-1017:~# /etc/puppet/node.rb awstest.hag.hilti.com
---
classes:
- hiera_classes
parameters:
  puppetmaster: li-lc-1017.hag.hilti.com
  domainname: hag.hilti.com
  hostgroup: crash/AWS/IPS/Test-6.9-ci
  location: HAG
  organization: Hilti
  root_pw: ...
  puppet_ca: li-lc-1017.hag.hilti.com
  foreman_env: KT_Hilti_Hostgroup_hgp_crash_rhel_6_9_ci_412
  foreman_subnets: []
  foreman_interfaces:
  ...
  kt_activation_keys: hg-crash::AWS::IPS::Test-6.9-ci
  remote_execution_connect_by_ip: 'true'
  remote_execution_ssh_keys: ....
  remote_execution_ssh_user: awsrexec
  remote_execution_effective_user_method: sudo
  kt_env: Hostgroup
  kt_cv: hgp-crash_rhel-6_9-ci
  lifecycle_environment: Hostgroup
  content_view: hgp-crash_rhel-6_9-ci
  kickstart_repository:
environment: KT_Hilti_Hostgroup_hgp_crash_rhel_6_9_ci_412

I think this is another pointer that the Katello-Foreman integration regarding the installation medium is the root cause of the issues.
Comment 20 Peter Vreman 2017-05-02 06:38:03 EDT
See also https://bugzilla.redhat.com/show_bug.cgi?id=1446659 requests that the auto-updating of kickstart_repo_id as used by Sync Content (when medium_id is null) to be also done when the change is done through the API. Currently the auto-refreshing is only implemented in the WebUI.

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