Bug 1733241

This not only concerns Locations but also Host Groups.
This bug renders the whole concept of Parent-Child inheritance useless.
Please give this some priority as this creates a lot of extra effort if you have a multi-tenancy setup that uses Parent-Child inheritance a lot.

I discussed this with Martin and we came to a following conclusion. The web UI displays both inherited and directly assigned resources. When the resource is inherited, it's disabled and on hover, the information is displayed, see the attached screenshot. In the API though, this is more complicated. Today, API (and hence also CLI) only lists directly assigned objects. This is intentional. API can't add "hover bubble" so that user could simply distinguish. But this information is important. Imagine there's location L, which has a sub-location S. Imagine there are 3 domains in your system, a,b,c. Listing all domain from location S returns all three a,b,c. So it would naturally mean, to remove b, one would try to update location S with "--domains=a --domains=c". But what if the b is assigned through inheritance and in fact is ditectly only assigned to L.

That's why API and hammer behaves this way and I believe is valid. With more API requests, one can get the list of all associated objects. But I also agree, it may be useful to see all inherited resources on single query.

Therefore we agree, we should consider this an RFE that would add new parameter to API, that would indicated whether we should or should not include inherited resources. In hammer, there would be new command argument "--include-inherited=yes". To keep backwards compatibility, the parameter would default to no. The very same argument applies to hostgroup. I'm switching this to RFE now. Hopefully it makes more sense now.

Created attachment 1612514 [details]
location ui with inherited resources

Hi Marek, Martin,

Let me first explain how this bug request got raised, because the bug might not entirely be soly related to Hammer.
The whole idea of inheritance / parent-child relation is that you can registered shared information in the parent object and this information will be shared by all childs.
So, within Forman I create a Parent Hostgroup, specify my custom templates there (Provisioning, iPXE, PXE, etc) and create child templates that inherit these templates.
Be aware that this setup has been created within the GUI, not with hammer cli.

If I the create a host object with hammer-cli and including the child hostgroup in the 'hammer host create --hostgroup <child> --build true', the I expect the templates assigned to the Parent Hostgroup
also be registered within the host object. Otherwise the whole concept of Parent-Child inheritence is useless.


By building this setup we encoutered the problem that the iPXE config did not got generated anymore. Looking in the GUI, thus Forman, it all got displayed correctly.
Then turning to hammer cli and querying the child we noticed the missing information (e.g. all inherited properties including the templates were missing, which should be present based on the Parent-Child relation.

I agree that the bugzilla problem description as being created by Avijit might only describe half of the problem.

Thanks for more information Marco, so the buggy behavior here is rather the fact, that host creation via CLI does not respect the inheritance from the parent hostgroup, correct? And if you do the same from the UI, it works just fine. If that's the case, my guess is, it's thanks to host form JS, that loads all inherited values and after the form is submit, it sends all values in one request. This would indeed be a bug, probably not in hammer itself but in our provisioning API layer.

If you could confirm my summary above (that I understood it correctly) I would create a separate BZ for tracking it, this BZ would be used to RFE described in comment 10.

Marek,

I just performed some additional testing:
- Created a new Child Hostgroup from the GUI
  (In the GUI it has filled all the parent properties into the Child Hostgroup greyed out, like mentioned above).
   This is 'as expected'. When I now use hammer-cli to retrieve details of this same child hostgroup, it does NOT show the parent properties although they are in place, because after the child hostgroup has been created I created a new host via the GUI as well and the correct iPXE config did get created. So by only selecting "Create new" in the GUI and configuring name, IP, MAC, Location and newly created Child Hostgroup, this new host entered build-mode correctly and the /var/lib/tftpboot/pxelinux.cfg/<MAC>.ipxe file got created.

So, actually within the foreman DB te parent properties are indeed propegated to the child object or the webpage gathers the parent properties itself, as you suggest.

So, it all depends on how the overal architecture of Parent-Child inheritence was designed, to determine where the bugs are.
Because if I create a parent-child relation within the GUI and the GUI is showing me in the details of the Child all the inherited parent properties, I expect (or may even demand) that when I used hammer cli to retrieve the properties of the Child-Object, that I also see the inherited parent properties. Because the GUI is also displaying these inherited properties.
Evenmore, these inherited properties are unconditionally bound to the child, because in the GUI they are even greyed out, so you cannot change or delete them from within the child object.

So, I'm not only doubting the 'hammer hostgroup create' command, but I also consider the command 'hammer hostgroup info' for a child hostgroup also be incorrect, because it does not reflect the inherited properties.

I consider the hammer architect and the foreman architect to be on different pages regarding the way to implement/handle inheritence.
Personally I prefer the GUI implementation of inheritence the most convenient way: the child fully includes the inherited properties.
Only marking a child as a decendant from the parent and to be able to retrieve the inherited properties from the parent by performing an additional call to the parent is not a correct implementation of parent-child inheritence, in my opinion.

Thanks for more information. Your observation with hostgroup inheritance is consistent with what I described for locations. The API/Hammer displays only directly defined attributes, the inheritance should work only when you use the hostgroup for host creation. The new parameter "to display inherited values" described in comment 10 should be added here too. The GUI has the liberty of showing direct value, inherited value (greyed out) or no value - all at the same time. In API we can only tell the value or no value, we can't mark the value is returned thanks to inheritance.

I understand your argument to have API behaving consistently with UI, hence we want to introduce "--include-inherited=yes" parameter to make this possible. However we want to keep API backwards compatible so it would default to no. This use case is still important, for the very same reason as with locations. Imagine you want to drop "puppet environment" attribute from child hostgroup, you need to see whether it's assigned directly on child or it's inherited from parent.

Now what I'd want to double check, how does it behave when you create a parent and child hostgroup according to your needs (e.g. in GUI) and then try to provision host using child hostgroup through Hammer? From you description:

> If I the create a host object with hammer-cli and including the child hostgroup in the 'hammer host create --hostgroup <child> --build true', the I expect the templates assigned to the  Parent Hostgroup
> also be registered within the host object. Otherwise the whole concept of Parent-Child inheritence is useless.

I understand this is the bug. The inheritance must work here and everything needs to be propagated from parent host group to the newly created host object. If that fails in your case, I'd open a separate BZ for this for better tracking. While it's related to your findings about how we display data in hammer, this would be something we must fix and what should be the default behavior for everyone.

Ohh boy, I love software updates (during support cases ;-)...
I tried to reproduce the issue via hammer-cli, so created inheritance relationship via GUI and create host via hammer-cli and ... it works (again)!
When I opened the support case at RedHat Support, we were running Satellite 6.5.1.1 and last Thursday my colleague upgraded our server to Satellite 6.5.2.1... Apparently it got fixed in the upgrade.

So, the primary bug is fixed.
But I agree that the optional "--include-inherited=yes" is needed to let hammer-cli behave consistent with UI / internal logic.

Thanks for your patience!

Thanks for letting us know! I'm keeping this open to track the "--include-inherited=yes".

*** Bug 1777571 has been marked as a duplicate of this bug. ***

Created redmine issue https://projects.theforeman.org/issues/28868 from this bug

Upstream bug assigned to mshira

Upstream bug assigned to mshira

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

Verified on Satellite 6.8 snap 2, inherited subnet is displayed in hammer info for child location

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 (Important: Satellite 6.8 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-2020:4366