Apologies in advance if this has perhaps already changed, I see there are some forthcoming changes like new role file format, and I haven’t dug into what all has been happening on master just yet. I had a bunch of thoughts brewing about Galaxy and after just seeing an old thread on ansible-project where Michael referred someone here for feedback, I see there are several meaty threads in this archive I should digest before opening my mouth
But… this one smallish thing just came up and I thought I’d fire it off: with roles on Galaxy that have no explicit versions set in the Galaxy system, I can install them with an arbitrary git SHA like neel.rundeck,4b121be158e88. I don’t know if this was an accidental feature or not, but it’s actually awesome with the current state of the Galaxy versioning system. However, that example I just gave doesn’t actually work, ansible-galaxy install balks at it, and it seems that happens with any role that has a version release marked on Galaxy. IMO, if installing an arbitrary SHA already works in some cases, it should always work.
Right now, Galaxy versions scare the hell out of me. I won’t use anything but SHAs. Git tags can be forcefully moved to different commits. I feel that I don’t have solid assurance that code I’m pulling in didn’t change between the time I installed it in local dev and when it gets pulled down to a production control host. Maybe Galaxy safeguards against a tag change, I don’t know, that’s opaque. Maybe a prudent path would be for my team to rsync 3rd-party roles to production. Maybe we should try a workflow with roles_path set to be inside our playbook repo so we track Galaxy installs in source control in their entirety. I wish there was more best practice doc accounting for risk in the current state
But that’s the rant I meant to save for after I read up some more…
For everyone else on the list, just wanted to share that there have been no changes to the role formats in Ansible, rather, we have a new optional way to specify the requirements file.
I generally think roles up on Galaxy should probably have tags rather than SHAs (that’s more friendly) but that the raw git:// protocol stuff should accept a SHA versus a branch/tag as well (and this should already work for raw git).
If Galaxy versions and someone moving a tag scares you, I’d probably recommend backing up what you are refering anyway, as the content could drop off GitHub tomorrow (Galaxy’s not going anywhere but the underlying GitHub could) and you’d want a backup anyway.
For everyone else on the list, just wanted to share that there have been no changes to the role formats in Ansible, rather, we have a new optional way to specify the requirements file.
Yes, I just meant the yaml requirements file, not any changes to roles, apologies for any confusion.
I generally think roles up on Galaxy should probably have tags rather than SHAs (that’s more friendly) but that the raw git:// protocol stuff should accept a SHA versus a branch/tag as well (and this should already work for raw git).
Sure, that’s fair, SHAs are ugly, if effective. Mainly though I was frustrated that in the 1.7 format, SHAs actually do work, but seemingly only if the role has no versions on Galaxy. For instance this is in our roles file and it works fine: smola.java,1b7afc3158284. But the other example I gave before doesn’t, neel.rundeck with a SHA. It’s a concern for me not only because I want to be certain that I’m getting the code I intend, but also because I’ve found people also lag on refreshing tagged versions on Galaxy, they’re often well behind their git master. Anyway, the raw git protocol will provide a solution, as you pointed out. Looking forward to 1.8
If Galaxy versions and someone moving a tag scares you, I’d probably recommend backing up what you are refering anyway, as the content could drop off GitHub tomorrow (Galaxy’s not going anywhere but the underlying GitHub could) and you’d want a backup anyway.
That’s fair too, and organizations with strict policy probably aren’t going to want to pull Galaxy roles direct from the Internet onto production control machines anyway. I just felt that a best practices doc that makes light of this with some workflow suggestions would be nice, and perhaps some kind of security disclosure. If Galaxy records a SHA for versions when they’re first tagged and then raises some kind of error or at least warning if there’s later a mismatch, that would make me feel a lot better, and I’d like to know about that feature transparently from docs.
