00:02:45 #startmeeting Ansible Azure Working Group 00:02:45 Meeting started Thu Sep 20 00:02:45 2018 UTC. 00:02:45 This meeting is logged and archived in a public location. 00:02:45 The chair is Kylie_. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:02:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 00:02:45 The meeting name has been set to 'ansible_azure_working_group' 00:03:00 #topic https://github.com/ansible/community/issues/281#issuecomment-420052274 test resource costs 00:03:19 Just wanted to remind everyone to be careful of the cost of resources used in tests 00:04:08 Ok 00:04:10 We want to try and limit ourselves to the cheapest instances that we can 00:04:26 We’re aware of Matt’s change 00:04:32 there's been a few cases where expensive instances/resources were used costing a lot of money 00:04:52 cool, if we need to test something expensive we can always talk about it here and find a cost effective way forward 00:04:59 As for VM, I think it is reasonable to try cheapest instance. 00:05:00 Sure 00:05:19 hi all 00:05:25 o/ 00:05:29 We start to add more modules for PaaS. 00:05:37 We noticed :) 00:05:44 I guess we could delete PaaS in each round of test. Right? 00:06:41 Not sure what you mean there- you mean within a given test run? 00:06:53 Yes, a given test run. 00:07:16 I guess what I mean is, what's the alternative? 00:07:46 One other thing I'm not sure if mattclay has mentioned, he's noticed a common trend where module PRs touch azure_common. This results in the full test suite when just an individual test is needed. It's more a question around whether azure_common is structured properly 00:08:20 The big thing there would be to go back and get rid of the "common client" pattern. I had a PR to do that awhile back, but it bit-rotted before I merged it 00:08:48 "common client" pattern is probably the largest source of entropy in azure_rm_common 00:09:23 would make everyone's lives easier as the tests will complete a lot faster :) 00:09:29 Basically restructure common to only deal with auth 00:09:42 and each module creates its own client 00:09:57 about this " trend where module PRs touch azure_common." 00:10:09 There's a tiny bit of other shared code in there that really doesn't need to be 00:10:14 That would result much more stable test runs (due to reduced test execution) and results would be returned much faster. 00:10:14 i think we should separate prs to make change in common first 00:10:24 and then change in the module / new module pr 00:10:42 Then each module need take care of their own api version 00:10:46 Any time changes to a module require changes to common code, that's a good indication there's something in the common code that doesn't belong there. 00:10:56 That’s ok 00:10:58 We should be moving to profiles for all that stuff anyway 00:11:29 Now that SDK profiles are "first class" 00:11:46 In future to support azure stack we need handle it again 00:12:08 Make sense 00:12:09 Not in shared code though, and still not directly managing API versions, just profiles 00:12:21 Yes 00:12:57 Let’s start from new modules 00:13:37 Yeah, not too hard to go back and change the old ones either, but definitely let's stop the bleeding by not adding any new shared clients 00:14:07 Yes 00:16:22 Not sure what else is on the agenda, but do we want to discuss comments on https://github.com/ansible/ansible/pull/45548? 00:17:04 Not sure if this was around "make it like this" vs "add/remove" modes, or something else? 00:17:07 Go ahead first. Zim for 45548? 00:17:58 yes, we were discussing it internally with yungezz already 00:18:14 btw, i am putting together the doc here: https://github.com/ansible/community/wiki/Azure-Module-Guidelines 00:18:22 About updating object 00:18:22 Also the comment about round-tripping SDK objects vs "re-creation" 00:18:35 i am more about doing it "make it like this" 00:18:37 Yes 00:18:50 and also here we agreed to make one more change 00:19:20 Zim raised concern some not supported Parameters might been missed if recreate 00:19:50 query existing load balancer structure -> check idempotency -> update existing struct -> update load balancer 00:20:13 Yes that’s the flow we discussed 00:20:15 yes, if existing lb has something that is not supported by the module, it will be deleted 00:20:17 "Make it like this" mode is generally the more useful of the two, and should probably be considered the minimum. Bolting on "add/remove" behavior later is difficult, because it usually requires one or more mode flags for the sub-list you're working on... Often also a code smell for "maybe this should be managed by a separate module", but that's not always possible. 00:20:47 I also love that you're asking those questions now. :) 00:20:58 so my initial intention here was to merge this pr as it is a the momemnt, and then improve it in the next pr. 00:21:20 but finally we agreed that i will make second improvement too before merging 00:21:50 Yeah, it's definitely the safer way to go 00:22:28 then i want to craate some idempotency tools for common patterns, and move them to common 00:22:37 (for instance arrays of resources) 00:22:43 (I assume you mean the round-tripping the SDK objects vs creating new ones and potentially dropping unknown properties on the floor) 00:22:44 and update the doc https://github.com/ansible/community/wiki/Azure-Module-Guidelines 00:23:02 👍 00:23:04 i would like to achieve some level of consistency how all the modules work 00:23:25 As for https://github.com/ansible/community/wiki/Azure-Module-Guidelines, Matt/Jordan, could you please help reivew and share feedback to us? 00:23:28 so pls review the doc too give me some comments :-) 00:24:02 i think it's the result of our long discussions :-) 00:24:03 * nitzmahone adds to review queue 00:24:27 Can't remember, is anyone coming out for AnsibleFest? 00:24:34 three ouf us 00:24:36 of us 00:24:46 and more from redmond 00:24:48 Matt, as I heard, you will share us some guidance when Google magic module (auto-generator) was raised in sync up meeting. 00:24:52 excellent- let's do a dinner or something 00:25:08 I head the name of Matt from the minutes. I assumed it means you;) 00:25:13 Probably 00:26:51 Yes for AnsibleFest. For "The Contributor Summit will also be over two days, on Monday 1st and Thursday 4th October, from 9:30am to 4pm (time subject to change).", @zikalino82 and @yungezz, not sure you are aware of Monday 1st or not. 00:27:07 I'm not super familiar with GCE, but IIUC their REST API lends itself a little better to autogenerated stuff than Azure's... I suspect if we tried to autogen those you'd have to replicate a lot of the flattening/API reformatting stuff that occurs with the Python SDK generation, and still end up with a much more "dense" object graph for a given resource than a hand-built module would. 00:27:07 Yes 00:27:09 yes we are 00:27:57 If somebody wants to play with it, go for it, but I'm guessing the user experience will be sub-par with a generated module and it might not be worth the trouble 00:27:58 i can share my experiences on the autogeneration..... ;-) 00:29:46 @zikalino82 and @yungezz, let us do more investigation, including "their REST API lends itself a little better to autogenerated stuff than Azure's." based on Zim's experience on the auto generation. We could discuss more with Matt during AnsibleFest. 00:29:59 Ok 00:30:33 Great. Then you all will be on Contributor Summit on Oct 1. If available, how about have dinner on Oct 1 night? @nitzmahone? 00:31:02 Should be fine- let's set it up offline! 00:31:08 Looking forward to it 00:31:24 I noticed there is "ask expert" session, not sure whether we have chance to ask Ansible Tower expert how to set Azure credential in Ansible Tower or not. We did not get it work:( 00:31:47 Nice:). 00:32:16 Hrm, that's pretty straightforward- I haven't done it in awhile, but yeah, we can play with that while you're here. Some of the developers that own it will be there 00:33:14 No need to burn Ask an Expert time for that though- we can "hallway track" someone for that if we can't get it working ourselves 00:34:20 ok, i just have one more thing, want to merge 2 modules: https://github.com/ansible/ansible/pull/45077 00:34:21 Great. Let me get environment ready on Azure before that and ask you find someone take a look. 00:34:37 and https://github.com/ansible/ansible/pull/45074 00:35:08 nitzmahone you alrady checked them briefly last time 00:35:20 Cool- I'd already glanced them over, so I'll take those 00:36:10 actually i realised that one of these i need for the demo for ansible fest, but i use azure_rm_resource instead ;-) 00:36:29 Nothing saying you can't demo from your own branch too, nobody will know ;) 00:36:46 "pay no attention to the branch behind the curtain" 00:36:51 * nitzmahone has never done that, nope ;) 00:37:24 it's ok, i want to demo azure_rm_resource anyway :-) 00:37:29 We should be able to get those merged by fest if you want to brave demoing from devel 00:37:53 Cool- anything else for today? 00:37:55 i have just noticed they would be very useful for myself... 00:38:12 BTW, next Thursday (Wednesday for US), I will be on the flight to SFO. 00:38:32 No other topic from me. Catherine, I guess you want to ask for review for CDN next week. 00:39:03 nothing else from me too.... 00:39:08 Cdn need some revisit after today discussion, for client in common 00:39:25 I will take it next week 00:39:37 I see. 00:39:56 If no other topic, I will trigger "endmeeting". 00:39:57 Sounds good- let me know if you run into anything with that. IIRC it was pretty straightforward, but might be something weird with arg validation or something 00:40:09 (when I did the PR to get rid of all the common clients) 00:40:17 Thanks all 00:40:23 til next week! 00:40:36 see you alll! 00:40:44 Thank you all. 00:40:47 #endmeeting