Data migration to the new galaxy.ansible.com

Get Help
, ,
1

We had some things (namespaces, roles, collections) corrected - probably manually - on the legacy Galaxy instance, in the past (see GitHub ansible/galaxy#2535). It looks like the data was attempted to migrate, but the - presumably manual - corrections seem to have caused duplicate namespaces and roles.

See, for example, the role painless.software I maintain:

  • Role: “painless.software” → https://galaxy.ansible.com/ui/standalone/roles/painless/software/
  • GitHub repository: “painless-software/ansible-role-software” → https://github.com/painless-software/ansible-role-software

Note that the content on the role page of the new Galaxy instance points to a non-existing repository on GitHub, because it assumes the 1:1 mapping of Ansible namespace and GitHub user or org name.

Note that I do not own the “painless” user or org name on GitHub.

The resources now found on Galaxy are:

  • Searching in Roles > Role Namespaces for “painless” yields 2 results:
    1. “painless-software” (incorrect namespace, correct icon)
    2. “painless” (correct namespace, incorrect icon → looks like GitHub user “painless”)
  • Searching in Collections > Namespaces for “painless” yields only 1 result:
    1. “painless” (correct namespace, correct icon)
    2. (Note: Nothing is found searching for “painless-software”)
  • Role “painless-software.software” → https://galaxy.ansible.com/ui/standalone/roles/painless-software/software/ (incorrect namespace, correct icon)
  • Role “painless.software” → https://galaxy.ansible.com/ui/standalone/roles/painless/software/ (correct namespace, incorrect icon → looks like GitHub user “painless”)
  • Namespace for Roles, “painless-software” → https://galaxy.ansible.com/ui/standalone/namespaces/5371/ (incorrect namespace, correct icon)
  • Namespace for Roles, “painless” → https://galaxy.ansible.com/ui/standalone/namespaces/9580/ (correct namespace, incorrect icon → looks like GitHub user “painless”)
  • Namespace for Collections, “painless-software” → https://galaxy.ansible.com/ui/namespaces/painless-software/ (404 Not Found → which is correct)
  • Namespace for Collections, “painless” → https://galaxy.ansible.com/ui/namespaces/painless/ (correct namespace, correct icon)

Sorry for the plain URLs; as a new user I’m not allowed to have more than 2 URLs in a post.

Also, as a consequence, my users cannot install the painless.software role anymore; it must now be called painless-software.software for the installation to succeed: :bomb:

$ ansible-galaxy install painless.software
Starting galaxy role install process
- downloading role 'software', owned by painless
- downloading role from https://github.com/painless/ansible-role-software/archive/master.tar.gz
 [ERROR]: failed to download the file: HTTP Error 404: Not Found
[WARNING]: - painless.software was NOT installed successfully.
ERROR! - you can use --ignore-errors to skip failed roles and finish processing the list.

Will this be corrected in an already-planned cleanup task?

Should users report such discrepancies?

3 Likes
2

Similar, if not identical, issue: Namespace issue with new galaxy.ansible.com

1 Like
3

I’d like to suggest to RedHat personnel responsible for Ansible Galaxy to make the link to the source code repository a user-modifiable project setting. Linking it hard to both GitHub as such and a GitHub namespace identical to the Ansible (role) namespace is not practical.

Not with the many exceptions that seem to have been added to the projects, seemingly in a manual fashion (on the legacy Galaxy instance). That said, please don’t make the same mistake - of manual changes while keeping the automatic namespace scheme in place - again on the now-new Galaxy.

1 Like
4

Any feedback when this will be fixed? My users cannot install the painless.software role. At least a timeline would be good. :timer_clock:

5

I have confirmed that the issue being tracked here Loading... and being fixed here github_user should override namespace.name for legacy roles. by jctanner · Pull Request #1923 · ansible/galaxy_ng · GitHub will resolve the painless role installs.

(venv) [jtanner@p1 galaxy_ng.legacy_role_mapping]$ rm -rf ~/.ansible; rm -rf roles; ansible-galaxy role install -p roles -s 'http://localhost:5001' painless.software
Starting galaxy role install process
- downloading role 'software', owned by painless
- downloading role from https://github.com/painless-software/ansible-role-software/archive/master.tar.gz
- extracting painless.software to /home/jtanner/workspace/github/jctanner.redhat/galaxy_ng.legacy_role_mapping/roles/painless.software
- painless.software (master) was installed successfully
1 Like
6

Sounds good, thank you!

Related to that, what about the branch? Why is the new Gelaxy still resolving to master although github_branch: main is defined in meta/main.yml?

7

@bittner good question. I’ll look at that field as well.

8

The PR got merged and deployed. Branches are captured and exposed now, and the github_user and github_repo fields look correct as well as my installation testing for the related roles.

9

Now it works correctly. Thanks for fixing the issue! :+1:

$ ansible-galaxy install painless.software
Starting galaxy role install process
- downloading role 'software', owned by painless
- downloading role from https://github.com/painless-software/ansible-role-software/archive/main.tar.gz
- extracting painless.software to /home/peter/.ansible/roles/painless.software
- painless.software (main) was installed successfully
1 Like
10

While installing the painless.software role now works, there is still data on the new Galaxy that probably shouldn’t be there or is still not correct.

  1. The role painless-software.software should probably be deleted?
  2. The role namespace 9580 shows the logo of the GitHub user “painless”, which the “wrong” GitHub user.
  3. When you click on the painless.software link on the same page it points to the painless-software.software role. That seems odd.

Will this be fixed? - If I’m not wrong I can’t clean this up all by myself.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.