Problem:
In the web interface I can view the hosts that are associated (via registration) with an activation key by selecting “Associations → Content Hosts”. I’ve been unable to find a way to obtain the list of associated hosts in the REST API given the value of the activation key. How can this be done?
Expected outcome:
JSON output from a REST API query that shows the content hosts associated with a given activation key.
Foreman and Proxy versions:
foreman-3.12.0.7-1.el8sat.noarch
foreman-proxy-3.12.0-1.el8sat.noarch
Foreman and Proxy plugin versions:
?
Distribution and version:
Red Hat Enterprise Linux 8.10 (Ootpa)
Red Hat Satellite (build: 6.16.4)
Other relevant data:
Hi,
you can get that via the hosts API endpoint with a search parameter like this:
https://yourforeman.example.com/api/hosts?organization=yourorg&search=activation_key=your_ak_name
Regards
2 Likes
Okay that works, thank you! I find it strange because I expected to see an activation_keys entry when I used the /api/hosts endpoint to view a particular host, however, I was querying the host with /api/hosts?search=name=HOSTNAME (because I don’t have the host’s :id available at this point), which returns a wildly reduced set of information as compared to /api/hosts/:id, and there are no activation_keys entries returned in the search= output, so I thought I was barking up the wrong tree by using the /api/hosts endpoint. Why the difference? I find this confusing.
I cannot tell you why /api/hosts only gives a subset of every hosts attributes, though in my experience this is true for several object types in the Foreman API.
Though, I can give you a few general tips for working with the API:
- You can find the API Docs for your Foreman version and all Plugins you have installed at
https://yourforeman/apidoc. Most endpoints that support searching will list the available search fields there.
- Most API endpoints (including
/api/hosts) will accept names in the ID field, so you can query /api/hosts/<fqdn>. directly. I believe it’s mostly Katello objects where this is not working properly, usually because those are scoped on a per-org basis by default and do not require to have globally unique names.
Aha! Now that I would not have expected. It works great and avoids the need for an intermediate lookup of the host ID. Thanks!
1 Like
It’s usually a consequence of the way the data is stored. In this case of host <> AK, it’s a many-to-many relationship (e.g. a host can have been registered with multiple AKs, and an activation key can be used to register many hosts.) So this information is not stored directly on the hosts or activation_keys table, but rather in a third “join” table. The associations you see when you search for host-AK associations, therefore, are the result of SQL queries and joins, and not just giving you the raw values from one table or another.
1 Like
