23:59:59 <nitzmahone> #startmeeting Azure Working Group
23:59:59 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
23:59:59 <zodbot> The meeting name has been set to 'azure_working_group'
00:00:19 <nitzmahone> Hey all- welcome to the inaugural meeting of the Azure working group!
00:00:31 <nitzmahone> Roll call?\
00:00:52 <Kylie> Hello Matt. This is Kylie from Microsoft.
00:01:21 <Kylie> I am PM, driving Ansible on Azure. Today we have two topics.
00:01:30 <nitzmahone> #chair Kylie KevinZhao-MSFT tripdubroot
00:01:30 <zodbot> Current chairs: KevinZhao-MSFT Kylie nitzmahone tripdubroot
00:01:49 <jborean93> Hey, Jordan from Red Hat
00:01:56 <nitzmahone> #chair jborean93
00:01:56 <zodbot> Current chairs: KevinZhao-MSFT Kylie jborean93 nitzmahone tripdubroot
00:02:47 <Kylie> #topic how to release latest Azure modules through Ansible playbook role?
00:02:48 <Kylie> https://github.com/ansible/ansible/issues/32617
00:03:30 <Kylie> 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 <nitzmahone> It can either be done via ansible.cfg or the envvars I mentioned in that issue.
00:04:20 <nitzmahone> ansible.cfg is probably the better way for most folks but just depends
00:05:08 <nitzmahone> The ideal setup is that the Ansible *content* doesn't need to know about the module masking and separate distributions
00:05:40 <nitzmahone> 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 <nitzmahone> 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 <Kylie> how to modify env vars within a Role? Any guidance?
00:06:32 <nitzmahone> You don't
00:06:49 <jborean93> You have to modify it before calling ansible-playbook
00:06:53 <nitzmahone> That'd be done on the host running Ansible
00:07:27 <nitzmahone> 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 <Kylie> Then it means we need to ask customer change env vars by themselves.
00:08:32 <nitzmahone> There's no great solution to this today, but it's better to handle outside of the content.
00:09:32 <nitzmahone> The installer stuff that's slated for 2.5 *should* make this a lot easier, but it's still being defined
00:11:36 <Kylie> 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 <Kylie> We could discuss it later. Since Yuwei, Tripdubroot are online, I would like to raise topic #2.
00:13:11 <nitzmahone> 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 <Kylie> Wonderful. Thank you Matt.
00:13:52 <Kylie> #topic PR requests for new modules.
00:14:47 <Kylie> tripdubroot submitted a PR for new module "key vault management".
00:15:47 <Kylie> Yuwei submitted new module for Azure image. Any else, Yuwei?
00:16:28 <Yuwei> No more new module from my side, but add some new features for existing modules
00:16:32 <jborean93> 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 <zikalino> finally managed to join, sorry i'm late...
00:18:21 <jborean93> welcome
00:18:31 <Kylie> Welcome
00:18:56 <nitzmahone> #action nitzmahone/jborean93 to review #32756, #32589
00:19:22 <nitzmahone> We'll take a look at those
00:19:24 <Kylie> 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 <nitzmahone> So there are a couple of 2.5 roadmap items currently on my plate:
00:20:13 <Kylie> Other two new modules are submitted for ACR and ACI. https://github.com/ansible/ansible/pull/32336
00:20:27 <Kylie> https://github.com/ansible/ansible/pull/32025
00:20:41 <Yuwei> Also there is a bug fix: https://github.com/ansible/ansible/pull/32614
00:22:12 <nitzmahone> #action nitzmahone/jborean93 review #32336, 32535, 32025, 32614
00:22:48 <zikalino> 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 <jborean93> It is best to split into smaller chunks as possible
00:23:22 <jborean93> Makes it easier to review when the changes/additions aren't too large
00:23:33 <nitzmahone> Or serialize them
00:23:57 <nitzmahone> (eg if there are shared module_utils, merge those things first and one module)
00:24:17 <nitzmahone> Then add other modules on as you see our feedback on things like UI
00:24:29 <nitzmahone> What will the SQL modules be doing?
00:25:08 <zikalino> everything related to Azure SQL support, starting from servers, databases, etc.
00:25:44 <nitzmahone> OK- do you anticipate the need for new shared code amongst the modules?
00:26:28 <zikalino> no, just using existing azure shared code atm
00:26:31 <nitzmahone> ok
00:27:32 <nitzmahone> 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 <zikalino> 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 <nitzmahone> Right, but we're still a ways off from release yet. Module freeze is Jan 30 IIRC
00:29:05 <nitzmahone> Doesn't really matter when they land in devel so long as you've got a workable set by freeze
00:29:14 <zikalino> ok, i will then create 2 PRs first, one for servers one for databases (each of them including facts)
00:29:20 <nitzmahone> Sounds good
00:29:36 <nitzmahone> 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 <zikalino> ok, i will try :-)
00:30:47 <Kylie> #topic v2.5 roadmap for Azure.
00:30:48 <Kylie> 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 <nitzmahone> 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 <nitzmahone> Neither- that's what the working group wiki is for
00:31:25 <Kylie> Ok.
00:31:25 <nitzmahone> The roadmap is about stuff Red Hat is writing
00:31:53 <nitzmahone> So this stuff should definitely be reflected there- just really high level and maybe who's working on it + ETA
00:32:29 <zikalino> "cleaning up the results from the modules" - do you have any more info on this? what shoudl be returned prefereably?
00:32:40 <nitzmahone> 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 <nitzmahone> Module results can be a bit of an art
00:33:27 <nitzmahone> Basic ideas:
00:33:42 <nitzmahone> * don't duplicate things that were passed as args to the module in results
00:33:59 <nitzmahone> * only return things that are actionable/usable by downstream modules
00:34:11 <nitzmahone> (eg, "forensic" stuff is better returned by diff mode)
00:34:52 <nitzmahone> 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 <jborean93> We also want to try and avoid deeply nested results, try to keep dictionaries only at the root level
00:35:03 <nitzmahone> (anything beyond "changed", that is)
00:35:07 <zikalino> ok, so basically, that "verbose" output should be just returned by _facts only?
00:35:22 <nitzmahone> Yep
00:35:44 <zikalino> and in the main module we should be selective and flatten / minimise the response
00:36:23 <zikalino> ok, that sounds good
00:36:42 <nitzmahone> 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 <nitzmahone> #action zikalino (and others on MS side) to update community Wiki with basic info on work in progress
00:38:09 <Kylie> Yes.
00:38:43 <Kylie> Then how Red Hat add those stuff to overall roadmap? I assume you will take care of it. Right?
00:41:01 <nitzmahone> 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 <nitzmahone> group stuff for that subject area
00:42:25 <nitzmahone> 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 <nitzmahone> (so having us managing that for N working groups is prohibitive)
00:43:50 <Kylie> Got it.
00:44:10 <Kylie> Thank you. Then that's all from my side.
00:44:58 <nitzmahone> FYI: roadmap board (filtered for Azure) is at https://github.com/ansible/ansible/projects/9?card_filter_query=azure
00:45:47 <nitzmahone> #info Red Hat Ansible Azure roadmap for 2.5 https://github.com/ansible/ansible/projects/9?card_filter_query=azure
00:46:05 <nitzmahone> Nothing else for me- shall we call it a meeting?
00:46:52 <jborean93> I'm good
00:46:55 <nitzmahone> 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 <nitzmahone> So Kylie, are you comfortable running the next one, or do you want me to do it again?
00:47:54 <Kylie> I could do it next one. Thank you Matt.
00:48:08 <nitzmahone> (so it'd be (hash)`startmeeting Azure Working Group` every time to ensure they're collected in the same place
00:48:32 <nitzmahone> OK, thanks all- we'll try to get those reviews knocked out in the next couple days
00:48:35 <nitzmahone> #endmeeting