23:59:59 #startmeeting Azure Working Group 23:59:59 Meeting started Wed Nov 15 23:59:59 2017 UTC. The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot. 23:59:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 23:59:59 The meeting name has been set to 'azure_working_group' 00:00:19 Hey all- welcome to the inaugural meeting of the Azure working group! 00:00:31 Roll call?\ 00:00:52 Hello Matt. This is Kylie from Microsoft. 00:01:21 I am PM, driving Ansible on Azure. Today we have two topics. 00:01:30 #chair Kylie KevinZhao-MSFT tripdubroot 00:01:30 Current chairs: KevinZhao-MSFT Kylie nitzmahone tripdubroot 00:01:49 Hey, Jordan from Red Hat 00:01:56 #chair jborean93 00:01:56 Current chairs: KevinZhao-MSFT Kylie jborean93 nitzmahone tripdubroot 00:02:47 #topic how to release latest Azure modules through Ansible playbook role? 00:02:48 https://github.com/ansible/ansible/issues/32617 00:03:30 Kevin cannot access IRC at home. So he sent his question to me. Here it is - Basically I want to know how we can modify the library path within a role as Matt suggested. But I couldn’t find any documentation about it. We need Matt’s help on how to do it. 00:04:04 It can either be done via ansible.cfg or the envvars I mentioned in that issue. 00:04:20 ansible.cfg is probably the better way for most folks but just depends 00:05:08 The ideal setup is that the Ansible *content* doesn't need to know about the module masking and separate distributions 00:05:40 So the playbook just uses the modules and assumes they're present- it's up to the config to make that happen 00:06:25 What we *lose* with this is the ability to "hide" modules that have since been shipped in the case of an Ansible upgrade. 00:06:28 how to modify env vars within a Role? Any guidance? 00:06:32 You don't 00:06:49 You have to modify it before calling ansible-playbook 00:06:53 That'd be done on the host running Ansible 00:07:27 That's why the config file is probably a better choice for most people, but it can be done with env if they use per-project config files or something 00:07:56 Then it means we need to ask customer change env vars by themselves. 00:08:32 There's no great solution to this today, but it's better to handle outside of the content. 00:09:32 The installer stuff that's slated for 2.5 *should* make this a lot easier, but it's still being defined 00:11:36 Let me sync up with Kevin later. 2.5 is late for us and as you pointed out it's still being defined. Anything could we help to fasten it? 00:12:58 We could discuss it later. Since Yuwei, Tripdubroot are online, I would like to raise topic #2. 00:13:11 Not really- the only thing that you want to do that's a little different than the typical usecase is hiding builtin modules, and I'll make sure that's handled. 00:13:47 Wonderful. Thank you Matt. 00:13:52 #topic PR requests for new modules. 00:14:47 tripdubroot submitted a PR for new module "key vault management". 00:15:47 Yuwei submitted new module for Azure image. Any else, Yuwei? 00:16:28 No more new module from my side, but add some new features for existing modules 00:16:32 I've been meaning to review the azure image stuff, I think there were a few things I needed to look further into, there is another PR with a corresponding facts 00:17:30 finally managed to join, sorry i'm late... 00:18:21 welcome 00:18:31 Welcome 00:18:56 #action nitzmahone/jborean93 to review #32756, #32589 00:19:22 We'll take a look at those 00:19:24 Hi Jordan, it is https://github.com/ansible/ansible/pull/32589. And please help review others, https://github.com/ansible/ansible/pull/32535. Please help take a look too. Thank you. 00:20:11 So there are a couple of 2.5 roadmap items currently on my plate: 00:20:13 Other two new modules are submitted for ACR and ACI. https://github.com/ansible/ansible/pull/32336 00:20:27 https://github.com/ansible/ansible/pull/32025 00:20:41 Also there is a bug fix: https://github.com/ansible/ansible/pull/32614 00:22:12 #action nitzmahone/jborean93 review #32336, 32535, 32025, 32614 00:22:48 i am currently working on several sql modules (there will be quite a few of them). so is it preferred to create single PR for a few related modules, or split them into single PRs? 00:23:10 It is best to split into smaller chunks as possible 00:23:22 Makes it easier to review when the changes/additions aren't too large 00:23:33 Or serialize them 00:23:57 (eg if there are shared module_utils, merge those things first and one module) 00:24:17 Then add other modules on as you see our feedback on things like UI 00:24:29 What will the SQL modules be doing? 00:25:08 everything related to Azure SQL support, starting from servers, databases, etc. 00:25:44 OK- do you anticipate the need for new shared code amongst the modules? 00:26:28 no, just using existing azure shared code atm 00:26:31 ok 00:27:32 So I'd suggest maybe PR 1 at a time, and maybe do 2-3 PRs at first, then we can review and if there are overall stylistic or UI-ish changes that need to be made, you can do them offline before PRing them 00:27:35 but for example releasing sql servers module without sql databases doesn't make much sense from user perspective, but for review purposes is ok 00:27:59 Right, but we're still a ways off from release yet. Module freeze is Jan 30 IIRC 00:29:05 Doesn't really matter when they land in devel so long as you've got a workable set by freeze 00:29:14 ok, i will then create 2 PRs first, one for servers one for databases (each of them including facts) 00:29:20 Sounds good 00:29:36 I don't mind if you include the related facts module in the same PR- the bot may gripe at you, but meh 00:30:05 ok, i will try :-) 00:30:47 #topic v2.5 roadmap for Azure. 00:30:48 As for 2.5, below are our plan by now - ACR/ACI (PR opened); AKS, SQL, Key Vault (tripdubroot is working on them), role assignment and App service. Will you have a separate meeting for 2.5 plan? Or just write them into the roadmap? 00:30:49 One of the roadmap items is cleaning up the results from the modules though- we want to get away from just returning the serialized JSON result from the SDK. 00:31:10 Neither- that's what the working group wiki is for 00:31:25 Ok. 00:31:25 The roadmap is about stuff Red Hat is writing 00:31:53 So this stuff should definitely be reflected there- just really high level and maybe who's working on it + ETA 00:32:29 "cleaning up the results from the modules" - do you have any more info on this? what shoudl be returned prefereably? 00:32:40 Mostly for other community folks who either want to contribute (to avoid duplicated PRs like the azure image stuff we just hit) and also so the community knows what's coming and can help test 00:33:21 Module results can be a bit of an art 00:33:27 Basic ideas: 00:33:42 * don't duplicate things that were passed as args to the module in results 00:33:59 * only return things that are actionable/usable by downstream modules 00:34:11 (eg, "forensic" stuff is better returned by diff mode) 00:34:52 So some modules might not return *anything*, though in the case of most cloud modules, things like the ID of the object created are good to return 00:35:01 We also want to try and avoid deeply nested results, try to keep dictionaries only at the root level 00:35:03 (anything beyond "changed", that is) 00:35:07 ok, so basically, that "verbose" output should be just returned by _facts only? 00:35:22 Yep 00:35:44 and in the main module we should be selective and flatten / minimise the response 00:36:23 ok, that sounds good 00:36:42 Yes- even the facts modules can sometimes need some careful thought, though. Just serializing the JSON from the SDK often yields a structure that is very deep and difficult to do anything useful with (remember, Ansible is *not* a programming language, and its target audience not programmers) 00:37:52 #action zikalino (and others on MS side) to update community Wiki with basic info on work in progress 00:38:09 Yes. 00:38:43 Then how Red Hat add those stuff to overall roadmap? I assume you will take care of it. Right? 00:41:01 We generally don't- the roadmap is mostly about communicating our commitments to the community about what we're building for a given release. Working group outputs like this are merged as they're ready. The working group stuff is pretty new, so we're still figuring out the best ways to engage and communicate more broadly, but generally folks that are following a particular subject area closely will come look at the working 00:41:01 group stuff for that subject area 00:42:25 That could change if GitHub ever makes their project boards changeable by non-committers, but at the moment, the roadmap board is only workable by full committers 00:43:50 (so having us managing that for N working groups is prohibitive) 00:43:50 Got it. 00:44:10 Thank you. Then that's all from my side. 00:44:58 FYI: roadmap board (filtered for Azure) is at https://github.com/ansible/ansible/projects/9?card_filter_query=azure 00:45:47 #info Red Hat Ansible Azure roadmap for 2.5 https://github.com/ansible/ansible/projects/9?card_filter_query=azure 00:46:05 Nothing else for me- shall we call it a meeting? 00:46:52 I'm good 00:46:55 So once the meeting is over, zodbot will display the URL for the log/notes/etc - as these go on, they'll be collected centrally so long as the meeting name is the same. 00:47:13 So Kylie, are you comfortable running the next one, or do you want me to do it again? 00:47:54 I could do it next one. Thank you Matt. 00:48:08 (so it'd be (hash)`startmeeting Azure Working Group` every time to ensure they're collected in the same place 00:48:32 OK, thanks all- we'll try to get those reviews knocked out in the next couple days 00:48:35 #endmeeting