Bug 1267521 - Medium is not updated after OS is changed on client
Summary: Medium is not updated after OS is changed on client
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Content Management
Version: 6.1.2
Hardware: All
OS: Linux
urgent
urgent vote
Target Milestone: 6.4.0
Assignee: Stephen Benjamin
QA Contact: Sanket Jagtap
URL:
Whiteboard:
Depends On: 1155704 1261667 1426373
Blocks: 1122832 1296845
TreeView+ depends on / blocked
 
Reported: 2015-09-30 09:26 UTC by Peter Vreman
Modified: 2020-02-14 17:34 UTC (History)
19 users (show)

Fixed In Version: foreman-1.18.0.21-1,tfm-rubygem-katello-3.7.0.25-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-16 19:29:53 UTC
Target Upstream Version:


Attachments (Terms of Use)
showing selection of synced content (49.88 KB, image/png)
2017-02-07 16:02 UTC, Justin Sherrill
no flags Details


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 24376 Normal Closed Installation media and kickstart repository ID are not exclusive 2020-06-02 23:18:22 UTC
Foreman Issue Tracker 24388 Normal Closed When facts update operating system, medium can become invalid 2020-06-02 23:18:22 UTC
Red Hat Bugzilla 1382775 'medium' 'CLOSED' 'stop creating installation media for synced repos' 2019-11-25 17:12:10 UTC
Red Hat Bugzilla 1439978 'medium' 'CLOSED' '[RFE] Installation medium of host provisioned from Satellite should update when the base OS in updated.' 2019-11-25 17:12:10 UTC
Red Hat Bugzilla 1446659 None None None 2019-11-25 17:12:10 UTC
Red Hat Knowledge Base (Article) 2097741 None None None 2018-04-22 18:18:51 UTC

Internal Links: 1382775 1439978

Description Peter Vreman 2015-09-30 09:26:53 UTC
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 15:28:12 UTC
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 10:14:55 UTC
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 23:13:24 UTC
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 16:02:38 UTC
Created attachment 1248446 [details]
showing selection of synced content

Comment 10 Tomer Brisker 2017-02-09 13:33:33 UTC
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 08:40:28 UTC
Clearing needinfo as comment on the other bug indicates this is the issue.

Comment 12 Peter Vreman 2017-02-13 12:55:10 UTC
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 08:22:52 UTC
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 08:26:54 UTC
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 14:42:03 UTC
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 08:47:08 UTC
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 10:38:03 UTC
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.

Comment 27 Peter Vreman 2018-05-28 11:04:38 UTC
Another failing scenario the has the same root cause:

With a fresh installed 6.3.1:
- Register the not existing Host through subscription-manager
- Use the API to set for the new created Hosts Managed=true and Build=true
-> Failure that medium cannot be blank

Comment 31 Stephen Benjamin 2018-07-03 20:25:43 UTC
Kickstart repository ID is available in both hammer CLI and the API, at least on 6.3.2:

# hammer -u admin -p changeme host update --help | grep kickstart
 --kickstart-repository-id KICKSTART_REPOSITORY_ID             Repository Id associated with the kickstart repo used for provisioning


> With a fresh installed 6.3.1:
> - Register the not existing Host through subscription-manager
> - Use the API to set for the new created Hosts Managed=true and Build=true
> -> Failure that medium cannot be blank

Can you clarify what you expect here? If you convert a host to managed, you should need to set some provisioning related options.  Setting kickstart_repository_id should meet the requirement for a Medium.  I can have a look at improving the error message. Or are you looking for a different fix here?  If the content view has a kickstart repository should we set that automatically (if we can guess based on the host's OS for example)?

Comment 32 Stephen Benjamin 2018-07-03 20:37:32 UTC
As for the general problem, if you used installation media in the past, the only option is to move to synced content as part of the host's content view.  

Unfortunately, previous versions of Satellite let you use any installation medium from any content view, so we can't really update the information automatically in the upgrade process.

Comment 33 Peter Vreman 2018-07-09 08:56:19 UTC
That i have to use the API to set the kickstart_repo_id is a complex workaround. Because it is at least 2 API calls needed: 1 to get the repo_id and then a second one to set it on the Host. To get the full complexity of the algorithms the user has currently to build you multiple this by the number of differetn ConentViews and number of Hosts.

My expectation is really simple: When i assign a ContentView (through either subscription-manager or API or UI) then i expect that the Host directly consumes everything from the assigned ContentView unless explicitly overriden.
In Sat6.0-6.3 a ContentView can contain: Kickstart, RPMs and Puppet modules.
I expect that all 3 content types are implicitly made available to the host.

I understand the need to be compabile with flexibility Foreman provides to mix-and-match everything you want. This can be handled with an opt-in/opt-out boolean for each of the ContentView provides fields. Note that the current 'Synced Content' for the kicktart_repo_id is not a clean solution requiring medium=null. Because null means 'undefined', but it is not really 'undefined' it is instead 'delegated' to katello with it is kickstart_repo_id

Comment 34 Stephen Benjamin 2018-07-24 15:06:38 UTC
Upstream 24376 is only one part of the fix. More upstream work coming.

Comment 35 pm-sat@redhat.com 2018-07-24 16:03:27 UTC
Upstream bug assigned to stbenjam@redhat.com

Comment 36 pm-sat@redhat.com 2018-07-24 16:03:34 UTC
Upstream bug assigned to stbenjam@redhat.com

Comment 37 pm-sat@redhat.com 2018-08-06 18:14:45 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24388 has been resolved.

Comment 43 Sanket Jagtap 2018-09-12 15:15:28 UTC
Build : Satellite 6.4.0 

Operating system:      
    Architecture:     x86_64
    Operating System: CentOS 7.5
    Medium:           CentOS mirror
    Partition Table:  Kickstart default
    PXE Loader:       PXELinux BIOS
Puppetclasses:         
    access_insights_client
    foreman_scap_client
Parameters:            
    kt_activation_keys => ak-rhel-7
Locations:             
    Default Location
Organizations:         
    Default Organization
OpenSCAP Proxy:        
Content View:          
    ID:   2
    Name: RHEL 7 CV


I was able to edit the hostgroups Rhel7 OS Synced content to Centos 7.5 and medium successfully

Comment 44 Bryan Kearney 2018-10-16 19:29:53 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/RHSA-2018:2927


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