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:
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?
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.
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.
Created attachment 1248446 [details] showing selection of synced content
Steven - would the fix for BZ1155704 which will allow preventing OS updates based on puppet facts be sufficient for your use case?
Clearing needinfo as comment on the other bug indicates this is the issue.
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.
Steven, in your case I think BZ 1155704 helps. Just disable OS updating if you don't want anything to touch it.
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.
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.
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.
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.
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
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)?
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.
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
Upstream 24376 is only one part of the fix. More upstream work coming.
Upstream bug assigned to stbenjam
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24388 has been resolved.
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
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