00:01:05 #startmeeting Azure_Working_Group 00:01:05 Meeting started Thu Jan 18 00:01:05 2018 UTC. The chair is Kylie_. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 00:01:05 The meeting name has been set to 'azure_working_group' 00:01:21 Hi everybody 00:01:30 Are Matt and Jordan online? 00:01:39 o/ 00:02:12 :) 00:02:28 #topic issue/pr triage 00:03:07 Jordan, will you triage opened issue/PR? Any regular meeting? 00:03:29 I've been looking at the SQL modules Zim has put forward 00:03:31 I am thinking we should triage those fro Azure here every week to ensure we don't miss critical stuff. 00:03:44 Thank you Jordan. 00:03:46 But for standard issues it really depends 00:04:46 For 2.5, we would like to have SQL, MySQL, PostgreSQL, key Vault (Zim is working on it), LB fix(Yuwei will work on it), multi IP fix(Yuwei is working on it). 00:05:06 I think we have until the start of Feb for new features/modules 00:05:38 Sorry, what do you mean? 00:05:58 With the freeze for 2.5 00:06:02 so about major database modules, we just have SQL Database not merged yet, 00:06:22 i will submit keyvault today 00:06:25 Features for core modules are stopped next week I believe, community module features are then stopped at the start of Feb 00:06:38 * jborean93 checking the roadmap for details 00:06:39 7 feb i believe 00:07:00 yep 00:07:09 so until that date, we can merge in new features for 2.5 00:07:18 anything beyond that point is for bug fixes only 00:07:24 Otherwise it goes in for 2.6 00:07:38 Yes. Let us move fast to catch up Feb 7 for 2.5. 00:08:35 One approval from you or Matt is enough for one new module. Right? Then Matt and you may look at different ones. 00:09:12 yes 1 approval is needed but sometimes it may need both of us to look at it depending on the issue/change involved 00:10:32 Understand. Then in the future, how about let us use this meeting triage issues reported by customers/external contributions? We should take care of them. In the future, we also could invite them join this meeting for discussion. 00:10:49 that sounds like a good plan to me 00:11:16 of course this is a good place to talk about bigger picture topics as well as triage 00:12:48 I noticed some labels marked for issues/Prs. For example, if we reviewed one issue or PR but need more information, could we add label like "more information needed"? 00:13:14 You can't directly, but the bot can add it for you 00:13:30 How could we let the bot know it? 00:13:32 If a maintainer comments, IIRC the bot will auto-add `needs_info` 00:14:07 the full list of commands and who can run them can be found here https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md#commands 00:14:35 just beat me to it ;) 00:15:24 Thank you. 00:15:37 https://github.com/ansible/ansible/issues/34068. 00:15:55 deprecated is added. Do you know why? 00:16:25 btw "staff" here means only Red Hat employees? or anyone else can become "staff"? 00:16:37 inventory scripts are being deprecated in favour of inventory plugins 00:16:49 While there is no inventory plugin yet, it is on the horizon for Azure 00:17:04 zikalino: staff is Ansible staff I believe 00:17:36 I just did a bot_status on that one, I actually suspect the new component detection is picking up azure.py, which is deprecated (ancient service management module) 00:18:03 What's the inventory plugin? 00:18:07 He didn't use the issue template (I'm surprised it didn't tag needs_template) 00:18:20 ah that probably would be it 00:18:21 I don't catch up. Same question as Yuwei. 00:18:42 So far we are using "Ansible -I azure_rm.py xxx" which means azure_rm.py is used. 00:19:09 We're starting to migrate those to use inventory plugins, which allows them to share code (eg azure_rm_common) 00:19:34 Right now the inventory scripts are not shipped with the distribution, the new style elevates them to a full plugin 00:20:07 I have a crusty prototype, but it needs more polish before we ship it- may or may not make it for 2.5 00:20:19 The EC2 one is also very early and hasn't been merged yet 00:21:06 In the new way, you put a plugin config file in the inventory that says it wants to use azure_rm 00:21:30 (and add whatever config like grouping/tags/filters, etc) 00:22:09 o, that is the thing we should learn in advance. 00:22:11 The net effect is the same, but it allows them to be used without the "copy the code from an external place into inventory" thing and allows them to share Ansible code 00:22:13 Will it be in 2.5? 00:22:22 TBD, but it will be very early preview 00:22:31 It's been on the roadmap and I've talked about it here several times 00:23:03 The existing ones aren't going anywhere 00:23:16 We're just trying to move to a more maintainable model 00:23:38 Ok. I was not aware of the connection. 00:23:46 That means the inventory will use the code from modules, developers no need to contribute to inventory anymore? 00:23:48 Any behavior change for end use? 00:24:34 The way you initially set it up is different, but the overall effect is the same. The docs are still very sparse for the underlying plugin feature 00:24:57 The old way will continue to work, so I wouldn't worry about it at the moment 00:25:30 The existing one hasn't been deprecated (in fact the way we ship them, I don't think we have a way to deprecate them) 00:26:06 Then both will co-exist. We need to add new doc to introduce new model once it is merged. Right? 00:26:31 Docs will be included with it if we merge it 00:26:45 Could you please keep up update for the schedule when it will be online? If missing Feb 7, does it mean it will not be in 2.5? 00:26:55 More than likely so 00:27:39 Ok. Back to issue triage. 00:27:53 https://github.com/ansible/ansible/issues/33819. Yuwei also provided the solution. Could we close it? 00:28:23 I think Yuwei as a maintainer could close it? Or it is related to a module, your action or Jordan's action is needed? 00:29:18 As a maintainer she should be able to close it, as long as she is sure it is the correct action to do 00:29:39 If it is waiting for a PR to merge then it should stay open until that PR is actually merged 00:31:15 Okay, the related pr is already merged 00:32:13 so comment `bug_resolved` or we can just close 00:32:34 Thank you Jordan and Matt. Yuwei and Zim, let us triage ones submitted by customers/external contributors. If anything we are not able to resolve or any open, we could involve Matt/Jordan in. 00:33:22 Jordan and Matt, we would like to take more responsibility to take care of issues/prs for Azure. We are new for the process, anything we should pay attention on, please let us know. Thank you. 00:34:14 #topic doc 00:34:16 http://docs.ansible.com/ansible/latest/guide_azure.html 00:34:30 Could we update this doc and ask your review on GitHub? 00:34:55 Some news about Azure. We would like to add link of CloudShell which does not request authentication. 00:36:03 Doc stuff also get's review by one of the docs team, he is usually pinged on the PR if it is flagged as a docs PR 00:36:28 got it. Thanks. 00:37:00 No more topic from me. We will triage issues/PRs and let you know what we need your help. 00:37:11 no worries 00:37:26 What do we want to do about the model update stuff? 00:37:35 module update? 00:37:39 What is it? 00:37:59 The SDK model version pinning 00:38:04 O, one more important topic is about python API version. 00:38:08 Yes. 00:38:10 that 00:38:12 @Yuwei? 00:38:23 Yes I am here 00:38:45 what's the status for SDK model version pinning? 00:39:08 Imazuel has some comments to my PR 00:39:11 I have a pattern that I think will work, but I probably won't have the bandwidth to fully apply. Want me to do it to a few modules and see if you agree that it's the best way, then you can apply to the rest? 00:39:53 May I know what's the pattern? 00:40:36 Basically what we talked about before- get rid of shared client in azure_rm_common altogether, import exact model version in each module and use the shared client creation method in azure_rm_common from each module. 00:41:19 I now use common file to provide a function to load modules, but fail with sanity check since azure-doc thinks it as a doc node 00:41:47 Common file is a problem, as it requires everything using it to be on the same API version 00:42:02 Yes 00:43:02 Should we also pull Laurent (python SDK person) into the discussion? 00:43:12 This is very important. 00:43:38 Probably so, especially because some clients don't have a version, so we'll face this problem all over again as soon as a new version is created for those. 00:43:57 I assume it's only doing it that way because there has only been one version of those APIs 00:44:14 But in order to keep things working properly, every model should be versioned 00:46:07 Also FYI, 2.4.3rc2 is being cut now. I suspect we'll want to backport whatever changes are made for versioning for 2.4.4, as most of the problems still exist for whatever the next SDK update is. 00:46:45 So we need to be careful not to spread those changes around a bunch of PRs, or it leads to cherry-picking issues like what we had this time 00:47:08 Totally agree with you, but if there is only one version of a lib, the sdk doesn't provide the version option 00:47:24 Right, I'm saying I think that's a design flaw that should be easily correctable 00:47:32 pinning to a single version isn't really viable though 00:47:37 of the package I mean 00:47:52 Right, I'm not suggesting that (is someone else?) 00:47:59 Pinning to the API version 00:48:02 it sounds like yuwei's suggestion is? 00:48:17 your's is to ping to the API version so any Azure package works the same 00:48:33 We need a long-term solution. Matt, could I schedule 30 min -1hour with you to discuss it tomorrow? I will pull Laurent in. 00:49:13 2.4.3rc2 is being cut now. Will we still have the API issue? I thought we have a short-term solution there. No? 00:49:32 When is the next one? 2.4.4? When will it be? Need to fix it ASAP. 00:49:50 2.4.3 was fixed to work with the current version of the storage provider, but future changes to other SDKs will likely break it in the same way 00:50:08 2.4.4 will release near 2.5.0 00:50:13 right. 00:50:29 (possibly even after, unless there's a critical bug that drives it sooner) 00:50:46 So whatever solution we end up with for 2.5.0 should be backported 00:51:00 Agree. 00:51:24 Let me schedule a meeting to finalize the solution. 00:51:44 Just to make best use of Laurent's time, I think we should try this approach on a limited basis and propose to him that all SDK models should be versioned in codegen 00:52:21 make sense. You mentioned you had a few for try? 00:52:23 He's already weighed in on 95% of the issue- the only outstanding problem is what to do about the unversioned providers 00:52:54 I'll do a couple of them tomorrow, file a PR, and poke him on it 00:53:18 We can discuss from there, and if we still need to meet in realtime, then we can set that up 00:54:02 If we all agree the approach works, then maybe yuwei and I can split up the remaining things and figure out the best solution to cherry-pick the changes back for 2.4.4 00:54:04 let us see whether we could achieve the agreement in PR. Otherwise I will call a realtime meeting to fasten it since 2.5 or 2.4..4 are upcoming. 00:54:07 thank you in advance. 00:54:58 These changes can run past Feb 7, too- these aren't user-visible changes 00:55:13 eg, not feature changes- stabilization activity 00:55:32 got it. 00:55:49 But hopefully we can get them nailed down quickly 00:56:14 Yes. 00:56:24 Thank you for raising this topic. 00:56:30 Any other topic? 00:56:36 not for me 00:57:01 Ok. Thank you all. Please help take care of PRs for SQL... Thanks. 00:57:05 #endmeeting