search

infobloxopen / infoblox-ansible

Ansible modules for interfacing to Infoblox systems
GNU General Public License v3.0
54 stars 61 forks source link

Any version of this module that does not require the "infoblox-client"? #219

Open jewettg opened 5 months ago

jewettg commented 5 months ago

Is there any version of this module that does not require the "infoblox-client" python code/library?

Attempting to use this module within any playbooks that are executed in Ansible Automation Platform require that a custom execution-environment to include the "infoblox-client" code for it to run. This is difficult to support since it requires that the EE gets updated when there are changes in the client.

Reviewing the code in "infoblox-client", shows that it is just a python collection of code that utilizes the REST-API feature of InfoBlox, and this module is just piggy-backing on that code, instead of calling the REST API calls themselves directly.

REST API documentation: https://insights.infoblox.com/resources-deployment-guides/infoblox-deployment-infoblox-rest-api

Thoughts?

matthewdennett commented 5 months ago

@jewettg, I'm curious to know what the difficulties you experience managing a custom EE with the required python modules? I commonly see custom EEs being maintained to support different needs, platforms and collections. Most of the time the EE is built from a pipeline automating the build, test and publish of the EE so updates are as simple as updating a requirements.txt and kicking the pipeline off.

There are a lot of things that could be improved in this collection and this could be one of them. It would possibly be quite a lot of duplication of what is in the "infoblox-client" module, which is probably why it was used in the first place. It would also be a huge rework of the entire collection. I'm not sure, if the convenience not needing to install the "infoblox-client" module in your EE would justify the undertaking. I guess that is something for the maintainers to chime in on though.

jewettg commented 5 months ago

The difficulties I was referring to are the portability and complexity. We do not support custom EEs as it adds another layer of complexity to our automation stack, requiring dependencies, setup, and configuration to allow the automation to run. The portability is also an issue when we want to develop locally and then add it to Ansible Automation Platform (can not be easily done by regular uses, requires service administrator to be involved, thus dissolves the ability for self-support).

In general, it is just bad practice, to require a collection to have a outside dependency on code that is separately maintained. All kinds of nuances and issues can occur in that case, unless you are monitoring both collection and client code bases, making yourself ultimately familiar with both.

So far, we have avoided using custom EEs by using properly written collections or relying on the REST APIs. It looks like that is our path this time as well. If we decide to write our own collection to standardize REST API calls, we will share our code or contribute it to the collection.

badnetmask commented 5 months ago

As a contributor to this module, I have to agree with @matthewdennett that re-writing it to be independent from the Python library would be a daunting task, which I don't see a lot of reward in it. We would end up with a lot of duplicated code on both sides, and probably some discrepancy at some point. I would leave the final word to the official maintainers of the collection.

As an IT engineer that manages a large AAP deployment, I would say that your need to support custom EEs is just a matter of time. We also did not want to do such a thing for a while, but we had to accept that the further along we went into our automation journey, the more complex things get, and eventually we had to apply some level of customization because the product engineering cannot think of all the corner/edge cases out there. We do leverage a very high level of self-service in our environment, and that is one of the reasons why custom EEs ended up being required: other teams (both app development and infrastructure teams) were finding exotic solutions to their particular use-cases which the automation team was not able to provide or support, so we ended up creating a self-service process for people to build their own EEs.

With all that said, I'm not trying to discourage you from your request, it's not my place to decide, I'm just adding another point of view based on my experience with both things (this module and AAP).