> Hi all,
>
> as the maintainer of the Ansible Foreman modules
> <https://github.com/Nosmoht/ansible-module-foreman> i would like to share
> my thoughts with you.
>
> First of all i really like the idea to bring Foreman modules into Ansible.
> The complete configuration of Foreman is much easier if you can use
> Infrastructure as Code.
> That was the reason why i started the implementation in March 2015. At
> this time Ansible didn't have the module_utils folder and modules had to be
> "self contained".
> So the only way to use shared code was to create a Python library and use
> it. My result of that constraint is the Python Foreman library
> <https://github.com/Nosmoht/python-foreman>.
> It was and still is a challenge to always sync the modules and the library
> functionality.
>
> As far as i can see Nailgun is the library to work with Satellite 6 API.
>
> In regards to the future used library i see three different options so far:
> 1. nailgun
> 2. python-foreman
> 3. Ansible's module_utils.
>
> I don't want to talk about functionality here, but more about constraints
> and dependencies.
> If either nailgun or python-foreman is used people would have to install
> the library to use the Ansible modules and could have the same sync issue
> like i had in the past.
> Besides that i believe the library would have even more dependencies
> (python-requests for example) which could make things even more worst.
> On the other hand people would have a Python library that could even be
> used outside of Ansible for other tasks.
>
> If all that stuff is put into Ansible's module_utils folder we wouldn't
> have any sync issue nor external dependencies, but the usage would be
> limited to Ansible.
> And Ansible provides a great framework that abstracts a lot of things
> (methods like fetch_url() and open_url()) that otherwise would have to be
> reimplemented.
>
> Long term speaking i believe a common Python library would be the winner
> as it provides a standardized and well tested Foreman/Satellite interface
> to the world.
>
> I'm not sure how far the nailgun development is, but python-foreman is
> open source and i'm happy to hand out the ownership of that repository.
>
The idea of entirely self contained Ansible modules is a nice one,
especially from a user perspective at first. I say at first, because once
things are setup the user has less to worry about. And, at least currently,
I think there is some precedence among modules in Ansible today requiring
outside python packages. If no python API was being used today to talk to
Foreman I'd jump right on this option.
Given that there are at least two python API projects, one of which, as
Andrew points out, is actively used and contributed to by a large QE team
leads me to conclude external API package should win out to reduce
repeating ourselves, fixing the same issues in multiple places and
diverging. Sometimes, when the goals differ enough, creating a separate way
to do similar things can be beneficial, in this case I don't think they
differ enough.
We are in discussion with the team that owns Nailgun to bring it into the
community proper. One benefit to it is that it has Foreman plugin support
built into it already (e.g. Katello). There is a likelihood of a gap
existing between the two API projects that we'd need to resolve.
I will say, I can be swayed if shown that writing and supporting the API is
not that difficult, but I do tend towards community effort in one place if
we can.
>
>
>
> Next topic: Ansible modules
>
> I've already done a lot of work to move the modules from python-foreman +
> modules into "everything in Ansible".
> Means all the library stuff goes into module_utils/foreman.py plus all the
> modules in modules/cloud/foreman/*.py.
> Nearly 75% of that work is done so i could open a PR for each module that
> is already finished.
> If that's something the community would like to see…let's do it 
>
I assume here you are talking about moving modules into ansible/ansible for
delivery via 'package-management-tool install ansible' and making them
available system wide? If so, some info and thoughts. Currently there is
some raw building blocks there now from a time when I tried to be too smart
with some modules I had made:
https://github.com/ansible/ansible/tree/devel/lib/ansible/modules/remote_management
This is not in cloud as you suggested, as I thought cloud would pigeonhole
Foreman and plugins too much given it does so much more than simply cloud.
Given manageiq modules are in this same directory, I tend towards feeling
this is the right spot for management projects like ours.
The second point I think worth discussing is at what level and time should
we push modules to ansible/ansible versus providing them via a stand alone
git repository. I think there are pros and cons to both when it comes to
managing the modules, getting changes into the modules, developing new
modules or functionality and ease of use by a user. I think we want to
balance development efficiency with ease of use.
>
> I wanted to commit that code into https://github.com/theforeman/
> foreman-ansible-modules but had some issue.
> - I would overwrite the nailgun using modules like foreman_ptable.py etc.
> - there is no place to put Ansible module documentation fragments into
> like utils/module_docs_fragments/foreman.py
>
>
We can get that directory made (Andrew?). As for over-writing versus
merging the two ideas when there are competing modules, I tend to defer a
bit to the ATIX-crew who wrote most of the Foreman ones currently in there.
But I assume this in general will likely depend on the prior topic of
discussion.
If the other maintainers on the repository are OK with it, I think my
preferred plan (to help get your code centralized and more eyes and hands
working on it):
- merge your modules in, even if we put them in a separate directory for
now to avoid the clashes
- Add you as a maintainer on the repository
- Then you can update your repository to say we've moved
- In between all of those keep discussing the above
This will allow the benefits noted above, and allow us to just do further
re-factoring depending on direction within the theforeman repository.
Eric
···
On Tue, Oct 24, 2017 at 3:47 PM, Thomas Krahn wrote:
If anyone has an idea how to fix that let me know 
Happy to see how it’s going on
Nosmoht
–
You received this message because you are subscribed to the Google Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Eric D. Helms
Red Hat Engineering
