Hi all, we had some discussion about this over the course of time. While at first, we were not convinced by nailgun to be the right choice, we have strong arguments for it by now: As already mentioned, one of the biggest plusses being, that it is developed by a large QA team. And as a side effect it is well tested. It is meant to make the satellite/foreman api useable in a common way. Citing the Nailgun readme: "The Satellite 6 API is not consistent in its implementation. For example, see the “Payload Generation” section of this blog post." Sadly, these inconsistencies shine through Nailgun, leading to inconsistencies in e.g. the search functionality. See also https://github.com/SatelliteQE/nailgun/issues/423 . This lead to a lot of repetitive code in our cement library that was originally meant to follow the DRY principle (many 'find_something' routines instead of a generic 'find_entity'). We think, nailgun should serve as an abstraction layer here, and level out these rough edges of the Satellite/Foreman api. As for the duplicate modules, we would wait for the final choice of the backing library and switch to the corresponding implementation afterwards. Then, of course we should compare their functionality and see what can be ported.
Matthias and the Atix Crew -----Ursprüngliche Nachricht----- > Von:Eric D Helms <[email protected]> > Gesendet: Donnerstag 26 Oktober 2017 17:06 > An: foreman-dev <[email protected]> > Betreff: Re: [foreman-dev] Community-developed Ansible modules for Foreman > API objects > > > > On Tue, Oct 24, 2017 at 3:47 PM, Thomas Krahn <[email protected] > <mailto:[email protected]>> wrote: > 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 didnt 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. Ansibles module_utils. > > I dont 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 Ansibles module_utils folder we wouldnt 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. > > Im not sure how far the nailgun development is, but python-foreman is open > source and im 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 Id > 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 dont 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 wed 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 > > Ive 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 thats something the community would like to see...lets 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 > > <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 > <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): > > 1) merge your modules in, even if we put them in a separate directory for > now to avoid the clashes > 2) Add you as a maintainer on the repository > 3) Then you can update your repository to say weve moved > 4) 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 > If anyone has an idea how to fix that let me know ;) > > > Happy to see how its 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 [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > <br clear="all" /> > -- > Eric D. Helms > Red Hat Engineering > -- > 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 [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
