00:06:28 #startmeeting Ansible Azure Working Group 00:06:28 Meeting started Thu Dec 20 00:06:28 2018 UTC. 00:06:28 This meeting is logged and archived in a public location. 00:06:28 The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:06:28 Useful Commands: #action #agreed #halp #info #idea #link #topic. 00:06:28 The meeting name has been set to 'ansible_azure_working_group' 00:06:39 D - destroy resource and create from scratch 00:06:39 #chair Kylie_ yungezz zikalino82 00:06:39 Current chairs: Kylie_ jborean93 yungezz zikalino82 00:06:46 #chair yuwei 00:06:46 Current chairs: Kylie_ jborean93 yungezz yuwei zikalino82 00:07:36 ok, i will resend whole thing :-) 00:07:45 idempotence of options that can't be updated, how they should behave: 00:08:02 #topic idempotence of options that can't be updated 00:08:26 so i guess we just collect opinions right now, we also need opinion from Matt 00:08:48 currently lots of modules (like vm for instance) just do A 00:09:01 I think typically we document the behaviour where properties that cannot change after creation (or we don't implement it) 00:09:13 and i think this is wrong, as the playbooks and actual state is out of sync, but users get OK 00:09:56 myself i would do B or C 00:10:17 at least there should be a warning that something was not udpated 00:10:27 how do you think? 00:10:34 I agree, if we can check something we should at least add a warning 00:10:42 That means all our modules need rewriting, currently we only care what could be changed and compare 00:11:11 not really, different modules behave in different way 00:11:25 Can you give an example 00:11:27 yea it seems to be a mixture today 00:12:20 I didn’t see error or warning when updating not updatable argument 00:12:43 can't think of any particular example, but i think for instance appgateway module will detect any changes and then fail if something can't be updated 00:13:09 That’s new module from you 00:13:40 that's the problem with current modules, for instance vm, we don't know that something wasn't checked on purpose, or because it can't be updated 00:13:46 for instance in vm. 00:13:51 What’s the common practice here? How aws and other modules work? 00:14:07 I don't think there is a common practice 00:14:07 image references were not checked, and they can be updated in particular circumstances 00:14:21 it's up to the author of the module but I've never seen a standard in place 00:14:41 sorry, that's in vmss, image references can be changed 00:14:41 common sense would indicate we at least indicate to the user if we detected a state change but either couldn't or didn't change it 00:15:13 so we shoudl agree on warning or error then 00:15:19 from the ‘changed’ in result right 00:15:46 I don't see why not, it would be hard to do an error outright when changing older modules because that's a behaviour change 00:16:04 Agree 00:16:07 But we can at least add a warning to indicate the user's state wasn't fully set 00:16:24 warning is more difficult to implement though 00:16:27 than error 00:16:36 in what way? 00:16:52 for warning we have to check everything in the module 00:17:12 Error same 00:17:14 it would be the same case for an error as well 00:17:19 for error we can just submit request to azure, and if it fails we have an error with descriprion why it failed 00:17:58 again, vmss image reference is a good example. 00:18:07 if we start moving towards checking individual options we can also start to look at implementing diff mode in the future 00:18:08 I think that’s today’s logic if you’re talking about error from azure 00:18:38 The check should be in ansible 00:18:40 yes 00:18:57 yep, gives you finer control when running in check mode as well 00:19:09 why should the check be in ansible? in case of displaying error it's redundant 00:19:12 it just unfortunately adds more logic and code 00:19:22 oh, yes, i agree with check mode..... 00:19:48 there's one risk also, the logic may change on the azure side, and we won't know it 00:20:16 It’s always there 00:20:28 Choices, 00:20:31 ok, let's stick to warning then 00:20:33 B - ignore, but display warning 00:20:36 Behavior etc 00:21:07 then we can implement check mode propely 00:21:20 but also we shoudl have a rule that we don't depend on azure errors 00:21:43 if the behaviour can change on their end it's probably not a good idea to rely on it 00:21:45 i mean, if error comes from azure, it's a bug and we should fix the logic in module 00:22:37 for instance right now, vmss image reference update works correctly when you replace one custom image id with another custom image id. 00:23:10 so that logic shoudl be moved to the module itself 00:25:56 still, is it ansible like behaviour? to display a warning that resource is in unchanged state and display "ok" in the same time? 00:25:56 that makes sense to me 00:28:35 ok, anyway, let's stick to it, always can be changed easily to errors if necessary :-) 00:29:46 cool, anything else we would like to talk about? 00:30:08 I have one inventory pr https://github.com/ansible/ansible/pull/50006#issuecomment-448230126 00:31:48 It seems ok to me at a glance, I'm sure Matt would like to review it when he gets back though. I see Alan has tested it which is a good sign 00:31:59 Ok 00:32:57 Who is Alan? 00:33:02 Any other or? Zim and yuwei ? 00:33:07 No 00:33:15 he's dev on Ansible Tower/AWX 00:33:19 No 00:33:25 I see 00:33:43 No more topic. Thank you Jordan 00:33:54 Thanks Jordan 00:33:55 no worries, I'm off next week but will be back the week after 00:34:10 Thanks, have a good one all 00:34:22 Thanks all 00:34:25 #endmeeting