Story #2345
Updated by jchristi about 8 years ago
*User Story* As a pulp user, I would like to be able to host a private instance of Ansible Galaxy with Pulp so that my organization can share and reuse Ansible roles across teams without having to use the public galaxy.ansible.com (ie, if our code contains sensitive information, or organization-specific stuff, etc). *User role* Administrator of Pulp installation or Ansible playbook developer or similar sysadmin/developer/devops/IT role. *Context* An IT organization that makes use of configuration management, deployment orchestration, and/or automated provision with Ansible may have certain parts of their Ansible code that they want to share across teams but do not want to distribute publicly on galaxy.ansible.com (ie. security, privacy, IP concerns, not useful outside organization, etc). While use of git repositories provides a basic means of sharing code, it is not as elegant as a package manager like "Ansible's galaxy":http://docs.ansible.com/ansible/galaxy.html (similar to Puppet's puppet forge, Python's pip, Ruby's rubygems, and NodeJS's npm), which allows for project dependencies to be defined and packaged in a standard way so that they can be easily downloaded and used without having to include the packages themselves in the project source code. Fine grained dependency management is obtained by versioning of packages and specifying which versions of those packages to use in a dependent project. An IT organization desiring this capability for Ansible roles may already make use of Pulp for package management for of other technologies (RPM, Puppet, Python, etc) and could re-use their existing infrastructure to accomplish the same functionality for Ansible. Note: It is entirely possible that the use of a front-end is really superfluous since it appears that package management can be achieved with just the ansible-galaxy CLI + git repositories (I haven't verified this or fully thought this through and welcome feedback). *Description* There are two main functionalities: (1) a completely private repository and (2) a mirror of Ansible galaxy similar to the puppet forge mirror functionality currently in Pulp. The two probably need to be implemented together so that a single URL can be provided to ansible-galaxy CLI as the location to fetch packages (roles) from. Now that "Ansible Galaxy is open source":https://www.redhat.com/en/about/press-releases/red-hat-launches-first-open-source-release-ansible-galaxy this greatly increases the ease of implementation for integration into Pulp. One potential issue is that ansible galaxy currently appears to depend on use of github.com as the storage mechanism for ansible roles (verification needed). This raises the question of should Pulp become the storage mechanism or should it mimic current galaxy.ansible.com functionality of acting only as a front-end to a separate back-end git repository. It seems like galaxy does not do much heavy lifting itself, choosing to rely on ansible-galaxy CLI for dependency resolution and github.com and git for storage and version tagging, Note: It is entirely possible that the use of a front-end is really superfluous since it appears that package management can be achieved with just the ansible-galaxy CLI + git repositories (I haven't verified this or fully thought this through and welcome feedback). *Done Criteria* * Ansible playbook developer can pull dependencies from Pulp by "specifying a custom endpoint":http://docs.ansible.com/ansible/galaxy.html#the-ansible-galaxy-command-line-tool * Pulp is not necessarily required to host the packages itself if suitable forwarding to an appropriate git server is possible and sufficient. * Access to public ansible roles is possible either via mirroring/local caching or forwarding *Additional Information* * https://galaxy.ansible.com/intro#welcome * http://docs.ansible.com/ansible/playbooks_roles.html#roles * http://docs.ansible.com/ansible/galaxy.html * https://www.redhat.com/en/about/press-releases/red-hat-launches-first-open-source-release-ansible-galaxy
.