Group by location/organization/host collection/lifecycle environment

[dLobatog]

It'd be great if this inventory could group hosts the same way it does with host groups, but with locations and organizations. If Katello is available as a Foreman plugin, grouping by host collection/lifecycle environment would be awesome too.

I should reference this inventory script in the foreman_ansible README and theforeman.org manual too.

@agx an aside, would you like to transfer this to @theforeman organization? We can provide you more visibility and packaging for this script over there. Of course you'd still have admin rights over the repo.

[agx]

I've added support for locations and organziations (can't test the atm but since the rest works fine I went ahead and pushed it). Note that this changes the hostgroup names from foreman_<hostgroupname) to foremanhostgroup which is more consistent if we want to add more in the future.

Not sure what to do about kotello though, I didnt' find anything in http://theforeman.org/api/1.10/apidoc/v2/hosts.html and don't have kotello around here. Do you have some example JSON or can provide a patch.

Moving to @theforeman is fine altough we might want to mention that this is rough atm and output might change. I also can't guarantee that I'll be able maintain this in the long run.

[agx]

Closing this fore now. Let's have the kotello parts in a separate issue.

[dLobatog]

Katello API bits are described here - http://www.katello.org/docs/2.4/api/index.html

The point for moving it to @theforeman is so that people have visibility over important foreman-related repos (I consider this to be important for Ansible) and precisely what you mentioned, having a team of people that could help you support and release this whenever needed :smile: , even if you can't maintain it in the future.

[agx]

On Mon, Feb 15, 2016 at 02:20:45AM -0800, Daniel Lobato García wrote:

Katello API bits are described here - http://www.katello.org/docs/2.4/api/index.html

Ahh...thanks a lot. So I will need to get around to setup kotello (or merge a pull request).

The point for moving it to @theforeman is so that people have visibility over important foreman-related repos (I consider this to be important for Ansible) and precisely what you mentioned, having a team of people that could help you support and release this whenever needed :smile: , even if you can't maintain it in the future.

Great, lets go ahead then - what needs to be done? I've also made a release to pypi yesterday. Cheers, -- Guido

[dLobatog]

@agx https://help.github.com/articles/transferring-a-repository/ is basically the procedure - after that procedure just ping me in this thread, and I'll add the repo to the Foreman Ansible Github team so you get admin access.

I've added you to the Foreman Ansible team (you should've got an email), this gives you admin access over theforeman/foreman_ansible , smart_proxy_ansible, and foreman_ansible_inventory when you transfer it, so exercise caution before merging stuff in these repos :smile: !

[agx]

On Tue, Feb 16, 2016 at 01:40:14AM -0800, Daniel Lobato García wrote:

@agx https://help.github.com/articles/transferring-a-repository/ is basically the procedure - after that procedure just ping me in this thread, and I'll add the repo to the Foreman Ansible Github team so you get admin access.

I've added you to the Foreman Ansible team (you should've got an email), this gives you admin access over theforeman/foreman_ansible , smart_proxy_ansible, and foreman_ansible_inventory when you transfer it, so exercise caution before merging stuff in these repos :smile: !

@dblatog transfering to theforman organization ends up with "you don't have admin rights for theforeman" Cheers, -- Guido

[domcleal]

@agx please try again, you should (temporarily) have permission to transfer in

[agx]

On Tue, Feb 16, 2016 at 05:10:26AM -0800, Dominic Cleal wrote:

@agx please try again, you should (temporarily) have permission to transfer in

That worked. Thanks! -- Guido

[rrubins]

Glad to see 'lifecycle_environment' and 'content_view' were added by using 'content_facet_attributes' (lines 273-277). But still looking for group by 'host_collection' being added by default. Any thoughts on that? Should 'host_collection' groups be created in some different way?

[dLobatog]

@rrubins I don't see host_collection in that API response, so yeah it would have to be created in some other way, likely through a 2nd API call (which makes it a poor candidate for a default attribute, as making 2 api calls will slow it down)

[agx]

Hi, On Tue, Oct 18, 2016 at 02:12:48PM -0700, Randy Rubins wrote:

Glad to see 'lifecycle_environment' and 'content_view' were added by using 'content_facet_attributes' (lines 273-277). But still looking for group by 'host_collection' being added by default. Any thoughts on that? Should 'host_collection' groups be created in some different way?

Looking at the API

http://www.katello.org/docs/2.2/api/apidoc.html

but looking at it seems we'd need to generate several groups based on host_collections

• All host_collections:

  GET /katello/api/host_collections

• By organization

  GET /katello/api/organizations/:organization_id/host_collections

…

The API lists more (some of them depreated, others by activation_key). I'm not a Kotello user so I can't tell which of them makes sense. But at least the "All host_collections" should be added.

[rrubins]

Thanks, guys! While I found a temporary workaround of using hammer cli and setting host params on each host to achieve exactly the ansible host grouping I needed, I feel like 'host_collections' might be a much cleaner and a preferred method by many Foreman/Satellite6 users who might not be using provisioning/host groups, but are after katello/content mgt functionality. Plus, I would think host_collections were created for exactly that reason - to be targets for 'collection actions' such as package manipulation or errata installation. So, a perfect fit for ansible groups. Thanks again for looking into it!