Inconsistency between Ansible Roles and Puppet Classes on Host edit

Problem:
There are inconsistencies between how Ansible Roles and Puppet Classes are presented in the Host Edit pages in Foreman 1.24 and below (haven’t assessed Foreman 2.0 yet; waiting on Katello 3.15 GA). I reviewed the 2.0 release notes, and didn’t see anything obvious about this as a change though. Host group edit pages are similarly inconsistent.

The inconsistencies are:

  • Available and assigned are reversed between Puppet Classes and Ansible Roles, and wording is not consistent (but that could be more due to Puppet using includes as it’s terminology) ; Puppet has Included on the Left, and available on the right. Ansible has Assigned on the right, and available on the left.
  • The fonts for the titles are not visually consistent.
  • The layouts are not consistent; Puppet has the + dropdowns, while Ansible has the tables.

Expected outcome:
For operator workflow, the two capabilities should be visually consistent, so there is no ambiguity as to what is assigned/included vs what has not been.

Foreman and Proxy versions:
Foreman 1.24.2

Distribution and version:
CentOS 7.7
Other relevant data:
Visual examples.


Hope that helps!

/Mike

This is a good set of RFEs!

The ansible assignment is the new widget that is planned to be further improved by @lstejska. Ideally the Puppet page should be revisited, perhaps something that could be done as part of The Road to Making Puppet Optional, cc @ezr-ondrej.

I think that swapping the order on Puppet tab is easy fix that could be done right away. Just swapping divs in app/views/puppetclasses/_class_selection.html.erb should do. Would you be interested in making such contribution?

Marek,

Thanks for the compliment! I’ll take a look at it and see what it takes to do it, and if it’s in my skill sets. One thing first though; I don’t use the chef plugin, but I just looked at the manual for it, and the only image I can see also has a different means of adding/ordering chef classes. It has it’s “assigned” run list on the left (as it doesn’t seem to have an “available” side).


So, each of the three supported configuration management technologies have three different means to assign and view them. Some may be due to how the
Config Management tool behaves, but some are also design choices in the Foreman UI. So, perhaps this is an opportunity to apply consistency in the design choices for all of them?

For your consideration,

/Mike

Thanks @Mkbrown, I do believe you’re completely right here. It’s on my long term agenda to create a unified component for assigning roles and potentionaly variables as well.
I’ll try to come up with RFE soon, but I expect to come not sooner than few releases as there are some higher priorities for now, so if you propose simple unification of sides in the meantime, you’re welcome to!

I’ll keep you posted here, once I come up with the RFE :slight_smile:

Yes, however for Chef specifically, this works differently on the backend side. We don’t import existing roles/recipes to Foreman DB, because Chef can’t use Foreman as an ENC. We mimic the funcationality, however we manipulate the runlist on Chef server and keep only the local cache of it in our DB. Perhaps we could sync roles and recipes to Foreman DB for a given environment too, then we could use the same visualization. However foreman_chef is only being maintained, no new features are being added atm.