Feature Request: Using/Setting more unique variables in Ansible Operators

[tima]

Feature Request

Is your feature request related to a problem? Please describe.

The Ansible Operator SDK stores things like name in meta.name. Using something as generic and nondescript as that is considered bad Ansible form and style given the engine’s flat namespace and the potential for collision.

Describe the solution you'd like

The idea here would be to transition what’s in stored meta to something like ansible_operator or something else sufficiently unique and descriptive. It's worth noting, Ansible itself uses ansible_* for any variables set by the system so it might be worth consideration here.

I don't know what is the best way to do this without causing some sort of breaks in existing/working operators using Ansible. I think it's important to consider and is better fixed now, pre "1.0" rather than waiting for namespace collisions to happen later when many Operators using Ansible have been deployed are run into collisions.

[geerlingguy]

Just wondering for this—is meta.name a convention across different operator languages (e.g. Go, Java, etc.)? If so, then maybe that's a good reason to stick with it.

Otherwise, one argument against it may be that in an operator context, these variables aren't necessarily ansible-related, but rather operator-related.

But I do see what you're saying, all the 'magic' variables/facts that are available to describe a given environment (e.g. ansible_ipv4, ansible_distribution, etc.) are ansible_-prefixed.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[camilamacedo86]

Hi @geerlingguy,

I am not sure if I got this one. Are you looking for all ENV VARs which are used/available to ansible starts with the prefix ansible? Could you please point out some examples over how you are checking it in the project X what you expected to see?

@fabianvf @estroz I am not sure if it is a blocker for 1.0.0. WDYT?

[geerlingguy]

@camilamacedo86 - I know @fabianvf, @tima and I were talking about this, and I think the idea was we'd put these vars behind an ansible_operator_ prefix.

In Ansible itself, there are a variety of environment-based 'facts' Ansible gathers prior to running playbooks (unless you disable fact gathering).

I imagine some things that would be really nice to have available would be things like:

• ansible_operator_version (like 1.18.0)
• ansible_operator_namespace (the namespace where the operator is currently running)
• ansible_operator_cluster_version (k8s or ocp cluster version, e.g. 1.18.1 or 4.3...)
• ansible_operator_last_reconciliation (or other timing-related facts?)
• ansible_operator_status (with the status/event information that would also be reported when running kubectl describe [operator]).

This is just kind of thinking out loud, though. I think the main goal was to get a structure for facts in place, then over time we could add things to it if desired.

[fabianvf]

@camilamacedo86 yeah, we're going to get the change from meta to ansible_operator_meta in before 1.0 at least, I was planning to do so immediately after the scaffold changes merge

[camilamacedo86]

Thank you for the clarifications :-)

[camilamacedo86]

/remove-lifecycle stale