I am working on a case 02328458, where Customer would like to have this problem fixed ASAP. 

The reason behind why the build their host group in such way(without any Lifecycle Env\CV) is because they just use them for populating puppet related information.

This is what the observation shared from Customer's end.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The behavior is a problem because what if I have a hostgroup that is shared between RHEL6 and RHEL7 hosts.  I have several hostgroups in my environment that are both RHEL6 and RHEL7.  I do not find it a valid solution that different operating systems should have different hostgroups.  I have several hostgroups in my environment that have both RHEL6 and RHEL7 hosts and changing that would cause some serious problems for us since we use hostgroups for Puppet.

If you look at how the data for a host is stored in the database or in Rails the values during "create" are copied from the hostgroup and saved for that host.  So if a hostgroup has environment 'test' then the default value for a host would be 'test' but it can be changed and regardless of what value is selected during creation that environment ID would get saved for that host and would always be associated with that host.  When you go to view the host the value you see is the value saved for the host, not the hostgroup.

I looked at the schema and the code.  The katello_content_facets table associates hosts so kickstart repositories.  This means when viewing a host the value shown should be the value for that host, not the hostgroup.  The value is saved for the host when a host is created or updated and should behave by showing you that value.

The fact the value you see is influenced by the hostgroup's value is NOT the behavior one gets for any other host attribute except this one.  Because of this issue the application suddenly limits hostgroups to a specific operating system which again is a huge limiting factor.  I think all 3 scenarios are bugs and the fix for all 3 is likely the same code since the rails view helper that determines what you see if used by all 3 scenarios.

I have been using Foreman for years, since before Satellite 6.  Hostgroups are NOT operating system specific and never have been.  The fact you can set a default OS is just a helper when creating hosts.  The fact the OS and other values are saved specific to a host regardless of hostgroup shows that the value of hostgroup does not influence a host after creation.  The only way hostgroups have influenced hosts after creation is via inheritance of things like parameters and puppet classes.

So look at katello_content_facets table, that's where the synced content ID is stored.

The view being used to set Synced Content: https://github.com/Katello/katello/blob/master/app/views/overrides/activation_keys/_host_synced_content_select.html.erb

The helpers are in /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.46/app/helpers/katello/hosts_and_hostgroups_helper.r or https://github.com/Katello/katello/blob/master/app/helpers/katello/hosts_and_hostgroups_helper.rb

I'm guessing the logic in "kickstart_repository_options" is flawed because everywhere else the code is looking at the correct kickstart_repository_id of the host but ends up using the value of the hostgroup.

The correct logic should be to find kickstart repositories available to the HOST based on that host's content view.  What's the point in setting a content view on a host if it's just going to use the hostgroup's value?  The value is saved to the host so that's what the view in Rails is supposed to show.  It's very poor design to save values for a host then host hostgroup values instead.  This is a bug.

It looks like the intended behavior is that kickstart_repository_options helper function uses the host object if viewing a host page.  I am still unsure why the results are for the hostgroup but it looks pretty obvious the intended behavior from code is NOT what's happening.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hello All,


I have tested the reported concern on satellite 6.5 as well and it remains the same.

Steps:
1. Hostgroup created without any content details selected i.e only information present is about puppet environments\puppet master\ansible roles etc.
2. Host created and manually selected content source\LCE\CV\OS details.
3. Built the host.


Test 1:
1. Edit the host which is built and found that OS is selected but synced media is blank and grayed out and partition table is blank.
2. The surprising fact is, even with the condition on Step 4, If I click on "Build" and reboot the host, it did build the host properly with the correct operating system.


Test 2:
1. Edit the same host and just click on Ok to submit it Or Change something in the host e.g. ansible roles\puppet environments etc and submit the host.
2. Now click on build again, and that will be getting failed and will complain about partition template.
3. If we now again edit the host and check the OS Architecture is selected but synced media is grayed out and Operating System and Partition table are blank.

Above won't be happening if the host group have the content details\Operating systems properly selected but I expect to have the manual changes to be retained even if the host group doesn't have the information about OS.

I believe and this is a point of concern and would like to know an ETA of addressing the same.



Regards,

Sayan

I am working the escalation of the BZ case with the customer, I asked him for an update outline of the issue, because he feels the issues has changed in the months it has been happening. We are asking for some feedback on the investigation based on this new outline of the situation. 


This is his current description of the overall issue. 

The initial issue was trying to change from static Media/Kickstart repo set at hostgroup to using Content view Media on Host and this wasn't possible. There were work arounds but the issue is much easier to describe this way:

1) Crease Hostgroup: base
2) Create Hostgroup: base/test
* Set Lifecycle Environment - production
* Set Content View - OSC_RHE7 (composite view used by all RHEL7 hosts)
* Set Content Source - satellite-test.infra.osc.edu
* Operating System:
** Set Architecture - x86_64
** Set Operating System - RHEL 7.7
** Set Media Selection - Synced Content
** Set Synced Content - RHEL 7.7 Kickstart
3) Create Host
* Set Hostgroup - base/test
* Change Content View - OSC_RHEL8 (composite view used by all RHEL 8 hosts)
* Operating System:
** Change Operating System to RHEL 8.0
** Synced Content to RHEL8.0 Kickstart
* Save Host
4) Edit Host
* ISSUE: Media Selection moved to "All Media" and unable to put back onto "Synced Content" which was the value used in Step #3. Field is greyed out.
* ISSUE: Media has no option selected despite having selected RHEL 8.0 Kickstart in Step #3 and field is greyed out and can't be changed

In step #4 the issues are similar to what I had before except this involves only Synced Content where the hostgroup has different content settings than the host. The issues have a work around of changing the OS to 7.7 then back to 8.0 and I can re-apply the settings given in Step #3 but that should be entirely unnecessary in order to edit a host.

The issue I encountered today I think manifested itself from same bug but in a different way. What happened was I selected a hostgroup and was unable to save the host using different OS version and Media than the host group but I'm now unable to figure out what about the hostgroup made this happen as my work around in that case was to remove all OS settings from the host group.

Now that RHEL 8 is out I will have many hostgroups with RHEL 7 and RHEL 8 hosts as I move systems to RHEL 8. I  think the only way to continue using my existing host groups is to change them to have new defaults for OS settings which shouldn't be necessary and will cause problems if I go to rebuild RHEL 7 hosts. Using different hostgroups isn't an option as I use the Hostgroup value in Puppet to define what a host should be configured to do.

We have looked at he bug and it is valid, but we have not scheduled it for a release.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in approximately a month. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

There will be upcoming work to revamp the host edit/details pages and will keep this bug in consideration during the redesign of these pages. Will leave this open.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in one month's time. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Connecting redmine issue https://projects.theforeman.org/issues/33581 from this bug

Connecting redmine issue https://projects.theforeman.org/issues/33591 from this bug

Deleted the original redmine issue. The fix for Scenario 2 will be tracked by a different issue #33591.

Upstream bug assigned to iballou

Upstream bug assigned to iballou

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/33591 has been resolved.

Hello

this bug is now resolved.

Be aware that if you omit some value and the host configuration fails to save, you must check the Host tab and OS tab settings again as they will be reset to default values.

Thank you

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 (Moderate: Satellite 6.11 Release), 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-2022:5498