I can think a few cases where being able to control local role folder names would make things cleaner. For example: referencing repos with the same name in the end, too long or obscure repo names, etc.
None of this is a blocker that would stop us from using this feature. I am looking forward to having this in the main branch and in a official release.
Perhaps we could make role name an optional third field - so if you do want role_name but not role_version, just leave role_version blank i.e. git+http://git.server/bad-role-name,nice-role-name
The reason for making it the third field is that I don’t want to break existing roles files and I don’t want the parsing for SCM roles to be fundamentally different to the galaxy roles.
I don’t particularly wish this to block the take-up of this pull request, but I’m happy enough to implement it if the above seems a reasonable approach.
Will
Ok, friendly role names now allowed as third field.
Added bonus of installing roles from URLs without SCM (think nexus, artefactory or just e.g. direct bitbucket/github/stash download URLs)
Integration tests and unit tests to demonstrate that these improvements seem to work as expected.
Will
Positional fields could be a problem, we already have a proposal for like 5 of them, and in different cases it’s now seaming like they are in different orders. I think we need to reset here. If we’re proliferating on fields, here is what I propose.
-
(A) continue to support the existing syntax for the galaxy-username, version
-
(B) use a list of YAML hashes for the approved syntax, and update the documentation
-
(C) go down the YAML path if the first non-space character is a “-”
Perhaps it looks roughly like this:
My implementation only uses three fields, in an order that is backward compatible with the existing roles file, and I’m not sure what the other proposed fields would be.
However, I like the YAML idea if only because it would work much more nicely with the dependencies section of meta/main.yml too.
I would prefer not to support a mixed format roles file - how about if the filename ends ‘.yml’ or ‘.yaml’ we treat it as yaml, otherwise use the existing format.
I also don’t particularly propose rewriting what I’ve done so far given that it’s backwards compatible - any change would be to support the yaml notation in addition (which would also be extensible to any of the other proposed fields I’ve forgotten about).
Will
“I also don’t particularly propose rewriting what I’ve done so far given that it’s backwards compatible”
This would be fine with me.
“I would prefer not to support a mixed format roles file - how about if the filename ends ‘.yml’ or ‘.yaml’ we treat it as yaml, otherwise use the existing format.”
+1
This could be applied on top.
This is now working for the roles file in YAML format.
It doesn’t work so well for role dependencies - we’d probably need to declare some special variables for that.
At the moment the YAML file format is
- src: “git+http://git.example.com/repos/horrible-role-name”
name: “nice-role-name”
version: v1.0
You can also use scm: git (or hg) instead of the git+ / hg+ - the end result is the same.
For this to work with role dependencies it would need to be obvious what are role_vars and what are settings for installing dependencies (perhaps prepend role_install to distinguish the two? - I haven’t implemented this at all, figure I should gather thoughts on requirements first.
Something like
dependencies:
- { role: friendly_role_name,
this_is_a_role_variable: x,
role_install_src: “git+http://url”,
role_install_version: v1.0 }
I’d follow pip’s example here, PyPi understands dependencies, which is the galaxy analog.
Outside of that, there are no deps (right?)
"dependencies:
- { role: friendly_role_name,
this_is_a_role_variable: x,
role_install_src: “git+http://url”,
role_install_version: v1.0 }"
I’m not understanding this part, currently in meta.yml it’s not required for anything like “this_is_a_role_variable” to be defined. I also think all that would be required is whether to install dependencies, i.e. a simple boolean
- role: username.rolename
dependencies: True # can set to False for galaxy roles, non-galaxy roles this is always off and cannot be controlled.
etc?
Then it should assume to fetch them from galaxy, because there is no other index of role deps.
I’m not sure pip has the same problem, which is effectively that dependency declarations are useful at both install time and at run time
In the below example ‘this_is_a_role_variable’ is a variable that gets passed to the role when it is run (and dependencies are run before the role itself is run, as explained in the Roles Dependencies section in the docs) rather than a variable used at installation time. The other parameters are all used for installation only.
Currently dependencies are installed through a similar installation mechanism as the roles file - so if when installing a role from the roles file, it comes across a dependency, it can install that too. So a non-galaxy role dependency can be specified using:
dependencies:
- role: “git+http://git.example.com/reponame.git,v1.0,friendlyname”
My question is whether the dict equivalent example I gave that you quote below should also work - but then there might be confusion between which parameters are role runtime variables and which are installationtime variables (although using a prefix like role_install_ should reduce the likelihood of clashes)
But if you’re saying that users have to manage their own dependencies when using non galaxy roles, then perhaps I need do no more - hopefully my solution works for installing non galaxy dependencies through the roles dependencies mechanism.
Apologies if it’s still no clearer.
Will
My question is whether the dict equivalent example I gave that you quote below should also work - but then there might be confusion between which parameters are role runtime variables and which are installationtime variables (although using a prefix like role_install_ should reduce the likelihood of clashes)
I think that it should work. As I posted earlier I am trying to manage internal roles that are not shared through Ansible Galaxy and I need to be able to specify internal role dependencies. BTW, currently, there is a hack that I found but I would prefer to not use:
dependencies:
- src: https://git.example.com/repos/horrible-role-name.git
scm: git
name: role-friendly-name
role: role-friendly-name
this-is-a-variable: x
Are the results of this thread available in a release yet?
I tried a few of the suggestions from this thread but none worked, not even the one listed in the documentation
http://docs.ansible.com/playbooks_roles.html
cat meta.yml
dependencies:
- { role: ‘git+https://github.com/geerlingguy/ansible-role-elasticsearch-curator’ }
(master)] ansible-playbook -i hosts site.yml -vvvv
ERROR: cannot find role in … /etc/ansible/roles/git+http:/github.com/geerlingguy/ansible-role-elasticsearch-curator
Is it not in trunk or am i missing something in .ansible.cfg?
(master)] ansible --version
ansible 1.8.2
configured module search path = None
Hi folks,
I haven’t had to use this stuff in a while, but I’ve had a new look at this.
Whatever the documents say, one way that works is:
dependencies:
- git+https://github.com/geerlingguy/ansible-role-elasticsearch-curator,optionalversion,optionalfriendlyname
There were some changes made in October 2014 that would have broken Ivalyo’s suggestion. (See https://github.com/ansible/ansible/issues/9173 and the associated fix).
Will