Bug 1733241 - hammer does not inherit parent location information
Summary: hammer does not inherit parent location information
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Organizations and Locations
Version: 6.5.0
Hardware: All
OS: All
medium
medium with 1 vote vote
Target Milestone: Unspecified
Assignee: Shira Maximov
QA Contact: Peter Ondrejka
URL:
Whiteboard:
: 1777571 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-25 13:53 UTC by Avijit Roy
Modified: 2020-02-22 04:36 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)
location ui with inherited resources (31.42 KB, image/png)
2019-09-06 18:24 UTC, Marek Hulan
no flags Details


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 28868 Normal Ready For Testing hammer does not inherit parent location information 2020-02-21 01:33:44 UTC

Description Avijit Roy 2019-07-25 13:53:03 UTC
Description of problem:

subnets and the templates that are configured in the parent location should also be visible in "hammer location info --name child_location". Unlike it shows correctly in GUI. 


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

6.5

How reproducible:

100%

Steps to Reproduce:
1. Create a parent and child location on GUI. 
2. Create a Subnet under parent and another subnet under child location. 
3. Now get the information of location through hammer.

# hammer location info --show-hidden-parameters yes --name child_location   ---> It will show subnet which is associated only with child_location. 

# hammer location info --show-hidden-parameters yes --name parent_location   ---> It will show subnet which is associated only with parent_location. 

Actual results:

# hammer location info --show-hidden-parameters yes --name child_location   ---> It will show subnet which is associated only with child_location. 

# hammer location info --show-hidden-parameters yes --name parent_location   ---> It will show subnet which is associated only with parent_location. 


Expected results:

Manage Locations >> Parent_Location >> Subnets  ---> It will show both subnets under parent & child location. 

Manage Locations >> Child_Location >> Subnets  ---> It will show both subnets under parent & child location. As inherited from parent.

The above behavior should also be reflected by hammer/API

Additional info:

The same behavior has been observed for provisioning template as well.

Comment 6 Marco Verschuur 2019-08-29 13:52:54 UTC
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.

Comment 10 Marek Hulan 2019-09-06 18:24:07 UTC
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.

Comment 11 Marek Hulan 2019-09-06 18:24:38 UTC
Created attachment 1612514 [details]
location ui with inherited resources

Comment 12 Marco Verschuur 2019-09-09 11:34:32 UTC
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.

Comment 13 Marek Hulan 2019-09-09 13:00:06 UTC
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.

Comment 14 Marco Verschuur 2019-09-09 20:47:47 UTC
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.

Comment 15 Marek Hulan 2019-09-10 11:49:55 UTC
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.

Comment 16 Marco Verschuur 2019-09-10 12:50:36 UTC
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!

Comment 17 Marek Hulan 2019-09-10 13:26:51 UTC
Thanks for letting us know! I'm keeping this open to track the "--include-inherited=yes".

Comment 18 Oleh Fedorenko 2019-11-29 17:13:26 UTC
*** Bug 1777571 has been marked as a duplicate of this bug. ***

Comment 19 Shira Maximov 2020-01-28 09:18:39 UTC
Created redmine issue https://projects.theforeman.org/issues/28868 from this bug

Comment 20 Bryan Kearney 2020-02-11 15:03:45 UTC
Upstream bug assigned to mshira@redhat.com

Comment 21 Bryan Kearney 2020-02-11 15:03:53 UTC
Upstream bug assigned to mshira@redhat.com


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