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]> 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]> 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]> 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]> 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]> 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].
>>> 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/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].
>>
>> 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/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].
>> 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/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].
> 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/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].
> 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/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 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/CA%2BnsWgysLnzHtfENrdCRYBRnBzK6HsU2brNrxFBLQECGP0cV8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
