List enabled and available features

[arvind4501]

This implemets listing of available and enabled features, with old foreman-installer there was no good way to list all availabe features then doing foreman-installer --full-help which comes up with lot of puppet module args listed.

Here we have features.yml as source of truth for features listing. I did not like how ansible playbook outputs directly for listing features(it creates a lot of noise), i want it to be like systemctl .

Old Approch:-

so i have created a PR in obsah which allows bypassing ansible playbook execution and runs scripts directly(a hack to get nice output, maybe can be better).

This is how it will show the result

./foremanctl features

FEATURE                   STATE        BASE                 DESCRIPTION
katello                   enabled      foreman              Katello content management
remote_execution          enabled      foreman,proxy        Foreman Remote Execution support
azure_rm                  available    foreman              Azure Resource Manager integration
google                    available    foreman              Google Compute Engine integration

This PR lays out my initial thought of solving features listing.

It requires: PR

Updated Approch:-

So after the discussion around script logic, we have dropped it and created a ansible stdout callback plugin to make our output look as we expected.

Here is how the current command results

./foremanctl features

FEATURE                   STATE        DESCRIPTION
katello                   enabled      Content and Subscription Management plugin for Foreman
foreman-proxy             enabled      Foreman Proxy for Foreman
foreman                   enabled      Foreman Core
google                    available    Google Compute Engine plugin for Foreman
azure_rm                  available    Azure Resource Manager plugin for Foreman
hammer                    available    Hammer plugin for Foreman

./foremanctl features --list-enabled

FEATURE                   STATE        DESCRIPTION
katello                   enabled      Content and Subscription Management plugin for Foreman
foreman-proxy             enabled      Foreman Proxy for Foreman
foreman                   enabled      Foreman Core

[arvind4501]

Currently This Does not list the BASE features which are hammer, foreman-proxy, foreman

[ehelms]

Is there any to make use of callback_result_format just for this command to format the results the way you'd want to the user? Just a curious question, I can see how this might be useful for some additional things in the future.

In the results, what does the BASE column represent?

[ehelms]

Colors can sometimes be a pain, this would enforce colors even if Ansible is configured with no colors. I think we either should skip colors or be consistent with Ansible's configuration.

[arvind4501]

Is there any to make use of callback_result_format just for this command to format the results the way you'd want to the user? Just a curious question, I can see how this might be useful for some additional things in the future.

I was not much aware about available callback plugins, but now that you mentioned it, i see that there are builtin plugins which i tried and they does not give our expected output format(if i did not missed anything), we might need to create a custom plugin for that but not sure if we should?

My thought here was that what if i need a custom script to run at some point from foremanctl and i did not find a way to do so, and that made me do theforeman/obsah#105,

In the results, what does the BASE column represent?

This was taken from https://github.com/theforeman/foremanctl/blob/master/src/filter_plugins/foremanctl.py#L7 , where we define BASE_FEATURES(which can have plugins on top of that). So here BASE represent that a feature is a plugin for which BASE_FEATURE. i was expecting this question while deciding what should be the column name and ended up using BASE which i think is confusing and should be better

[arvind4501]

Colors can sometimes be a pain, this would enforce colors even if Ansible is configured with no colors. I think we either should skip colors or be consistent with Ansible's configuration.

I agree, colors should be consistent, thanks

[ehelms]

In the results, what does the BASE column represent?

This was taken from https://github.com/theforeman/foremanctl/blob/master/src/filter_plugins/foremanctl.py#L7 , where we define BASE_FEATURES(which can have plugins on top of that). So here BASE represent that a feature is a plugin for which BASE_FEATURE. i was expecting this question while deciding what should be the column name and ended up using BASE which i think is confusing and should be better

I am not sure this column of information is useful to the user, and we can omit it in the output.

[stejskalleos]

🍏 LGTM
Tested together with the theforeman/obsah#105

Before installation:

./foremanctl features

FEATURE                   STATE        DESCRIPTION
katello                   enabled      Content and Subscription Management plugin for Foreman
azure_rm                  available    Azure Resource Manager plugin for Foreman
google                    available    Google Compute Engine plugin for Foreman

After installation

./foremanctl deploy  --add-feature azure_rm --add-feature google
./foremanctl features

FEATURE                   STATE        DESCRIPTION
azure_rm                  enabled      Azure Resource Manager plugin for Foreman
google                    enabled      Google Compute Engine plugin for Foreman
katello                   enabled      Content and Subscription Management plugin for Foreman

3 features listed (3 enabled, 0 available).

[stejskalleos]

@evgeni @ehelms if you don't have any other comments, feel free to merge

[evgeni]

I like the output a lot, but I totally dislike it's a standalone script 🙈

[ehelms]

I'd be interested in seeing a contrasting implementation of this that follow the paradigms of the current design. That is, using Ansible to collect and output the list of features. Perhaps just something simple that uses the debug module to output the results in the structure you've presented above. I feel like this is needed before we accept a deviation from our baseline design.

[arvind4501]

I like the output a lot, but I totally dislike it's a standalone script 🙈

yes @evgeni, i just wanted that there is a way to run scripts via foremanctl rather than playbook, if there are some other use cases for it.
but then also i would love to know if there is some better way which i can implement. are you thinking about custom callback plugins, sure i can try that but not sure how they fit in our design

[arvind4501]

I'd be interested in seeing a contrasting implementation of this that follow the paradigms of the current design. That is, using Ansible to collect and output the list of features. Perhaps just something simple that uses the debug module to output the results in the structure you've presented above. I feel like this is needed before we accept a deviation from our baseline design.

I can see that there is a way for callback plugins to hook into ansible's lifecycle events and change default output behavior, so maybe we are going towards callback plugins(stdout callback plugins).
Also looking at filter_plugins i see this a similar to our existing design

[arvind4501]

With 0ee3f43 and theforeman/obsah#107 to set stdout callback for a playbook) , we have now moved from running direct script to run ansible stdout callback plugin to change how the output of a command/playbook is displayed.

This is more cleaner and does not by pass running playbook, it hooks into the ansible output event and customize the display.

[ehelms]

In theory this shouldn't need to be locked to quadlet, but we can leave it for now as that's a bigger question we need to answer across multiple playbooks.

[ehelms]

@arvind4501 Thanks for considering this alternative, and @evgeni for the assistance! Looks great!

Should we revert theforeman/obsah#105 ?

[ShimShtein]

Maybe it would be better to use subprocess.run or subprocess.popen?
This way the STDOUT of the test will remain clean and we will have the full process output to examine.

[arvind4501]

Yes, we should revert theforeman/obsah#105 since we moved away from script approch, here is the revert PR theforeman/obsah#110

[evgeni]

@arvind4501 this needs a rebase after the merge of #309

[ShimShtein]

LGTM, not tested though

[arvind4501]

/packit build

[Gauravtalreja1]

ACK, Tested with theforeman/obsah#111 🍏
It works correctly to list enabled/available features along with base features, and new --list-enabled option also works correctly now to list just enabled features.

# foremanctl features
FEATURE                   STATE        DESCRIPTION
foreman                   enabled      Base Foreman Server
foreman-proxy             enabled      Base Foreman Proxy
hammer                    enabled      Foreman CLI
katello                   enabled      Content and Subscription Management plugin for Foreman
google                    available    Google Compute Engine plugin for Foreman
azure-rm                  available    Azure Resource Manager plugin for Foreman
remote-execution          available    Remote Execution plugin for Foreman

# foremanctl features --list-enabled
FEATURE                   STATE        DESCRIPTION
foreman                   enabled      Base Foreman Server
foreman-proxy             enabled      Base Foreman Proxy
hammer                    enabled      Foreman CLI
katello                   enabled      Content and Subscription Management plugin for Foreman