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