Community-developed Ansible modules for Foreman API objects

Hi all,

We're seeing more and more interest in Ansible within the Foreman
community, and one facet of that is the ability to deploy Foreman
itself using Ansible. That obviously requires a set of resources that
use the Foreman API to create/update objects in Foreman. That effort
has already been started with the ansible-modules repo [1] which uses
Nailgun [2] underneath. At present, there are 5 Foreman resources in
this repo (and another 12 Katello ones).

However, there is also a community member workingon this in parallel
[3] using a different Python layer [4] underneath. That repo contains a
much larger / more complete set of API resources, and it would be a
shame not to use it, and to give credit to it's creator.

So, this is a call for collaboration on how to bring these together.
I've reached out to Nosmoht (BCC'd on this mail, hi!) and he's willing
to participate in this effort, so next we'll be needing a few more
volunteers to join in, and discuss how to proceed. From my perspective,
I think it makes sense to continue to use the "theforeman" repo for now
(things under our namespace are easier to promote as 'official'), merge
in Nosmoht's modules (and make him a committer / maintainer) and then
work on standardising all the modules to use the same underlying tool
(and deate which one it should be). Once we're happy with the stability
of the repo, we can consider trying to get it added to the Ansible
repos.

Thoughts?

Cheers
Greg

[1] https://github.com/theforeman/foreman-ansible-modules
[2] https://github.com/SatelliteQE/nailgun
[3] https://github.com/Nosmoht/ansible-module-foreman
[4] https://github.com/Nosmoht/python-foreman

2 Likes

Hi there,

speaking from our site (Atix-Crew) this is an excellent idea.

We are already putting an effort into this topic working with Andrew,
Eric and Evgeni.

We also oriented us in the past Nosmoht's basic ideas -props to him!!-
and committed some PRs on

his modules, meaning we know the general architecture of his
implementation.

We are definitely up for any discussion and would love to be part of
this collaboration.

Cheers,

Bernhard, Matthias & The Atix Crew

··· On 10/06/2017 03:37 PM, Greg Sutcliffe wrote: > Hi all, > > We're seeing more and more interest in Ansible within the Foreman > community, and one facet of that is the ability to deploy Foreman > itself using Ansible. That obviously requires a set of resources that > use the Foreman API to create/update objects in Foreman. That effort > has already been started with the ansible-modules repo [1] which uses > Nailgun [2] underneath. At present, there are 5 Foreman resources in > this repo (and another 12 Katello ones). > > However, there is also a community member workingon this in parallel > [3] using a different Python layer [4] underneath. That repo contains a > much larger / more complete set of API resources, and it would be a > shame not to use it, and to give credit to it's creator. > > So, this is a call for collaboration on how to bring these together. > I've reached out to Nosmoht (BCC'd on this mail, hi!) and he's willing > to participate in this effort, so next we'll be needing a few more > volunteers to join in, and discuss how to proceed. From my perspective, > I think it makes sense to continue to use the "theforeman" repo for now > (things under our namespace are easier to promote as 'official'), merge > in Nosmoht's modules (and make him a committer / maintainer) and then > work on standardising all the modules to use the same underlying tool > (and deate which one it should be). Once we're happy with the stability > of the repo, we can consider trying to get it added to the Ansible > repos. > > Thoughts? > > Cheers > Greg > > [1] https://github.com/theforeman/foreman-ansible-modules > [2] https://github.com/SatelliteQE/nailgun > [3] https://github.com/Nosmoht/ansible-module-foreman > [4] https://github.com/Nosmoht/python-foreman >


Herzliche Grüße aus München

 Bernhard Hopfenmüller

 OSAD Open Source Automation Day
 19.10.2017 in der BMW Welt München

 www.osad-munich.org

 JETZT ANMELDEN!
1 Like

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.

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 :slight_smile:

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

If anyone has an idea how to fix that let me know :wink:

Happy to see how it's going on
Nosmoht

Nailgun is used for Satellite's QA for testing the API. It's not
purpose-built for Ansible, but it is generally written as a Python library
for Satellite's API. We get 'free' maintenance/features with Nailgun
because the QA team contributes to it (we have access as well). Nailgun
seems to have similar dependencies to python-foreman (i.e. requests).

> - I would overwrite the nailgun using modules like foreman_ptable.py etc.

We still need to discuss what we will do with duplicate modules (whether to
use python-foreman or nailgun). If there are modules that don't exist in
foreman-ansible-modules, we would appreciate PRs for those.

  • there is no place to put Ansible module documentation fragments into like
    > utils/module_docs_fragments/foreman.py

I would say just create utils/module_docs_fragments in your PR.

If given a choice, I would vote for Nailgun, a more mature project with
more contributors and guaranteed future contribution from Satellite QA.
There is a bit of a gap between foreman-ansible-modules and Nailgun, given
that it is not purpose built; for this, we do include
ansible_nailgun_cement.py [1].

I appreciate the support and interest from the community.

[1]

Andrew

··· On Tue, Oct 24, 2017 at 3:47 PM, Thomas Krahn 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 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.

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 :slight_smile:

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

If anyone has an idea how to fix that let me know :wink:

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.


Andrew Kofink
akofink@redhat.com
IRC: akofink
Software Engineer
Red Hat Satellite

> 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 :slight_smile:
>

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):

  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 we've 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

··· On Tue, Oct 24, 2017 at 3:47 PM, Thomas Krahn wrote:

If anyone has an idea how to fix that let me know :wink:

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

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 > Gesendet: Donnerstag 26 Oktober 2017 17:06 > An: foreman-dev > Betreff: Re: [foreman-dev] Community-developed Ansible modules for Foreman API objects > > > > On Tue, Oct 24, 2017 at 3:47 PM, Thomas Krahn <thomas.krahn.tk@gmail.com > wrote: > Hi all, > > as the maintainer of the Ansible Foreman modules 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 . > 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 > > 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): > > 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 foreman-dev+unsubscribe@googlegroups.com . > For more options, visit https://groups.google.com/d/optout . > >
> -- > 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 foreman-dev+unsubscribe@googlegroups.com . > For more options, visit https://groups.google.com/d/optout .

[…]
> If given a choice, I would vote for Nailgun, a more mature project with
> more contributors and guaranteed future contribution from Satellite QA.
> There is a bit of a gap between foreman-ansible-modules and Nailgun, given
> that it is not purpose built; for this, we do include
> ansible_nailgun_cement.py [1].
>
> I appreciate the support and interest from the community.

So far we've only used python-foreman in a few different projects, one to
configure Foreman based on a YAML file. We use python-foreman to resolve the
IDs first thus the actual names of the templates, etc. can be used. Working
with the lib is nice but it still needs some glue because the API is
inconsistent and doing a lookup for the ID is not aligned for all resources.

I have no experience with nailgun but from my point of view dependencies are
not that big of a deal when provided as proper packages. E.g. to use the
Ansible mysql_db module you require python-mysqldb.

I'd love to switch to an upstream Ansible module to configure Foreman and
improve our existing playbooks.

Thanks for all the hard work so far!

Kind regards

Michael

··· On Wed, 25 Oct 2017 08:09:10 -0400 Andrew Kofink wrote:
Here's a radical thought, use Hammer...

Ansible modules do not have to be written in Python[2], although Ansible does provide some nice shortcuts with Python, all that is really required is JSON output... Some Ruby examples [1]
A couple of things to note if we were to entertain going down this route; - How does DOCUMENTATION work for non-python modules? I played around for a bit, but couldn't get ansible-doc to work..
- If the goal is to get them into Ansible core, will they accept Ruby modules? Looking at Ansible core I think all the modules are python...

[1] https://github.com/ansible/ansible-for-rubyists
[2]
http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/developing_modules.html

··· On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer < michael.hofer@adfinis-sygroup.ch> wrote:

On Wed, 25 Oct 2017 08:09:10 -0400 > Andrew Kofink <akofink@redhat.com> wrote:
[...]
If given a choice, I would vote for Nailgun, a more mature project with
more contributors and guaranteed future contribution from Satellite QA.
There is a bit of a gap between foreman-ansible-modules and Nailgun,
given
that it is not purpose built; for this, we do include
ansible_nailgun_cement.py [1].

I appreciate the support and interest from the community.

So far we've only used python-foreman in a few different projects, one to
configure Foreman based on a YAML file. We use python-foreman to resolve
the
IDs first thus the actual names of the templates, etc. can be used. Working
with the lib is nice but it still needs some glue because the API is
inconsistent and doing a lookup for the ID is not aligned for all
resources.

I have no experience with nailgun but from my point of view dependencies
are
not that big of a deal when provided as proper packages. E.g. to use the
Ansible mysql_db module you require python-mysqldb.

I'd love to switch to an upstream Ansible module to configure Foreman and
improve our existing playbooks.

Thanks for all the hard work so far!

Kind regards

Michael

--
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.

I had a look at this at some point but what I really dislike about Hammer as an API is that the JSON output is also capitalized and inconsistent. Ended up with large mappings and quickly gave up. Maybe I missed something and it can be done easily.


··· On Wed, Nov 29, 2017 at 09:35:46AM +0000, Sean O'Keeffe wrote:
Here's a radical thought, use Hammer...

Ansible modules do not have to be written in Python[2], although Ansible
does provide some nice shortcuts with Python, all that is really required
is JSON output... Some Ruby examples [1]
A couple of things to note if we were to entertain going down this route;
- How does DOCUMENTATION work for non-python modules? I played around for a
bit, but couldn't get ansible-doc to work..
- If the goal is to get them into Ansible core, will they accept Ruby
modules? Looking at Ansible core I think all the modules are python...

[1] https://github.com/ansible/ansible-for-rubyists
[2]
http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/developing_modules.html

On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer < >michael.hofer@adfinis-sygroup.ch> wrote:

On Wed, 25 Oct 2017 08:09:10 -0400 >> Andrew Kofink <akofink@redhat.com> wrote:
[...]
If given a choice, I would vote for Nailgun, a more mature project with
more contributors and guaranteed future contribution from Satellite QA.
There is a bit of a gap between foreman-ansible-modules and Nailgun,
given
that it is not purpose built; for this, we do include
ansible_nailgun_cement.py [1].

I appreciate the support and interest from the community.

So far we've only used python-foreman in a few different projects, one to
configure Foreman based on a YAML file. We use python-foreman to resolve
the
IDs first thus the actual names of the templates, etc. can be used. Working
with the lib is nice but it still needs some glue because the API is
inconsistent and doing a lookup for the ID is not aligned for all
resources.

I have no experience with nailgun but from my point of view dependencies
are
not that big of a deal when provided as proper packages. E.g. to use the
Ansible mysql_db module you require python-mysqldb.

I'd love to switch to an upstream Ansible module to configure Foreman and
improve our existing playbooks.

Thanks for all the hard work so far!
Yeah, modules have to be written in Python for inclusion in Ansible core [1].

[1]
http://docs.ansible.com/ansible/latest/dev_guide/developing_modules_checklist.html

··· On Wed, Nov 29, 2017 at 4:40 AM, Ewoud Kohl van Wijngaarden < ewoud@kohlvanwijngaarden.nl> wrote:

I had a look at this at some point but what I really dislike about Hammer
as an API is that the JSON output is also capitalized and inconsistent.
Ended up with large mappings and quickly gave up. Maybe I missed something
and it can be done easily.

On Wed, Nov 29, 2017 at 09:35:46AM +0000, Sean O'Keeffe wrote:

Here's a radical thought, use Hammer...

Ansible modules do not have to be written in Python[2], although Ansible
does provide some nice shortcuts with Python, all that is really required
is JSON output... Some Ruby examples [1]
A couple of things to note if we were to entertain going down this route;
- How does DOCUMENTATION work for non-python modules? I played around for
a
bit, but couldn't get ansible-doc to work..
- If the goal is to get them into Ansible core, will they accept Ruby
modules? Looking at Ansible core I think all the modules are python...

[1] https://github.com/ansible/ansible-for-rubyists
[2]
http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/
developing_modules.html

On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer < >> michael.hofer@adfinis-sygroup.ch> wrote:

On Wed, 25 Oct 2017 08:09:10 -0400 >>> Andrew Kofink <akofink@redhat.com> wrote:
[...]
If given a choice, I would vote for Nailgun, a more mature project with
more contributors and guaranteed future contribution from Satellite QA.
There is a bit of a gap between foreman-ansible-modules and Nailgun,
given
that it is not purpose built; for this, we do include
ansible_nailgun_cement.py [1].

I appreciate the support and interest from the community.

So far we've only used python-foreman in a few different projects, one to
configure Foreman based on a YAML file. We use python-foreman to resolve
the
IDs first thus the actual names of the templates, etc. can be used.
Working
with the lib is nice but it still needs some glue because the API is
inconsistent and doing a lookup for the ID is not aligned for all
resources.

I have no experience with nailgun but from my point of view dependencies
are
not that big of a deal when provided as proper packages. E.g. to use the
Ansible mysql_db module you require python-mysqldb.

I'd love to switch to an upstream Ansible module to configure Foreman and
improve our existing playbooks.

Thanks for all the hard work so far!

--
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.



--
Andrew Kofink
akofink@redhat.com
IRC: akofink
Software Engineer
Red Hat Satellite
As well, hammer is a bit of a beast dependency wise. We currently package it in the SCL, I'm not sure how well it works from gem install and even if with all of that you are increasing the barrier to entry for users by requiring Ruby, gem installs, potentially the SCL for newer Ruby versions. I appreciate the thought behind it but it feels more like a can of worms that is better off with the lid staying on.

Eric


··· On Wed, Nov 29, 2017 at 8:06 AM, Andrew Kofink <akofink@redhat.com> wrote:

Yeah, modules have to be written in Python for inclusion in Ansible core
[1].

[1] http://docs.ansible.com/ansible/latest/dev_guide/
developing_modules_checklist.html

On Wed, Nov 29, 2017 at 4:40 AM, Ewoud Kohl van Wijngaarden < > ewoud@kohlvanwijngaarden.nl> wrote:

I had a look at this at some point but what I really dislike about Hammer
as an API is that the JSON output is also capitalized and inconsistent.
Ended up with large mappings and quickly gave up. Maybe I missed something
and it can be done easily.

On Wed, Nov 29, 2017 at 09:35:46AM +0000, Sean O'Keeffe wrote:

Here's a radical thought, use Hammer...

Ansible modules do not have to be written in Python[2], although Ansible
does provide some nice shortcuts with Python, all that is really required
is JSON output... Some Ruby examples [1]
A couple of things to note if we were to entertain going down this route;
- How does DOCUMENTATION work for non-python modules? I played around
for a
bit, but couldn't get ansible-doc to work..
- If the goal is to get them into Ansible core, will they accept Ruby
modules? Looking at Ansible core I think all the modules are python...

[1] https://github.com/ansible/ansible-for-rubyists
[2]
http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/develop
ing_modules.html

On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer < >>> michael.hofer@adfinis-sygroup.ch> wrote:

On Wed, 25 Oct 2017 08:09:10 -0400 >>>> Andrew Kofink <akofink@redhat.com> wrote:
[...]
If given a choice, I would vote for Nailgun, a more mature project
with
more contributors and guaranteed future contribution from Satellite
QA.
There is a bit of a gap between foreman-ansible-modules and Nailgun,
given
that it is not purpose built; for this, we do include
ansible_nailgun_cement.py [1].

I appreciate the support and interest from the community.

So far we've only used python-foreman in a few different projects, one
to
configure Foreman based on a YAML file. We use python-foreman to resolve
the
IDs first thus the actual names of the templates, etc. can be used.
Working
with the lib is nice but it still needs some glue because the API is
inconsistent and doing a lookup for the ID is not aligned for all
resources.

I have no experience with nailgun but from my point of view dependencies
are
not that big of a deal when provided as proper packages. E.g. to use the
Ansible mysql_db module you require python-mysqldb.

I'd love to switch to an upstream Ansible module to configure Foreman
and
improve our existing playbooks.

Thanks for all the hard work so far!

--
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.

--
Andrew Kofink
akofink@redhat.com
IRC: akofink
Software Engineer
Red Hat Satellite

--
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
1 Like