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