Comply with updated Ansible sanity test rules

[AlanCoding]

SUMMARY

See:

ansible/proposals#178 (comment)

In this case, version_added should not be there, because the option was there when the module was introduced to the collection.

That applies for the auto-migrated collections, and other maintainers still can go their own way. But the tests don't allow for pinning versions from ansible-base. So we can't keep the old stuff. That decision has already been made.

There are some other wonky things in here, because we are balancing 2 different namespaces. For the 3 deprecated modules not shipped in the ansible.tower collection, we are free to reference awx.awx versions.

In the modules where we deprecate things which are in ansible.tower, we prefer Tower versions over AWX versions. Thus, we ignore those rules permanently for awx.awx. We might have to delete those rules for the ansible.tower collection (because it will become correct with the namespace change, and will trigger the unnecessary-ignore rule). Let me ping @felixfontein here, because I'm sure they weren't anticipating this situation of releasing the same content under 2 different namespaces.

ISSUE TYPE

• Bugfix Pull Request

[softwarefactory-project-zuul]

Build succeeded.

• awx-api-lint : SUCCESS in 9m 11s
• awx-api : SUCCESS in 14m 36s
• awx-ui : SUCCESS in 4m 31s
• awx-ui-next : SUCCESS in 15m 23s
• awx-swagger : SUCCESS in 9m 32s
• awx-detect-schema-change : SUCCESS in 16m 47s (non-voting)
• awx-ansible-modules : SUCCESS in 9m 53s

[softwarefactory-project-zuul]

Build succeeded.

• awx-api-lint : SUCCESS in 2m 07s
• awx-api : SUCCESS in 9m 56s
• awx-ui : SUCCESS in 3m 50s
• awx-ui-next : SUCCESS in 11m 14s
• awx-swagger : SUCCESS in 8m 17s
• awx-detect-schema-change : SUCCESS in 7m 58s (non-voting)
• awx-ansible-modules : SUCCESS in 2m 17s

[felixfontein]

@AlanCoding do I understand correctly that you have one set of sources (https://github.com/ansible/awx/tree/devel/awx_collection) for two different collections (awx.awx and ansible.tower)? Do both use the same version numbers, or do these also differ?

ansible/proposals#178 (comment)

In this case, version_added should not be there, because the option was there when the module was introduced to the collection.

That applies for the auto-migrated collections, and other maintainers still can go their own way. But the tests don't allow for pinning versions from ansible-base. So we can't keep the old stuff. That decision has already been made.

Well, the consensus seemed to be that version_added refers to the collection version the content is contained in. The typical user story is: I need collection x.y, and I need feature z in it. So which version of the collection do I need so I get this feature? If the user looks at the docs and finds a version number unrelated to the collection version number, this is not helpful.

I guess you can still mention this in description.

There are some other wonky things in here, because we are balancing 2 different namespaces. For the 3 deprecated modules not shipped in the ansible.tower collection, we are free to reference awx.awx versions.

So both collections have different version schemes? I unfortunately only found one of them (https://galaxy.ansible.com/awx/awx), so I cannot compare.

In the modules where we deprecate things which are in ansible.tower, we prefer Tower versions over AWX versions. Thus, we ignore those rules permanently for awx.awx. We might have to delete those rules for the ansible.tower collection (because it will become correct with the namespace change, and will trigger the unnecessary-ignore rule). Let me ping @felixfontein here, because I'm sure they weren't anticipating this situation of releasing the same content under 2 different namespaces.

If you release the same content under two different namespaces, you might want to template the content in a way that the correct version numbers are added in both namespaces.

[AlanCoding]

do I understand correctly that you have one set of sources (...) for two different collections

Yes, one is on Galaxy and the other is one cloud.redhat.com.

Do both use the same version numbers, or do these also differ?

Versions are different, because versions are hard-and-fast bound to the server versions. It is exactly as confusing as what the original decisions for server versioning were. AWX leapfrogged Tower versions intentionally, so that they don't hit the 3.x.x series.

For an idealized case moving forward, I think we would have version_added: match the Ansible Tower (and ansible.tower collection) version, and the documentation could also helpfully state the AWX version. The Tower versions would always be x.x.0, because the dot-releases should never introduce new features.

Templating (replacing) the namespace is one thing, but replacing version numbers would require a mapping of versions of one server version to the other. Such a mapping never has existed. I don't want to start such a thing strictly for the purposes of the collection.

[felixfontein]

Then why not just put the ansible.tower versions into version_added in the correct format (semver, i.e. x.y.0)? ansible-test only ensures that versions are of the correct format (i.e. semver for collection versions). Also, if you want to put other version numbers there, why not simply add ignore.txt entries?

[AlanCoding]

Isn't that what I'm doing here?

I think I might see a point of confusion. There are 3 deprecated modules right now, and these were explicitly excluded from ansible.tower. So if tower_send shows an AWX version, that's because this is only an AWX module.

[felixfontein]

Ah, I eventually found that. I had to scroll down several pages before I found a version_added that wasn't removed. I was wondering why you're still removing all these numbers. Are these Tower versions, and is Tower using versions that are not of the form x.y.z?

[AlanCoding]

The version numbers being removed are almost entirely Ansible versions from 2.9 or earlier. Even things that were added since then didn't use awx.awx versions, so it seems like there's no way to salvage them.

[felixfontein]

I saw a lot of 3.7 removed, that's why I assumed that all x.y versions must be Tower.

[AlanCoding]

oh right, 3.7.0 was the initial version of ansible.tower, but awx.awx existed for a few months before then. In terms of ansible.tower versioning, that would still make it the initial collection version.

[softwarefactory-project-zuul]

Build succeeded (gate pipeline).

• awx-api-lint : SUCCESS in 1m 57s
• awx-api : SUCCESS in 7m 02s
• awx-ui : SUCCESS in 3m 45s
• awx-ui-next : SUCCESS in 7m 19s
• awx-swagger : SUCCESS in 8m 19s
• awx-detect-schema-change : SUCCESS in 8m 08s (non-voting)
• awx-ansible-modules : SUCCESS in 2m 06s
• awx-push-new-schema : SUCCESS in 7m 43s (non-voting)