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 ?? On Wed, Aug 13, 2014 at 9:29 AM, Will Thames <[email protected]> wrote: > It tries a git ls-remote and an hg identify and then uses whichever > succeeds. > > Will > On 13/08/2014 11:19 pm, "Michael DeHaan" <[email protected]> wrote: > >> 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? >> >> >> >> >> On Wed, Aug 13, 2014 at 8:57 AM, Will Thames <[email protected]> wrote: >> >>> 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 >>> >>> On Wednesday, August 13, 2014 5:04:52 AM UTC+10, Michael DeHaan wrote: >>>> >>>> >>>> >>>> >>>> On Mon, Aug 11, 2014 at 8:31 PM, Will Thames <[email protected]> >>>> 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. >>>> >>>> >>>>> >>>>> 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 >>>>> >>>>> >>>>> On Monday, August 11, 2014 11:02:34 PM UTC+10, Michael DeHaan wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 11, 2014 at 8:45 AM, Will Thames <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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-versio >>>>>>> ning-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 >>>>>>> >>>>>>> -- >>>>>>> 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/100fd0dc- >>>>>>> c083-4bd3-8e9f-dce0cb2c9b18%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/ansible-project/100fd0dc-c083-4bd3-8e9f-dce0cb2c9b18%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/d9177e20-4009-40fd-8217- >>>>> d7a2bacc9732%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/ansible-project/d9177e20-4009-40fd-8217-d7a2bacc9732%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/8173919e-8948-4840-a58a-930bccb9259d%40googlegroups.com >>> <https://groups.google.com/d/msgid/ansible-project/8173919e-8948-4840-a58a-930bccb9259d%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%2BnsWgzFdWQS_H5PE1ijN4UAHsfUA5Foc%2BFzQ2hZa93twyw8tA%40mail.gmail.com >> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzFdWQS_H5PE1ijN4UAHsfUA5Foc%2BFzQ2hZa93twyw8tA%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/CAGmGhM3AKe9JCOwnNZytgvA-rVjU0KW7E9G6e67c7wsdRgWYDw%40mail.gmail.com > <https://groups.google.com/d/msgid/ansible-project/CAGmGhM3AKe9JCOwnNZytgvA-rVjU0KW7E9G6e67c7wsdRgWYDw%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/CA%2BnsWgxnzxsbqVFzFUJGBvBn0O7mdZ8PvXdreSw7jFeEbB0CoQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
