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