You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 10, 2017. It is now read-only.
The platform list continues to grow. Requests to add additional operating systems and versions are never-ending, and we perpetually fail to complete them in a timely fashion.
The current incarnation of platform does not really fit network operating systems. In many cases there either is no version or there are many, many versions, and in both cases we have adopted using any for the version.
It also fails to fit container roles. For example, Container App roles don't have a single operating system or platform. If a platform maps to a container's base image, Container Apps consist of many containers, so there may be multiple base images involved. This doesn't fit, and it's confusing.
Another issue is the list of platforms we manifest in the meta/main.yml template when the ansible-galaxy init command executes. The resulting list is unmanageable.
And finally, creating the meta/main.yml template requires a Galaxy API request. This is undesirable if the user does not have internet access or the Galaxy server happens to be down.
Proposal
Make platforms behave more like tags by doing the following:
Allow users to provide a list of platform values they think are appropriate
Modify the import process to accept a format of Platform_Name:Version, and allow :Version to be optional. This is in keeping with the Docker image format.
Completely remove the list of platform values from the meta/main.yml template, replacing it with "platforms: []" and appropriating commenting with examples. This naturally removes the API call.
Modify the Galaxy data model to no longer validate platform names and versions, and allow version to be optional.
The text was updated successfully, but these errors were encountered:
I'm inclined to agree. Seems clear that by mandating certain platforms, we've become a bottleneck.
What we lose is the ability to enforce uniformity -- but you can't have everything. Means that our fuzzy search may have to be a bit better, and also means that role owners will have incentive to make sure the platforms they choose are easily discoverable.
Problem
The platform list continues to grow. Requests to add additional operating systems and versions are never-ending, and we perpetually fail to complete them in a timely fashion.
The current incarnation of platform does not really fit network operating systems. In many cases there either is no version or there are many, many versions, and in both cases we have adopted using any for the version.
It also fails to fit container roles. For example, Container App roles don't have a single operating system or platform. If a platform maps to a container's base image, Container Apps consist of many containers, so there may be multiple base images involved. This doesn't fit, and it's confusing.
Another issue is the list of platforms we manifest in the
meta/main.yml
template when theansible-galaxy init
command executes. The resulting list is unmanageable.And finally, creating the
meta/main.yml
template requires a Galaxy API request. This is undesirable if the user does not have internet access or the Galaxy server happens to be down.Proposal
Make platforms behave more like tags by doing the following:
Platform_Name:Version
, and allow :Version to be optional. This is in keeping with the Docker image format.The text was updated successfully, but these errors were encountered: