Roles namespace has changed with the new Galaxy website

[btravouillon (Bruno Travouillon)]

I was used to file issues on GitHub ansible/galaxy projects, but from New Ansible Galaxy - #12 it looks like issues should be opened here now.

I tried to copy the content of the report Roles namespace has changed with the new Galaxy website · Issue #3253 · ansible/galaxy · GitHub here, but new users are not allowed to post more than 2 URLs. Given the issue is with a website, it makes it difficule to explain.

SUMMARY

Our namespace mila was created in [#2792].

Since then, people are using mila.<collection_name> and mila.<role_name> to install our roles and collections.

---
roles:
  - name: mila.bareos
    version: 1.5.0

  - name: mila.cobbler
    version: v0.2.2

  - name: mila.cobbler
    version: v0.3.3

collections:
  - name: mila.proxmox
    version: 0.5.2

Previously, we were able to see our published content with a single URL.

Today, there are three URLs, one for the collections and two others for the roles.

STEPS TO REPRODUCE

Search for “clockwork” in the roles : this will return two results with the same content. If you enter the official role and click on Github Repository, you’ll get a 404.

EXPECTED RESULTS

I expect to see all the published content (roles and collections) in the same page.

If that’s not possible with the NG version, I would at least expect to get a coherent namespace which is mila.

[gwmngilfen (Greg Sutcliffe)]

@btravouillon

looks like issues should be opened here now.

You are correct! Thanks for the detailed output - I know the Galaxy team are triaging and working through the issues as fast as they can.

[btravouillon (Bruno Travouillon)]

Hi,

Is there any update on this issue?

[tannerjc (James Tanner)]

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 issues with the mila 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' mila.clockwork 
Starting galaxy role install process
- downloading role 'clockwork', owned by mila
- downloading role from https://github.com/mila-iqia/ansible-role-clockwork/archive/v0.9.4.tar.gz
- extracting mila.clockwork to /home/jtanner/workspace/github/jctanner.redhat/galaxy_ng.legacy_role_mapping/roles/mila.clockwork
- mila.clockwork (v0.9.4) was installed successfully

[btravouillon (Bruno Travouillon)]

Alright, it seems better today. The erroneous role namespace is now empty. I guess this will be deleted in a near future.

The only issue left is the avatar used in our role namespace which is not our logo but the profile picture of GitHub user mila. (which would be a real issue to me if my own face picture was uploaded to a third-party website without my consent)

[tannerjc (James Tanner)]

The only issue left is the avatar used in our role namespace which is not our logo but the profile picture of GitHub user mila.

This is one of challenges of having a namespace on galaxy that matches some other user on github. We should never have created a namespace with that conflict considering the user has been on github since 2009 https://api.github.com/users/mila and the namespace request was made in 2021.

The reason you are seeing mila’s avatar instead of something else is due to this piece of the new code: https://github.com/ansible/galaxy_ng/blob/master/galaxy_ng/app/api/v1/serializers.py#L74-L76

    def get_avatar_url(self, obj):
        url = f'https://github.com/{obj.name}.png'
        return url

We generate a url at request time that naively uses the namespace name, or in your case “mila”'s. What we need to do instead is use the url that comes from the provider namespace attached to the v1/legacy/standalone namespace here

I have an open jira to track that bug here. We’ll try to take care of it early next week.

[lkiesow (Lars Kiesow)]

@tannerjc

This is one of challenges of having a namespace on galaxy that matches some other user on github. We should never have created a namespace with that conflict considering the user has been on github since 2009 https://api.github.com/users/mila and the namespace request was made in 2021.

But even then, this would have become an issue as soon as someone registered that user on GitHub. So, checking before creating a namespace would have been by no means a guarantee that there is no conflict.

Previously, namespaces did always override GitHub users. And namespaces would only be created if a GitHub user hadn’t already claimed that name. There was no conflict. Whoever claimed a name on Galaxy first owned it.

This changed only with the new version of Galaxy. Saying that the specific namespace name was always problematic isn’t really fair. It was just fine with the old system. It only became a problem now.

Sorry if my frustration is bleeding through…
For us this change just was very surprising and caused quite a bit of a headache for many people. Contacting namespace owner in advance and letting them know would have been great. Even now, I’m still not quite sure what the status of the old(?) namespaces will be in the future. Will we still be able to use them? Can we continue to use them to combine roles from different GitHub organizations? The UI for this seems to be completely gone?

[tannerjc (James Tanner)]

But even then, this would have become an issue as soon as someone registered that user on GitHub. So, checking before creating a namespace would have been by no means a guarantee that there is no conflict.

I agree. The only way to be certain the namespace had no conflicts would be for the role author to secure the user or org on github first.

Previously, namespaces did always override GitHub users. And namespaces would only be created if a GitHub user hadn’t already claimed that name. There was no conflict. Whoever claimed a name on Galaxy first owned it.

Yes, I agree that was the case. We haven’t eliminated that behavior in new galaxy, but I feel that we shouldn’t continue to encourage it. What I’d personally like is to make custom namespace creation a self-service option within the UI, but we have to figure out what constraints to put on that to reduce “domain squatting” and other conflicts of interest. I’m open to suggestions on the best way to implement and constrain this as a feature.

This changed only with the new version of Galaxy. Saying that the specific namespace name was always problematic isn’t really fair. It was just fine with the old system. It only became a problem now.

I agree it wasn’t an obvious user facing problem previously, but it was a problem with self-service. Knowing to go to github to file an issue to ask for a custom namespace was a barrier to entry that most people wouldn’t know how to get around. For the backend admins, it was additional triage and work to process and fulfill those requests.

Sorry if my frustration is bleeding through… For us this change just was very surprising and caused quite a bit of a headache for many people. Contacting namespace owner in advance and letting them know would have been great.

It’s okay to be frustrated and I understand. We did our best to limit the frustration with the feature set we had time to deliver by the deadline and have been working around the clock to fix and re-add what we can. The whole team and organization has been taking all the feedback on this forum and coding as fast as possible to implement what is actionable.

Even now, I’m still not quite sure what the status of the old(?) namespaces will be in the future. Will we still be able to use them?

It’s “grandfathered” in at this point, so it’s not going away unless you or another authorized user for the namespace decide to delete it.

Can we continue to use them to combine roles from different GitHub organizations?

I’m not sure I fully understand what you are asking. Are you wanting to know if you’ll always be able to import into a namespace from an arbitrary / unmatched github_user value? If so, yes the current roles as is should continue to map into the right place. New roles though are a challenge because we don’t have a way to override the namespace at import time via the CLI or the API. I think we need to take that on as a feature request and get it done soon. I’ve noticed people have been putting a “namespace” field in their role’s meta/main.yml (maybe because of ansible-lint’s suggestion?), and I’m thinking that might be a good way to facilitate the destination namespace for an import without altering the REST api signatures or the CLI arguments.

The UI for this seems to be completely gone?

If that’s in reference to importing direct to a namespace, then yes it’s gone (for now). We’re rebuilding the foundations in the API and UI that should make this possible again in the future.

[tannerjc (James Tanner)]

I think this issue as originally described is resolved. We also have ways to make uploads to various namespaces much easier now.

Ansible Galaxy’s role import enhancements and fixes for the new year

Ansible Galaxy’s role import enhancements and fixes for the new year. Import logging … Remember when you could see a nice formatted list of messages when your roles were imported? We’ve brought that back (see Role import logging by jctanner · Pull Request #1959 · ansible/galaxy_ng · GitHub)! You may have already noticed, but when you run “ansible-galaxy role import” it displays colorized messages about what the backend is doing with the role (where it’s cloning from, what lint tests pass or fa…