Bad request on collection publish

[debben]

Hello,

I'm trying to get up and running with galactory. I'm able to get the code running locally. When I try the following test though:

ansible-galaxy collection init debben.helloworld
ansible-galaxy collection build debben/helloworld
ansible-galaxy collection publish -s http://127.0.0.1:8888 debben-helloworld-1.0.0.tar.gz

I get a 400 back from galactory. When I set a breakpoint within galactory source, the failure seems to be coming from here:
https://github.com/briantist/galactory/blob/main/galactory/api/v2/collections.py#L176

Where request.files['file'] is empty. Is there any limitations on the ansible-galaxy version or a better way to inspect how the request is being parsed? I've not had much experience with python+flask+werkzeug but I'm hoping this issue is just some bug resolved by updating a dependency.

[debben]

I ended up finding that werkzeug is at the latest version and after digging pretty deep in it's source, it seemed like what was being sent over by ansible-galaxy wasn't parsing right by werkzeug. My ansible-core version was 2.9.6. Upgrading to 2.13.10 seemed to change how the response body was constructed such that galactory didn't error on publihs.

[briantist]

Hi @debben , I see you were able to get working with a newer version of ansible-core. 2.9.6 is incredibly old even for 2.9 (which itself is long EoL). If you must use 2.9, try newer version of it, I think the last one is something like 2.9.26.

But in general, I will probably be looking to support more modern versions of core. Keeping in mind mind that core doesn't use semver, and that the first two components combined are major versions, 2.9 is 6 major versions behind the current latest, 2.15.

In places that still need to use 2.9, I've also seen limited success with using a newer version of ansible-core installed in a virtual environment (python venv) and using that only to run ansible-galaxy commands while they use their existing environment for 2.9.

---

Other than that, I'd love to hear more about your experience with galactory , how you're using it, any feedback you might have. Thanks!

[debben]

So far so good. I'm in need of roles support though so I'm trying to gauge what effort would be needed there. If it would be #23 or if also v1 api would be needed. I'm currently using artifactory generic artifact storage to host .tar.gz of collections and roles and then referencing them as by url. I'm hoping that by using galactory I can take advantage of renovatebot/renovate#19486 once it's ready.

[briantist]

Thanks @debben , I planned from the beginning not to support standalone roles. The overwhelming direction in the community is toward collections, which offer a better package experience for all ansible content, including roles.

If your interest is primarily for roles as internal content, I would recommend putting them in collections and publishing those. If your interest is more about proxying to upstream roles, then I'd suggest setting up your ansible.cfg to point to both your "internal" galactory-based repository for collections, and a second "server" that points directly at galaxy for roles. Or to do installation in separate runs with separate targets.

Although I might consider a PR to add v1/roles support, my inkling at the moment is that I would not, due to the maintenance burden of it vs. the benefit given the direction of the community.

I would recommend we open a separate issue or discussion before you spend significant time on coding.

For me, the biggest problem right now with the whole project has been the difficulty of getting working tests, and if I were to consider role support it would have to be with test coverage and support, something that's very difficult now because I'm lacking it even for the rest of the project (which is on me).

If you want to continue talking about it, let's do so via a discussion so that it can be an ongoing conversation and others in the community can weigh in.

Thanks very much for your feedback I appreciate it a lot!