> > 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 On Monday, August 18, 2014 3:49:06 PM UTC+3, Will Thames wrote: > 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 > > > > On 18 Aug 2014, at 22:35, Michael DeHaan <[email protected] <javascript:>> > wrote: > > 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. > > > > > On Mon, Aug 18, 2014 at 7:35 AM, Will Thames <[email protected] > <javascript:>> wrote: > >> 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 } >> >> On 17 Aug 2014, at 23:00, Michael DeHaan <[email protected] >> <javascript:>> wrote: >> >> "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. >> >> >> >> >> On Sun, Aug 17, 2014 at 3:21 AM, Will Thames <[email protected] >> <javascript:>> wrote: >> >>> 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 >>> >>> On 17 Aug 2014, at 00:52, Michael DeHaan <[email protected] >>> <javascript:>> wrote: >>> >>> 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 >>> >>> ?? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Aug 15, 2014 at 8:07 AM, Will Thames <[email protected] >>> <javascript:>> wrote: >>> >>>> 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 >>>> >>>> >>>> On Friday, August 15, 2014 10:22:44 AM UTC+10, Will Thames wrote: >>>> >>>>> 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 >>>>> >>>>> On Friday, August 15, 2014 3:03:36 AM UTC+10, Ivaylo Bratoev wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> On Thursday, August 14, 2014 3:10:29 PM UTC+3, Michael DeHaan wrote: >>>>>> >>>>>>> " 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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 14, 2014 at 12:17 AM, Ivaylo Bratoev < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> 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/1e58 >>>>>>>>> ef87f234926caaf5e6b1f2c5378d90f476b1/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://[email protected]:ansible/role-disa-stig-rhel6.git,1.0 >>>>>>>>> git+https://git.acme.com/ansible/role-kibana.git >>>>>>>>> git+git://[email protected]: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 <[email protected]> >>>>>>>>>> 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://[email protected]:ansible/role-disa >>>>>>>>>>> -stig-rhel6.git,1.0kibana,git,https://git.acme.com:ansible/role-kibana.git >>>>>>>>>>> >>>>>>>>>>> logstash,git,git://[email protected]: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 [email protected]. >>>>>>>>>>> To post to this group, send email to [email protected] >>>>>>>>>>> . >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/msgid/ansible-project/2946b30e- >>>>>>>>>>> e772-44af-9592-f0fec3f8da30%40googlegroups.com >>>>>>>>>>> <https://groups.google.com/d/msgid/ansible-project/2946b30e-e772-44af-9592-f0fec3f8da30%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> 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 [email protected]. >>>>>>>> To post to this group, send email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/ansible-project/ >>>>>>>> af2e9ef3-19e1-4379-a6b8-439936841e7d%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/ansible-project/af2e9ef3-19e1-4379-a6b8-439936841e7d%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>>> 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 [email protected] <javascript:>. >>>> To post to this group, send email to [email protected] >>>> <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/ansible-project/0520bf55-0dc0-4a3b-9c27-5d15da78a289%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/ansible-project/0520bf55-0dc0-4a3b-9c27-5d15da78a289%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> 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 >>> [email protected] <javascript:>. >>> >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> 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 >>> >>> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxP4WCqUf4MbhytOO-A%3DfiTnn8Dtz%2BHUhxJ3RD%2BTNQB5Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> 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 [email protected] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ansible-project/B9D82A46-0916-4747-8323-5A9309F12251%40thames.id.au >>> >>> <https://groups.google.com/d/msgid/ansible-project/B9D82A46-0916-4747-8323-5A9309F12251%40thames.id.au?utm_medium=email&utm_source=footer> >>> . >>> >>> 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 >> [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxsMac6wEVHNVHTZimWaZVCR93rX0eO8qdVJgsiEUxznQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxsMac6wEVHNVHTZimWaZVCR93rX0eO8qdVJgsiEUxznQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/4DEBED3F-10A0-401F-B067-749AA58CA13B%40thames.id.au >> >> <https://groups.google.com/d/msgid/ansible-project/4DEBED3F-10A0-401F-B067-749AA58CA13B%40thames.id.au?utm_medium=email&utm_source=footer> >> . >> >> 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 > [email protected] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgysLnzHtfENrdCRYBRnBzK6HsU2brNrxFBLQECGP0cV8w%40mail.gmail.com > > <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgysLnzHtfENrdCRYBRnBzK6HsU2brNrxFBLQECGP0cV8w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e8d48d23-2681-428c-90ca-ba9a1b6b0a86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
