15:05:52 #startmeeting Ansible Core Public Meeting 15:05:52 Meeting started Thu Jul 7 15:05:52 2016 UTC. The chair is jimi|ansible. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:52 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:05:52 The meeting name has been set to 'ansible_core_public_meeting' 15:05:53 #topic agenda: https://github.com/ansible/community/issues/111 15:05:53 ummm... 15:05:54 zodbot? 15:05:54 ^ gregdek, do we need to kick zodbot? 15:06:06 nm, just my wifi acting up... 15:06:24 Looks like we need to kick your wifi. ;) 15:06:33 * ttom says hi 15:06:41 wifi = basement, office = 3rd floor attic... need to relocate wifi 15:06:55 or install a repeater (or two) 15:07:02 wires for the win 15:07:15 * bcoca stares at cat6 in his bathroom 15:07:29 new house was built in '93... got a quote from an electrician for pulling ethernet and it was $$$$$ 15:07:46 mine was built in 1890 15:07:59 so yeah, best i'll probably be able to do is get it on the 1st floor and hope that's good enough 15:08:11 bcoca: yeah but you've gutted yours at least once :) 15:08:17 x3 ... yes 15:08:18 and here I just finished artfully taping ethernet to the walls 15:08:38 jimi|ansible: http://www.homedepot.com/b/Tools-Hardware-Power-Tool-Accessories-Drill-Bits/N-5yc1vZc248 15:08:38 anyway, meeting! 15:08:55 jtanner: thanks... 15:09:02 jimi|ansible, my first PR meshes well with your comment on #111 15:09:04 always here to help =) 15:09:05 bcoca: I win, 1855 ! 15:09:25 if we can get #3025 into RC2, that would be useful 15:09:26 willthames: /me looks 15:09:32 * gundalow waves 15:09:34 willthames: its already there 15:09:41 q 15:09:41 cool, let's move on :) 15:09:51 toshio cp into stable-2.1 which is what rc2 is cut from 15:10:07 bcoca: that was cp'd, ok 15:10:14 willthames: just verify and let me know if that's not the case 15:10:17 bcoca, sounds good, I didn't know that was the source of RC2 15:10:18 fyi, cp == cherry picked 15:10:24 but I will check 15:10:25 nm, he said in a comment he did it 15:10:29 stable-x is ALWAYS the source of next RC 15:10:35 it's definitely in stable-2.1 15:10:40 k, then we're good 15:10:45 it's like the next commit after the RC1 15:10:53 ok, https://github.com/ansible/ansible/pull/12904 15:11:06 I have been waiting on this one forever 15:11:18 and in the absence of any other known roles/galaxy work, I would like it in 15:11:23 looks good ingeneral, some bikeshedding on new property, its more full_name than version as you add name to it 15:11:35 is there a force option? 15:11:38 chouse gave it a +1, so i'm fine with merging it 15:12:29 ^ changes default behaviour if roles are installed, we should at least add a toggle to let users decide if this is what they want 15:12:59 sorry i'm late. 15:13:10 lots of things to do. 15:13:15 bcoca, not sure, line 404 looks like it still respects force 15:13:26 I say not sure as it's been months since I last looked 15:13:34 is this the autoinstall roles proposal? 15:14:01 tima, no, that's next 15:14:19 no, this is 'install if diff version' 15:14:24 bcoca, you're right, it will update roles even if they exist, with force off 15:14:34 ok. thanks. just catching up here. 15:14:35 also ... you can downgrade ... 15:14:58 this is supposed to be 'don't bother doing anything if the role already exists, only do stuff for changes' - i.e. install idempotency 15:15:13 not sure this is behaviour we want as is, might want an upgrade option and a force even if downgrade 15:15:47 does not make install idempotent, just adds version diff to it 15:15:52 this PR is 8 months old 15:15:54 many other steps to make it idempotent 15:16:04 you have had plenty of opportunity for feedback 15:16:12 i have 1yr old prs in my queue 15:16:14 sounds lke this can be merged into one - install if doesn't exist, upgrade if newer. downgrade if force. then it's like idempotent modules 15:16:24 it makes install not spend a whole heap of effort doing stuff if nothing needs doing 15:17:53 if anyone wishes to provide actionable feedback on the PR, I can likely accommodate that, I just want it to move forward 15:18:22 although I like jimi|ansible's suggestion best 15:18:55 willthames: i disagree about force, https://github.com/ansible/ansible/pull/12904/files#diff-0fb1ac8e85c5f8b604a2bcbbe16a50c8R405 is in the 'not force' code block, so it will remove the old role if not forcing and the role versions don't match 15:19:11 * jimi|ansible grrrs at wifi again 15:19:45 jimi|ansible: you need to shake your fist at it, too 15:19:53 jimi|ansible: pointed that out in the PR 15:20:24 bcoca - what? where? 15:20:25 ahh i hadn't refreshed 15:20:43 ah, ok, me neither 15:20:44 willthames: been comenting on ticket during the meeting 15:20:48 as you asked 15:20:54 the check on force should be moved down into that if block, and it should be an if/elif/else 15:21:15 i think we can do this: if its an upgrade, go ahead and replace w/o force, if it is a downgrade, require force 15:21:40 thanks bcoca 15:21:54 makes sense 15:22:01 sadly its a package manager ... should work mostly like one 15:22:03 if if role.install_info['version'] != role.version and force (remove role); elif role.install_info['version'] == role.version (continue) 15:22:25 jimi|ansible: we might want to treat upgrade/downgrade differently 15:22:33 and else (print a message about the role existing and needing --force) 15:22:51 ^ i would do that in case you cannot determine version up/down (shas?) 15:22:51 bcoca: possibly 15:23:17 that could be another if/elif block under the portion where the versions don't match 15:23:18 can we rename -f --upgrade? 15:23:36 I believe pip will downgrade with --upgrade 15:23:51 when I say rename I mean alias 15:23:51 yes, one of the many things pip does wrong 15:23:52 willthames: -f can be to overwrite too, for instance when someone is installing a role from a branch rather than a tag or sha 15:24:12 so no, -f != upgrade 15:24:27 it shoudl be there for when we don't do actions by defaut (downgrade, no version, etc) 15:24:30 -f is almost necessary for almost every install operation 15:24:32 but in either case, since we're installing into the same dir --force does the same, so i don't think we need to do any special handling for downgrading 15:24:35 it's pretty much meaningless anyway 15:24:50 willthames: perhaps --allow-downgrade? 15:24:54 jimi|ansible: well, eventually we wnat to move way from that 15:25:04 s/way/away/ 15:25:26 part of the plan is allowing multiple versions and ref role by version/min version 15:25:50 yes, i have been considering allowing a subdir under the main role dir 15:26:07 jimi|ansible: subdir? 15:26:08 ie. role_name/1.x.y/{tasks,meta,etc...} 15:26:20 ah, no, i was going for parallel and symlinks 15:26:23 eeewww 15:26:26 kind of like debian and gentoo do slots 15:26:29 so your role spec would be - {role: role_name, version: 1.x.y} 15:26:50 hey, you know if you guys actually wrote this stuff up, I wouldn't need to revisit proposals#7 15:26:58 /role_name-version and link to role_name for 'latest or user selected' 15:27:06 willthames: i've been considering it for about 10 minutes :) 15:27:09 willthames: its on my list 15:27:09 jimi|ansible, I really want to keep versions out of playbooks 15:27:17 it's been on your list for months 15:27:20 willthames: and we've discussed this before 15:27:24 willthames: looong list 15:27:24 willthames: you do, but i've been asked about this several times before 15:27:49 some users really want more specific control over what versions of roles they use in playbooks 15:27:50 willthames: i brougt this up during london dev meeting 15:27:56 and they want them all available from one role path 15:28:05 yeah, and proposals#7 is long after london dev meeting 15:28:11 jimi|ansible, yeah, that's weird 15:28:24 i agree, it's not how i'd do things at all 15:28:25 all of our roles are relative to playbook_dir 15:28:28 jimi|ansible: no they require them. it's more than want. 15:28:53 I really don't get how diamond dependencies resolve in that scenario 15:29:02 willthames: as we discussed before, its other workflows in which many teams collaborate and reuse roles but not all on same page/version 15:29:08 which you could do today, you'd just have to do - {role: role_name/1.x.y } in your playbook 15:29:13 we have a team standard that role dependencies are banned because of that 15:29:13 no diamons, more like fans 15:29:18 and you could install them via ansible-galaxy the same way 15:29:40 jimi|ansible: yes, but we want something more built in 15:29:53 jimi|ansible, that's fine until one of the roles you use depends on a different version of that same role in it's meta/main.yml 15:29:57 ^ which is why i started considering allowing it as a more built-in mechanism via subdirs 15:29:58 not a big departure of that, if we use symlinks and version names 15:30:28 subdirs will be hard as a 'role would include roles inside' 15:30:29 bcoca, except how many canonical forms are there - commit id, tag, branch name etc 15:30:57 willthames: also discussed with you before, we need to narrow it down to 1 or 2 forms before we can get there 15:31:05 ^ i believe i state that in the proposal 15:31:10 bcoca: nah not really, if none of the special dir names are found, see if the role_dir has dirs in it and use LooseVersion to find the "newest" one (and allow for a symlink named 'latest') 15:31:30 it'd be a pretty trivial change i think 15:31:36 jimi|ansible: breaks down when you consider sha can be used as version, we need a way for user to specify cannonic al 15:31:40 this just feels like brexit. very loose on details 15:31:58 there is very little concrete in the proposals 15:32:07 willthames: it is, have not had time to write it up 15:32:14 willthames: just spitballing ideas 15:32:18 right, so it's not in a proposal 15:32:29 well, that is a diff one that he just came up with 15:32:37 jimi|ansible: how would multiple versioned be maintain by the user in that scenario? 15:32:40 the problem is clear, we need multiple role versions to coexist 15:32:59 tima: how do you mean multiple versioned? 15:33:37 for installation, ansible-galaxy would have an option to allow the installation into the subdir based on the provided version (and to modify the 'latest' symlink) 15:33:38 jimi|ansible: yes. i'm trying to imagine the users 15:34:02 piling up many versions of a role and how they'd manage/maintain those 15:34:09 jimi|ansible: sounds like almsot same as i was thinking, except i keep roles in parallel dirs 15:34:12 or it would pick it up automatically based on the same criteria i mentioned above 15:34:22 as keepign them parallel is backwards compatible 15:34:25 and also how you'd resolve which of two versions you'd use in a conflict 15:34:41 ie. if it found role_path/role_name existed, it'd check to see if there were the versioned subdirs 15:34:42 * resmo doesn't have a use case for multiple role versions... 15:35:12 resmo: 2 teams using same role, team2 modifies role, playbooks of team1 break with modified role, still want older version 15:35:15 willthames: if no version is specified, ansible would have to figure out the latest based on the use of LooseVersion on the dir names 15:35:40 jimi|ansible: when versions are 'sha'? 15:35:43 in that case i'd probably also print a warning saying "hey, no version specified and we found multiple, so using the latest (1.x.y)" 15:36:05 jimi|ansible, I'm talking about two specified versions. Say a playbook depends on v1.1 of a role, but also depends on a role that depends on v1.2 of the same role, but they have inconsistent defaults/main.yml vars 15:36:24 resmo: dev team is working on an upgrade app that changes the tasks/role. whatever they do also has to go thru QA/CI testing before being moved into prod. 15:36:26 we should look at them as 'diff roles' 15:36:28 bcoca: I life in an ideal world where the teams can discuss this out :) or make 2 repos :) 15:36:36 willthames: in that case i'd tell the user "don't do that" 15:36:49 resmo: you have not worked in 'enteprise' level companies i assume ..... 15:36:53 as we don't name space vars for roles, that'd bit them in the ass very quickly 15:36:59 communication can be frowned upon 15:36:59 s/bit/bite/ 15:37:02 jimi|ansible, if we could just say 'don't do that' we could save a lot of effort on this discussion ;) 15:37:15 jimi|ansible: +1 15:37:17 i say it all the time 15:37:26 jimi|ansible: that is why version or 'full name' has to be considered 15:37:27 bcoca: :) sure I am but I am the ansible guy who can say who things have to go :) 15:37:31 roles aren't objects. 15:37:41 tima: letsnotgothere 15:38:07 jimi|ansible: we can do w/o namespacing by just taking each instance's version into consideration 15:38:21 bcoca: oh we have java developers here? ;) 15:38:23 and handle defaults like we do now even when same role is called sevearl times 15:38:32 in fact i'd probably write it to throw an error if two different versions of a role were attempted to be used 15:38:34 tima: youarekilling me 15:38:46 jimi|ansible: that is one solution 15:39:15 jimi|ansible, you mean like https://github.com/ansible/ansible/pull/12904/files#diff-0fb1ac8e85c5f8b604a2bcbbe16a50c8R440 15:39:16 and probalby the first one we implement, at one point we might want to allow the multiple versions to execute as 'diff roles' 15:39:25 * jtanner hides evidence of java dev 15:39:31 jimi|ansible: sounds about right. 15:39:33 imagine if as a python developer you tried to use two different versions of a package... that'd be dogs and cats, living together, mass hysteria! 15:39:56 jimi|ansible: import os as notos 15:39:58 would require sys.path hackery ... 15:40:01 import os.old as os 15:40:08 willthames: yes that's for install, but for runtime 15:40:13 which leads me to think multi-role versions should just be handled with multi role dirs 15:40:14 yeah i was just thining that -- what does other package managers do like pip/python? 15:40:29 jtanner: +1 15:40:40 tima: as jimi|ansible says, its not just hte package manager, its the system running 15:40:45 I feel like we're bikeshedding the fact that multiple versions of roles are going to be a thing, and yet there are no concrete proposals and my PR seems to be blocked on this 15:41:07 if jtanner just means that each playbook should have its own roles, I'm all for it 15:41:13 willthames: getting back to your PR then, as noted there is an issue with force which needs to be corrected 15:41:13 some package managers allow mulitple version of libraries for example, but then use symlinks topoint at 'official one' then packages that use the specific versiosn can still work, those that dont specify use the symlink 15:41:25 jimi|ansible, concur 15:41:34 happy to correct now I have concrete feedback 15:41:54 I don't think I'll bother with the next meeting topic 15:42:04 I think we've already gone down that rabbithole this morning 15:42:11 well, discussion affect proposal more tahn this specific PR, i'm fine with teh PR for now (adjusted for comments), will need to change in future once we get the versions done 15:42:11 willthames: was just thinking that if playbook A has different role version requirements than playbook B, A and B should use different role paths via ansible.cfg or whatever means 15:42:42 jtanner, or just install the roles in the directory next to the playbook, which is what we do 15:42:50 yeah, "whaever means" 15:43:19 jtanner: but what about multiple plays within the same playbook using different role versions? with my idea that'd work fine without having to use different role paths 15:43:30 apparently our use of roles files was unusual for tower, 88 roles files in a repo is abnormal? (probably would be more given current standards) 15:43:47 jimi|ansible, that's your "don't do that" scenario 15:43:52 willthames: i would say your use is sane .. but sane is not 'normal' 15:43:58 role paths are plural now (iirc), so you have to compensate for that too if you want to allow different versions 15:44:05 covered in line 440 of my PR 15:44:06 willthames: not true, different plays would conceivably be fine for that 15:44:12 roles are tracked per play, not per playbook 15:44:19 jtanner: they always 'were' but not all code reflected that 15:44:46 so if play1 wants to use apache v1.0.0 and play2 wants to use apachev1.1.0 i don't have a problem with that 15:44:48 jimi|ansible, I see what you're saying, I'm just not convinced that people are asking for play-specific roles versions 15:44:57 crazy land :D 15:45:09 that is a corner case, but in theory it should be fine 15:45:15 honestly, I think that is madness 15:45:21 i dont disagree its crazy ... but it has been a gripe, specially from enteprise 'class' users 15:45:25 madness!? 15:45:32 15:45:44 hah 15:45:54 ...i shall be writing code in the shade. 15:45:59 bcoca: it is a gripe of the enterprise customers though i haven't seen it at the play level. 15:46:28 its the dev->qa->prod scenario for a project (collection of related playbooks) 15:46:28 tima: probalby cause it is not possible right now, the second we install mutiple role versions side by side ... it will happen 15:46:32 I think I'm enterprise class enough that that seems a "don't do that" use case 15:46:40 so what does multi-version have to do with willthames's current PR? 15:46:46 willthames: +1 15:46:59 bcoca: i see what you mean that's why i'm not found of introducing versions side-by-side. 15:47:02 jtanner: a little bit, has more to do with his proposal 15:47:03 jtanner: we just went down a rabbit hole, mostly my fault, we're past the PR now 15:47:15 it's ok, we're into the next topic 15:47:23 I would like concrete objections to the proposal 15:47:27 which is? 15:47:28 * resmo is out for a beer 15:47:30 so on to gundalow 15:47:32 that was supposed to be the action from last time 15:47:41 i think we posted those to the proposal, we just disagree on the objectives 15:47:41 https://github.com/ansible/community/issues/111#issuecomment-231090464 15:47:51 jimi|ansible: yo 15:48:03 bcoca, no, I disagree 15:48:06 we're still talking about #111? 15:48:13 tima, onto https://github.com/ansible/proposals/issues/7 15:48:18 willthames: exactly, you and i disagree == we disagree 15:48:22 but we've discussed it for ages last time 15:48:26 ok. that wasn't clear. 15:48:39 yeah -- what's changed in the proposal? 15:48:43 and the actions from last time were that bcoca would come up with some concrete proposals for an alternative 15:48:55 tima, nothing has changed - there has been zero feedback 15:49:01 ^ as i posted above, on my list 15:49:05 as i recall we voiced many concerns and objections. 15:49:08 #info https://github.com/ansible/ansible/pull/16491/files 15:49:14 tima, I responded to them in full 15:49:49 gundalow: how does skipping asserts help? i'd imagine that might cause problems of its own 15:49:49 not satisfactorily. 15:50:12 since later tasks quite often depend on previous ones succeeding, which is validated by asserting them 15:50:16 jimi|ansible: its for QA plays 15:50:22 i understand your proposal works for you and your way of doing things but it won't fly for many others. 15:50:33 jimi|ansible: Not my PRs, just had people ask to give then a bit of a push 15:50:39 i think debugs would work jsut as well 15:50:39 jimi|ansible: it's not skipping. it's making sure you continue with the play so at the end you get a full report instead of having it stop at the first failed assert 15:50:45 i 15:50:54 tima, then I'd appreciate further comment 15:51:16 ttom: i'm not opposed to this per se, but really the better way to handle this is via blocks with a rescue 15:51:18 've said it before, but i think skipping complete roles on fail is more useful for our integration test scheme 15:51:21 it's for plays like under test/integration/roles where you have each task followed by an assert task that verifies it 15:51:48 #topic ansible/ansible#16491 15:51:52 bah, ENOPOWERS 15:51:54 many of those tasks in the roles are pre-reqs for later tasks 15:51:56 wait. we're having two different discussion at the same time? 15:52:11 tima: no, i said we were moving on, you all just kept discussing the old topic :) 15:52:11 tima: rest of us moved on 15:52:21 * gundalow point to the stale #topic 15:52:29 which is fine, it's irc, i'm used to 3-4 conversations going on at once... 15:52:34 * jtanner backs away 15:52:48 i thought we were on #111 and moved to proposal #7. sorry. switching gears. 15:52:52 gundalow: i wasn't changing the topic as it's the main agenda, but i can if we want 15:52:57 that will require writing the play in a specific way. I wanted a way to run existing "test" plays and having them run to the end. like running nosetests - you get a report, then you go fix the failed ones 15:52:58 tima, all I want is some actionable response to proposal #7 15:52:58 #111 is the agenda 15:53:02 and we can move on 15:53:16 jimi|ansible: Can you please update #topic 15:53:17 jtanner: It's not for use with our integration tests, but for playbooks written specifically to take advantage of it. 15:53:19 bah. 15:53:26 #topic https://github.com/ansible/ansible/pull/16491 15:53:29 Thanks :) 15:53:46 mattclay: i was offtopic, sorry 15:53:57 #chair bcoca gundalow jtanner tima Shrews nitzmahone ryansb Qalthos newtMcKerr 15:53:57 Current chairs: Qalthos Shrews bcoca gundalow jimi|ansible jtanner newtMcKerr nitzmahone ryansb tima 15:54:00 i understand the pr though 15:54:33 ^ almost tempted to say "make test role in glaxy that has both as plugins" and then can be included in plays as needed 15:54:40 not sure its something we want to ship by default 15:54:42 ttom: ok as i said, i'm not opposed to it, but using it that way might cause other testing problems and overall it's better done via blocks 15:54:47 anyone else have an opinion? 15:54:50 use case - you're developing a module. you want to have as many tests as needed to make sure it's not breaking when ansible changes (the new module won't break ansible, but ansible will break the module). you run it by using a specific MAKE_TARGET for test/integration/Makefile using test/utils/run_tests.sh 15:55:09 It's a strategy and a callback - nobody is going to use it by accident. 15:55:28 right, which is why i'm fine with it :) 15:56:14 i'm still trying to take it in. 15:56:15 if it's a callback plugin though, does it need to be included? 15:56:32 willthames: it's what allows the summary of asserts to be shown at the end 15:56:42 otherwise it's not super helpful just to pass asserts always 15:56:51 ansible.cfg allows you to point at your own callback plugins though 15:57:10 the strategy makes sure asserts get 'ignore_errors=true' and the callback keeps track of assert tasks and provides a report at the end 15:57:15 well, using that logic, we would not ship any 15:57:21 bcoca, true 15:57:28 and it's not like it's enabled by default 15:57:30 ^ tempted ... 15:57:39 right, i'm assuming we'd merge this because it's something we'd look to use in our integration tests 15:57:54 which would have to be cleaned up so that future actions don't depend on things being asserted 15:58:02 we already merged the junit callback ... 15:58:17 I'm not so sure we'd use it for our tests. 15:58:28 what if i'm testing a play with a different strategy type? like free? 15:58:29 We'd have to re-write our tests to work with it, for starters. 15:58:31 im fine either way, this can go to galaxy or we can ship it, either way user has to explicitly use it 15:58:43 I have an irc callback plugin (based on the slack plugin) 15:58:45 mattclay: why not? i already want to rewrite them to use blocks as I mentioned 15:59:11 that way we could have all tests run regardless of errors 15:59:16 im suprised we did not ship an irc callback ... 15:59:25 jimi|ansible: I've gone back and forth on whether we want all the integration tests to run to completion or not. 15:59:44 It would be nice to get a full picture of the test results, but it's a waste of CI resources too. 15:59:54 i do, it makes it easier to spot problems in multiple areas in one shot 16:00:58 I'm fine either way. a while back I asked how to tackle the issue with failed asserts stopping the play and not running the next tests. you suggested it might be done with a callback plugin and a strategy. if there's a better / easier way - I'd switch to it. I thought this solution can be applied to any plays already written in this manner (and there are, as mine are based on others that are there) 16:01:57 mattclay and I were talking about the strategy thing awhile back (IIRC I proposed the name "apathy") 16:02:13 +10 on name bikeshedd 16:02:21 anyway, it can be altered to stop executing additional tests if a specific assert fails. assert doesn't complain if you add additional args - you can add "halt:true" and the strategy can make sure it halts 16:02:25 ttom: another option might be to set ignore_errors at the Play level (or at the block level, if you want it more fine grained) 16:02:29 and then still use your callback 16:03:04 many ways to do it 16:03:06 ttom: that highlights another problem area... module params are not validated at the action level 16:03:17 jimi|ansible: +1 16:03:20 But requiring a nonstandard exec strategy for integration tests also seems .. wrong 16:03:25 not a big deal, just something which should probably be done to prevent typos from confusing users 16:03:59 but you don't want ignore_errors for other tasks - the play usually does three types of tasks - 1. a setup task that prepares the state to be tested (can't have ignore errors), the test task and an assert task. 16:04:31 ttom: right, so you could put your asserts in a block and put the ignore_errors on the Block 16:04:33 you can override the play setting at task level ... also blocks! 16:04:46 jimi|ansible: stopreadingmymind 16:04:49 heh 16:05:19 If we do end up using something like this for our integration tests, it should be optional. Having the ability to stop on the first failed test is good for conserving CI resources. 16:05:32 mattclay: strategy is settable per play 16:05:37 so it'd be easy to mix in 16:05:39 nitzmahone: right. that becomes problematic in large ci/cd shops if you need to modify the play to test it then modify it back. 16:06:10 strategy: "{{runme|default('linear')}}" 16:06:32 -e 'runme=apathy' 16:06:34 bcoca: opens the door to a production runtime error. 16:06:42 ttom: so i think there may be general interest in the callback, but not the strategy. Anyone else agree/disagree? 16:06:52 agree 16:06:59 tima: like that was not a 'jupiter sized hole' already 16:07:12 jimi|ansible: I was just meaning run all tests and stop on first failure (as we do now), or optionally run all tests to completion. No need to configure it differently for different plays. 16:07:24 tima: it will simply tell you the strategy was not found and stop 16:07:27 it's handled nicely 16:07:34 OK. So I'll work on writing the playsin a way that doesn't require a strategy and edit the callback to match. it will also mean that once a play is written like that, you can't turn the behavior off by changing the strategy. 16:07:54 bcoca: except now you've pointed a telescope at it for the audit and compliance team. 16:08:08 mattclay: right, this is why i want to wrap all our tests in blocks, so they can run to completion but at the end check to see if things failed and exit appropriately 16:08:30 tima: no worries, they probably think its a condiment dispenser 16:08:30 i think the additional resources is a non-argument, because it's no more intensive (and is in fact less intensive) than a test that passes with no errors 16:08:32 jimi|ansible: understood. i meant that someone could easily run test under production or free when its supposed to be (was tested as) linear. 16:09:50 tima: yes, but we can't stop all users from tripping over their own feet 16:09:57 jimi|ansible: For run to completion, are you thinking a single test role, or an entire playbook like destructive? 16:10:11 mattclay: per role 16:10:31 until bcoca's role-revamp thing works, it'd be the only way 16:11:17 So test roles would run to completion, but we'd stop after the first role which had any failures? 16:11:40 jimi|ansible: agreed. i'm just not for saying that tying their shoes is optional. ;) 16:12:04 no, the top level playbook running it would run all and at the end (in tasks or post_tasks) check for flags set by rescue blocks and do a `- fail:` as needed 16:12:17 since we're breaking the tests out per group now, that'd be fine 16:12:47 https://github.com/ansible/ansible/pull/16630 16:12:50 ^ MT 16:13:13 bcoca: k, we're still running through gundalow's stuff 16:13:34 so it's gone 2am for me now - I have no strong opinions on the other agenda items, but 14332 lgtm 16:13:34 there were some additional dag- things he had in there after this testing stuff from ttom 16:13:57 willthames: k thanks! 16:13:59 to sum 16941 - i'll remove the strategy, and focus on the callback? 16:14:10 ttom: yeah i think so 16:14:14 jimi|ansible: MT <= miss tell ... means you should ignore 16:14:24 is the testing working group meeting anytime soon? 16:14:34 ahh, i had no idea what the mt was supposed to mean 16:14:51 sorry .. old BBS lingo ... 16:15:05 willthames: Thanks for your timne 16:15:10 ttom: since we've got an actual QA team for core now, might be worth setting that up? 16:15:18 thanks gundalow 16:15:32 bcoca: I thought MT meant Movable Type -- I was having PTSD flashbacks here. ;) 16:15:32 Not sure how long dag- will be around for either... 16:15:34 willthames: will try to get the galaxy/role proposals out soon, sorry i've been lagging on that 16:15:35 thanks jimi|ansible , and thanks everyone else 16:15:41 I'd like to return home 16:15:51 bcoca, that would be great 16:16:00 * ttom thanks everybody for their input 16:16:09 dag-: that's fine, if you want we can discuss them later when you're back around? 16:16:13 (in #ansible-devel) 16:16:17 thanks everyone. 16:16:25 and we can just run over them and leave comments now 16:16:30 move rest of items for next meeting? 16:16:41 jimi|ansible: fine by me, I think all of them have been discussed before, I just need to know what the plan is 16:17:09 dag-: k i'll check them out and if there's anything we need to discuss i'll move them to the agenda for next tuesday 16:17:20 you're too kind :-) 16:17:22 Shrews: how about yours? the one was merged into devel and stable-2.1 i believe? 16:17:22 jimi|ansible: Sounds like a plan 16:17:28