Role and playbook versioning

[Will Thames]

Working in an environment where we hope to reuse common playbooks and roles across the organisation, I've been thinking a lot on how to manage updates to roles and playbooks without breaking repeatability (running the same playbook against the same environment should have the same result, even if the two runs are separated by months).

My current strategy and some of the techniques that I use to augment that is described at
http://willthames.github.io/2014/08/11/techniques-for-versioning-ansible.html

and I plan to add some more rules for ansible-lint to allow checking that roles fit the techniques (I'm not sure even whether to publish the rules, but they certainly won't be core rules as they may well be entirely specific to my environment)

Anyway thoughts are welcome on whether there are better ways to do it! (Particularly if there's a pure DVCS way that achieves a similar outcome)

Will

[Michael DeHaan]

So, let's not go down that lint-discussion road again.  We know where it leads.

Rather, let's once again discuss how we can improve roles to do what we need.

As for role versioning, there have been a few who have liked the things that chef did with their library tool (I haven't used it), and we've posted quite a few times that we're open to making the ansible-galaxy CLI work better with raw SCM repos as well as versioning deps.

There's also been the suggestion that ansible have a tag to assert the required ansible version, or perhaps it's a module.

All of this seems like a good thing to do.

I don't particularly care for the idea of requiring a version in the role name, as that breaks the ability to cleanly branch the role in Galaxy, which is handled via git tags presently.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/100fd0dc-c083-4bd3-8e9f-dce0cb2c9b18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Thames]

I know your thoughts on ansible-lint - that the behaviour should be integrated into core. But my pull request to do something along those lines has been open for 8 months https://github.com/ansible/ansible/pull/5123

ansible-lint provides a way of enforcing locally applicable standards - for example, we use it to warn against using Ansible as a build tool, among other things.

Anyway, to focus on the main points you make.

My understanding is that ansible galaxy role versions matter at install time. I guess that means that each playbook installs the roles locally. This means that the problem of using one role version for uat and one role version for prod is not necessarily solved is it?

I assume there are existing discussions on using repos other than github - I'll have to look into this. I'm definitely keen to avoid reinventing any wheels if I can.

To be clear, I'm not particularly concerned about the versioning of Ansible itself, just that the same playbook can reference different roles.

Will

[Michael DeHaan]

On Mon, Aug 11, 2014 at 8:31 PM, Will Thames <wi...@thames.id.au> wrote:

I know your thoughts on ansible-lint - that the behaviour should be integrated into core. But my pull request to do something along those lines has been open for 8 months https://github.com/ansible/ansible/pull/5123

I think it's no-secret that we've had a large queue lately. 

A lot of our prioritzation has been around hardening of core functionality, and also keeping with EC2 and other hoping things moving.    This is still interesting to me just not something our heuristics have bubbled to the top.

Part of the problem is having absolutely ridiculous levels of contribution at this point, which we are thankful for.

Anyway, to focus on the main points you make.

My understanding is that ansible galaxy role versions matter at install time. I guess that means that each playbook installs the roles locally. This means that the problem of using one role version for uat and one role version for prod is not necessarily solved is it?

playbooks don't actually install the roles, but ansible-galaxy CLI calls do.

In the ansible-galaxy requirements file you can in fact say

username.rolename,v1.00

username.rolename2,v1.05

And if you had them so configured to check out in locations (ideally using a different role path for each) that would be easy to do.  You might also have an ansible.cfg that selects this rolepath and also adds it to .gitignore

One of the things missing though is the ability to (right now) specify git:// and ssh:// git locations so it doesn't just have to download from Ansible galaxy proper.

I think we're also open to new formats for the requirements file if needed, as long as it can continue to support the old format.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/d9177e20-4009-40fd-8217-d7a2bacc9732%40googlegroups.com.

[Will Thames]

How does
https://github.com/ansible/ansible/pull/8600
look for URL based roles?

I think I can make good use of this - I'll have to rethink our workflow but the final result should be better and meet my requirements. Hopefully I'll have a new blog post and I'll mark the old one as deprecated.

Will

[Michael DeHaan]

Yeah this is about what I was thinking?

Can I ask how it determines if something is hg or git:// for a https:// URL?

Maybe we need do syntaxes like git+https:// and git+ssh://, etc?

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/8173919e-8948-4840-a58a-930bccb9259d%40googlegroups.com.

[Will Thames]

It tries a git ls-remote and an hg identify and then uses whichever  succeeds.

Will

You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/TawjChwaV08/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzFdWQS_H5PE1ijN4UAHsfUA5Foc%2BFzQ2hZa93twyw8tA%40mail.gmail.com.

[Sam Doran]

I would love to have this functionality added to ansible-galaxy. I'm currently using librarian-ansible because it allows me to specify my own git repos for sourcing roles. I don't care for how heavy-handed librarian-ansible is, though: each time I run any librarian-ansible command it wipes out all changes in the librarian_roles directory, causing all my customizations to be lost. I much prefer the behavior of ansible-galaxy but can't use it because I host my roles on a private git repository.

One thing I do like very much about librarian-ansible is the syntax/capability of the Ansiblefile:

# This will pull a role using the Ansible Galaxy API
role "kunik.deploy-upstart-scripts"

# This allows me to specify my own git repository as a source as well as a version number
role "disa-stig-rhel6", git: "g...@git.acme.com:ansible/role-disa-stig-rhel6.git", "1.0"

# I can also point to github repos
role "role "pgolm.ansible-playbook-monit", github: "pgolm/ansible-playbook-monit"

There are philosophical differences in how the two tools operate as well. With librarian-ansible, you are not meant to ever customize roles under the control of librarian-ansible. This makes keeping the roles up to date rather easy but customizing them is not recommended since any changes will be lost (unless you copy the role out of the librarian_roles folder, essentially forking the role).

ansible-galaxy, on the other hand, lends itself more to using shared roles as a starting point and not as an ongoing source of truth. I could be using ansible-galaxy wrong, but that's how I see it (or maybe it's flexible enough to be used either way). I run ansible-galaxy once to get the role, then customize it to my liking. Running ansible-galaxy again does not overwrite any customizations I have made to the role, which is much friendlier and more in line with how I like to use the tool.

[Michael DeHaan]

Good intentions aside, that librarian project should not needed to be created - there's somewhat of a tragedy of the commons effect from github where not everyone joins the lists and knows about the work we are all trying to build here, coupled with a bit of a simple name problem that led people to assume ansible-galaxy was only for galaxy.ansible.com, when that wasn't the case - it's really the role tool for the whole "galaxy" of ansible modules, or whatever.

Ansible's always been a "batteries included" kind of ecosystem, where we want everybody to collaborate on shared tooling, rather than have 5 ecosystem projects spring up that all work differently, and lack the critical mass.

It's the same reason we have the 235-ish modules in core, rather than the 40-60 of some other projects - so you have to hunt less around distributed projects and find that some do some things and others do other things.

I particularly don't like how that tool creates another syntax for describing things, worse yet one that looks like Ruby in a system of software where that doesn't /quite/ make sense, but it also didn't quite make sense that a simple list of roles needed to be in YAML just yet either.

So it may be in the future we support both a YAML format and the existing string format, TBD.

In any event, I regret that no list discussion occured when that tool came onto the scene, as I think a lot of those contributions could have been funneled into the shared project.

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/cc0614f4-4d5a-4f74-97d3-42de785bc445%40googlegroups.com.

[Michael DeHaan]

That seems reasonable, especially if skipping hg/git if not installed, though I'm guessing that's maybe *not* as easy for ssh:// git?

Just trying to think aloud whether specifying the protocol is a good idea.  I'm thinking it might be, and it would save some network activity on long resource lists as well.

What about:

for basic files:

rolename,version # implies galaxy

rolename,version,scm,source

??

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAGmGhM3AKe9JCOwnNZytgvA-rVjU0KW7E9G6e67c7wsdRgWYDw%40mail.gmail.com.

[Sam Doran]

I agree with you completely. I don't particularly like using librarian-ansible but it's all I have at the moment. I really just want to be able to specify custom sources using ansible-galaxy. 

The syntax is indeed Ruby because librarian-ansible is written in Ruby. What I was trying to explain, which I don't think I did very well, was that the ability to be explicit rather than implicit in specifying role sources is what I like best about the configuration file. I have no affection of the exact syntax used.

Will's PR uses logic in the code to determine the type of remote server: I just prefer to be more explicit rather than relying on the program to figure it out. But that's my preference and could easily be argued either way.

[Michael DeHaan]

"The syntax is indeed Ruby because librarian-ansible is written in Ruby."

Yeah, that didn't make sense to me at all either.

I'm not sure what features people need out of the tool, but it would be easier for us to talk about what tools ansible-galaxy needs here, rather than referencing the tools i n the Chef ecosystem I'm unfamiliar with.

(Also see previous comment on being explicit, I think that's what we should do...but I like where this is going)

We can keep simple syntax for now and move on from there if needed (and if so, supporting both as best we can).  Might not be needed.

Our initial goal was to make something more or less like a pip requirements file, something pretty basic.

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e9ac3279-cd16-4515-bbd0-92afb1a788fe%40googlegroups.com.

[Sam Doran]

I like your syntax suggestion. That seems to fit more with the ansible project. I agree that specifying the protocol would be a good idea.

Here's what it might look like:

# Galaxy roles
adham.helal.authentication
agios.nginx-unicorn,1.3

# Custom roles using various protocols

disa-stig-rhel6,git,ssh://g...@git.acme.com:ansible/role-disa-stig-rhel6.git,1.0

kibana,git,https://git.acme.com:ansible/role-kibana.git

logstash,git,git://g...@git.acme.com:ansible/role-logstash.git

[Michael DeHaan]

+1

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/2946b30e-e772-44af-9592-f0fec3f8da30%40googlegroups.com.

[Will Thames]

I'm happy enough with this approach but how do we apply that to role dependencies.

In my git test role I provide a git dependency:
https://bitbucket.org/willthames/git-ansible-galaxy/src/1e58ef87f234926caaf5e6b1f2c5378d90f476b1/meta/main.yml?at=master

This works with the ansible-galaxy in the pull request but would not as it stands without some form of scm detection.

On reflection, I think I'd be happiest with the scm+url suggestion - this would eliminate the need for scm detection and keep the role_name/url, role_version format of the rolesfile
role_name would continue to be derived from the repo name.

From Sam's example, this would then look more like this (not 100% happy with git+git but it's nicer than handling the special case).

# Custom roles using various protocols

git+ssh://git@git.acme.com:ansible/role-disa-stig-rhel6.git,1.0

git+https://git.acme.com/ansible/role-kibana.git

git+git://git@git.acme.com:ansible/role-logstash.git

This would end up with roles called e.g. role-logstash, which might not be what you want, but I would prefer to keep the rolesfile simple.

Will

On Thursday, August 14, 2014 12:59:43 AM UTC+10, Michael DeHaan wrote:

+1

On Wed, Aug 13, 2014 at 10:57 AM, Sam Doran <sam....@me.com> wrote:

I like your syntax suggestion. That seems to fit more with the ansible project. I agree that specifying the protocol would be a good idea.

Here's what it might look like:

# Galaxy roles
adham.helal.authentication
agios.nginx-unicorn,1.3

# Custom roles using various protocols

disa-stig-rhel6,git,ssh://git@git.acme.com:ansible/role-disa-stig-rhel6.git,1.0

kibana,git,https://git.acme.com:ansible/role-kibana.git

logstash,git,git://git@git.acme.com:ansible/role-logstash.git

[Ivaylo Bratoev]

Hi guys,

I am currently investigating different options for managing roles and looking forward to having this in Ansible itself. My requirements are similar - having roles shared (and versioned) in private git repos, referenced from playbooks in other repos.
The solution you are discussing here sounds like in the right direction. I would just add one more requirement - being able to overwrite the role-name and rely on the git repo name exclusively. Idea for syntax if you want to keep the role_name/url, role_version format:

git+https://git.acme.com/ansible/role-logstash.git#alias=logstash

This would reference the role from the private repo but use the name 'logstash' instead of 'role-logstash'.

If you are OK to change the format to role_name, scm, url the syntax suggested by Sam would work well for us:

logstash,git,https://git.acme.com/ansible/role-logstash.git

Ivo

On Thursday, August 14, 2014 3:37:03 AM UTC+3, Will Thames wrote:

I'm happy enough with this approach but how do we apply that to role dependencies.

In my git test role I provide a git dependency:
https://bitbucket.org/willthames/git-ansible-galaxy/src/1e58ef87f234926caaf5e6b1f2c5378d90f476b1/meta/main.yml?at=master

This works with the ansible-galaxy in the pull request but would not as it stands without some form of scm detection.

On reflection, I think I'd be happiest with the scm+url suggestion - this would eliminate the need for scm detection and keep the role_name/url, role_version format of the rolesfile
role_name would continue to be derived from the repo name.

From Sam's example, this would then look more like this (not 100% happy with git+git but it's nicer than handling the special case).

# Custom roles using various protocols

git+ssh://g...@git.acme.com:ansible/role-disa-stig-rhel6.git,1.0

git+https://git.acme.com/ansible/role-kibana.git

git+git://g...@git.acme.com:ansible/role-logstash.git

[Will Thames]

Also, what is the intended mechanism for pinning versions in dependencies in meta/main.yml?

dependencies:

- git+http://git.example.com/repos/role-abc,v1.0

There’s probably some work to trim the .git off the role_name too (I just don’t bother putting the .git in the repo url but maybe not all git servers cope with that)

On 14 Aug 2014, at 10:37, Will Thames <wi...@thames.id.au> wrote:

I'm happy enough with this approach but how do we apply that to role dependencies.

In my git test role I provide a git dependency:
https://bitbucket.org/willthames/git-ansible-galaxy/src/1e58ef87f234926caaf5e6b1f2c5378d90f476b1/meta/main.yml?at=master

This works with the ansible-galaxy in the pull request but would not as it stands without some form of scm detection.

On reflection, I think I'd be happiest with the scm+url suggestion - this would eliminate the need for scm detection and keep the role_name/url, role_version format of the rolesfile
role_name would continue to be derived from the repo name.

From Sam's example, this would then look more like this (not 100% happy with git+git but it's nicer than handling the special case).

# Custom roles using various protocols

git+ssh://git@git.acme.com:ansible/role-disa-stig-rhel6.git,1.0

git+https://git.acme.com/ansible/role-kibana.git

git+git://git@git.acme.com:ansible/role-logstash.git

This would end up with roles called e.g. role-logstash, which might not be what you want, but I would prefer to keep the rolesfile simple.

Will

On Thursday, August 14, 2014 12:59:43 AM UTC+10, Michael DeHaan wrote:

+1

On Wed, Aug 13, 2014 at 10:57 AM, Sam Doran <sam....@me.com> wrote:

I like your syntax suggestion. That seems to fit more with the ansible project. I agree that specifying the protocol would be a good idea.

Here's what it might look like:

# Galaxy roles
adham.helal.authentication
agios.nginx-unicorn,1.3

# Custom roles using various protocols


disa-stig-rhel6,git,ssh://git@git.acme.com:ansible/role-disa-stig-rhel6.git,1.0kibana,git,https://git.acme.com:ansible/role-kibana.gitlogstash,git,git://git@git.acme.com:ansible/role-logstash.git

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/2946b30e-e772-44af-9592-f0fec3f8da30%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/TawjChwaV08/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e3e48247-98bb-44db-912c-ca953b624c04%40googlegroups.com.

[Will Thames]

I’ve solved the trimming the .git off the end and also the ability to specify role_version in meta/main.yml

It doesn’t work with an upgrade of a dependency because the check is currently for if the role exists, not if it’s a particular version. 

I’ve added an integration test for all of this too - so I know ansible-galaxy and ansible-playbook work with the changes against SCM roles but not if the changes break existing roles inside or outside of galaxy - be good to get some additional testing around this.

Will

[Michael DeHaan]

Yeah I think the above syntax, and also in dependencies, would be fine.

Dependency downloads are all in the ansible-galaxy CLI, so I think that would cover everything.    We would just need the core change that would get the role name out correctly too.

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/551E689E-2833-4AE3-999A-FFFB0F005E21%40thames.id.au.

[Michael DeHaan]

" would just add one more requirement - being able to overwrite the role-name and rely on the git repo name exclusively. Idea for syntax if you want to keep the role_name/url, role_version format:"

While interesting, we don't want to do this because we already have ",version" used for describing roles in a way that  is not specific.  Further, I don't think those URLs technically support comments in the case of ssh://, so that seems like something we'd want to avoid.

We can go with git+https://url,version

I'm happy with that.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/af2e9ef3-19e1-4379-a6b8-439936841e7d%40googlegroups.com.

[Ivaylo Bratoev]

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.

[Will Thames]

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

[Will Thames]

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

[Michael DeHaan]

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:

----

- repo: git+ssh://

  role_name: blippy

  version: ...

- galaxy: username.rolename

  recursive: false

- galaxy: username.rolename2

  version: 1.2.3

- galaxy: username.rolename_is_terrible

  role_name: save_as_this

??

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/0520bf55-0dc0-4a3b-9c27-5d15da78a289%40googlegroups.com.

[Will Thames]

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

Ivo

+1

disa-stig-rhel6,git,ssh://git@git.acme.com:ansible/role-disa-stig-rhel6.git,1.0kibana,git,https://git.acme.com:ansible/role-kibana.git logstash,git,git://git@git.acme.com:ansible/role-logstash.git

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/2946b30e-e772-44af-9592-f0fec3f8da30%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/af2e9ef3-19e1-4379-a6b8-439936841e7d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/0520bf55-0dc0-4a3b-9c27-5d15da78a289%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/TawjChwaV08/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxP4WCqUf4MbhytOO-A%3DfiTnn8Dtz%2BHUhxJ3RD%2BTNQB5Q%40mail.gmail.com.

[Michael DeHaan]

"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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/B9D82A46-0916-4747-8323-5A9309F12251%40thames.id.au.

[Will Thames]

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 }

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxsMac6wEVHNVHTZimWaZVCR93rX0eO8qdVJgsiEUxznQ%40mail.gmail.com.

[Michael DeHaan]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/4DEBED3F-10A0-401F-B067-749AA58CA13B%40thames.id.au.

[Will Thames]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgysLnzHtfENrdCRYBRnBzK6HsU2brNrxFBLQECGP0cV8w%40mail.gmail.com.