Hello devs,
I was contacted by @Bernhard_Suttner about the upcoming foreman_ansible plugin plans. He and his team would like to be more involved in the plugin development, so we discussed how to best share our thoughts about what we should improve in short and long term future.
We agreed on doing a hangout where we’ll do a brainstorming and agree on what can be worked on right away and who will work on that. We’ll be happy to have more developers involved if you’re willing to help with the coding 
We’ll meet on Monday 16th, 10am CEST. If you want to join, please come to the #theforeman-dev IRC channel where I’ll share the hangout link. Also please let me know if the time does not work for you. We plan to create redmine issues out of tasks we identify, so you can watch the progress there as well.
Thanks
–
Marek
5 Likes
Thank you Marek for this initiative. Myself and some colleagues like @x9c4 from ATIX will participate.
Have a great weekend!
Today we had this brainstorming. From what I understood, there are 2 critical features for ATIX:
1 - Better handling of parameters, possibly as Smart Class Parameters or Smart Variables
2 - Distribution of roles (Pulp?)
https://docs.google.com/document/d/1hIrzD8RSCJKcDkqoNTDEAfLzyheNM-TOSs4566zDl3g/edit?usp=sharing contains some of the things we talked about.
Next steps - link issues in Redmine with the problems described in the doc.
1 Like
Hi,
in the last few weeks we analyzed how to configure ansible roles in foreman. Our perspective is, that we need something like puppet’s Smart Class Parameters / Smart Variables. For most puppet classes foreman knows which parameters are necessary. The puppet class defines the parameters and the default value in the class definition and foreman can parse this definition and show the appropriate parameters in the UI. This isn’t possible in ansible right now.
To configure the ansible roles, we can do it in multiple ways:
- configure each ansible role with a single textarea field in which you can set the variables. Each hostgroup / host could just overwrite the variable definition. Looks like Ansible Tower provides only such a textarea field, too but I guess Ansible Tower fulfills a different use-case.
- re-use the smart class parameters / smart variables from puppet and adjust it to the ansible world
- create a new configuration view for the ansible role variables. Maybe based on React. I guess, this component can be a little bit easier that puppet Smart Class Parameter. It would also be possible to re-use this component to be used for Saltstack, Chef and maybe Puppet later on, too.
To improve the experience of foreman for the system administrator, who doesn’t write ansible roles but deploys new hosts and sets the parameters of a ansible role, we can introduce something like a role_meta.yaml file:
- Developer provides a ansible role (maybe from ansible galaxy) and stores this role to foreman
- The ansible role has multiple configuration parameter. The developer writes a role_meta.yaml which describes the parameter + types + default values (+ ranges and validators) and attach the role_meta.yaml to the ansible role.
- Foreman does now know, which parameters for a given ansible role exist and is able to create the user interface including the default parameters.
- The system admin can use the user interface to overwrite the parameters.
Thinking further ahead, it might be possible to “generate” the role_meta.yaml based on the first definition of a ansible role. Means, during the first time configuration of the ansible role the available parameters + types + default values must be given. If you configure the ansible role in this way completely, then you know which parameters exist, which type they require etc. Based on this information it might be possible to save the role_meta.yaml so that the user interface for other hosts is auto-generated.
What’s your opinion? Which route should we take?
Best regards,
Bernhard
1 Like
Hello
thanks for the write up. I like the idea of reusing smart variables. They were slowly replaced by smart class parameters already and I think they are rarely used today with puppet. If we could cut the connection between them and puppet classes I think we’d get all we need as they support all that smart class parameters do.
I’d prefer to avoid introducing new parameter type into the stack
I like the idea about role_meta.yaml, though it might be worth of discussing this also with ansible community. Or if we could get 90% of information from default.yml in role, just parse that and let user add missing parts manually in UI. Exporting back to some yaml file seems like a great addition!
–
Marek
Hello,
I am not sure whether this will cover all mentioned points. But this PR-5241 [https://github.com/theforeman/foreman/pull/5241] i.e global parameters with types will help to configure ansible roles in foreman instead of using Smart Class Parameters / Smart Variables.
_
Kavita
Thanks, that would be a good intermediate solution.
Unfortunately I still think Smart Parameters tend to fit the use case better, as we already have an UI pattern for this, overriding variables, etc… should be very similar. Plus we can benefit from matchers like “override if domain=something” etc… which we cannot do with Global Parameters.
I’m working on a POC of Ansible params which you may test in https://github.com/dlobatog/foreman_ansible/tree/ansible-params and https://github.com/dlobatog/smart_proxy_ansible/tree/smart_class_params - still largely WIP.
1 Like
