00:00:09 <Kylie_> #startmeeting Azure Working Group
00:00:09 <zodbot> Meeting started Thu Nov 30 00:00:09 2017 UTC.  The chair is Kylie_. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
00:00:09 <zodbot> The meeting name has been set to 'azure_working_group'
00:00:44 <Kylie_> #chair jborean93
00:00:44 <zodbot> Current chairs: Kylie_ jborean93
00:00:56 <Kylie_> #chair nitzmahone
00:00:56 <zodbot> Current chairs: Kylie_ jborean93 nitzmahone
00:00:59 <jborean93> Hi
00:00:59 <nitzmahone> o/
00:01:15 <Kylie_> Hi Matt and Jordan
00:01:24 <Kylie_> We have many topics today:)
00:01:37 <Kylie_> #topic playbook role with latest Azure module
00:02:15 <Kylie_> It is ok to ship latest Azure module. But modules will call azure_rc_common.py which cannot be packaged.
00:03:07 <nitzmahone> It can; just add a `module_utils` dir in the role
00:03:16 <Kylie_> To get latest modules work with 2.4, some additional APIs are needed to add to common.py. Is it acceptable to add such a bug fix into 2.4 small version?
00:03:30 <nitzmahone> (module_utils are pluggable like everything else since 2.2 or 2.3 IIRC)
00:03:43 <Kylie_> Great to know. Thank you Matt
00:04:08 <Kylie_> Do you know what is the schedule of 2.4.2-1.0? Now it is -0.5 rc1.
00:04:17 <nitzmahone> Let me know if you have any trouble with that, but should work fine (though be careful not to introduce changes that might break the modules "in the box", since they'll use the overridden one too)
00:04:27 <nitzmahone> It just shipped today
00:04:53 <nitzmahone> 2.4.3 will likely be mid-January to early-February
00:05:26 <Kylie_> Ok. Then we will start from 2.4.2-1.0.
00:06:49 <Kylie_> #topic PR review
00:06:55 <zikalino> hello, just joined a few mins ago
00:07:09 <Kylie_> Good timing. Zim, any question or request about PRs?
00:07:41 <zikalino> from my side i have been working on fixes in ACR, ACI (now renamed) and SQL Server
00:08:06 <Kylie_> Zim, do you have any question to Jordan or Matt here?
00:08:33 <zikalino> i think perhaps i missed a few minor things, but they are ready for second round of review
00:09:17 <nitzmahone> OK; if you haven't already, can you comment `ready_for_review` on those?
00:09:28 <zikalino> ah, ok, i will do
00:10:16 <zikalino> and btw, right after SQL modules i will submit MySQL And PostgreSQL modules (there was question in one of review comments about other databases)
00:11:29 <jborean93> yes I was wondering whether we wanted to have separate modules for each type
00:11:33 <jborean93> or one module per type
00:11:57 <nitzmahone> If the API is different, I'd probably vote for one per type
00:12:36 <jborean93> zikalino: is the API different, or do you just pass a different type parameters, with the potential for args per type?
00:12:43 <zikalino> i would go for one module per type, as they may have different options, especially SQL has very different options
00:13:27 <nitzmahone> Yeah, if the docs would be a bunch of "only applies to DBs X,Y,Z" then definitely +1 to separate
00:13:48 <jborean93> no worries, just wanted to check
00:14:21 <zikalino> i actually have one question (not technical really), what is the criteria for including modules in core ansible versus releasing them via ansible roles?
00:15:18 <nitzmahone> ...
00:15:41 <nitzmahone> Tough to answer that one
00:16:05 <nitzmahone> We're probably moving in a direction where the only modules we'll ship in the box are the core modules we maintain
00:16:24 <nitzmahone> ... and maybe a handful of certified modules, either in the core distribution or a separate one
00:16:46 <nitzmahone> And others would just live in a package repo that's easy to install (galaxy++)
00:17:21 <nitzmahone> So meantime, if it's something that's generally useful, we'll usually accept it for inclusion
00:18:17 <nitzmahone> Would solve the problem of "missing the bus" for a release and allow module authors both the flexibility to release whenever they want and to add features whenever they want without our approval.
00:19:02 <nitzmahone> (while still making it easy for users to get the modules- that's the part that's pretty sketchy today)
00:19:49 <Kylie_> What's is the criteria for back fix backported to 2.4 minor version?
00:19:52 <nitzmahone> My understanding is that the only reason y'all were wanting to release via Galaxy is to give users an easy way to try out modules/features that hadn't been shipped in Ansible yet
00:20:00 <zikalino> so perhaps releasing some modules via galaxy would be better, and then just tracking download number, and promoting to the core if become very popular
00:20:19 <nitzmahone> That'd be fine
00:20:50 <nitzmahone> Kylie_: basically anything that doesn't constitute a new feature is eligible for backport, it just needs to be requested.
00:21:38 <Kylie_> Ok. thanks.
00:22:02 <Kylie_> Yuwei, zim, any other question about PR before we moving to next topic?
00:22:15 <zikalino> actually one
00:22:42 <nitzmahone> Best thing to do is once it's been merged into devel, create a PR to stable-2.4 with the fix cherry-picked and a brief CHANGELOG entry; the release manager for 2.4 will review and usually merge once tests pass.
00:23:24 <zikalino> i have noticed that some modules have broken examples (in fact half of azure moudules have broken examples), so i was wondering if anyone considered adding example check to sanity tests.
00:23:29 <nitzmahone> (usually use `git cherry-pick -x [sha]` so it will include the original SHA in the commit- also the reason to wait until it's been merged to devel, since we mostly always squash commits.
00:24:31 <nitzmahone> We've discussed it, but a lot of samples aren't necessarily workable standalone, and can potentially take a lot of time/resources to execute...
00:24:50 <Kylie_> Understand. Thank you Matt. If we want to add APIs in azure_rc_common.py, is it a bug fix level or feature level?
00:24:53 <jborean93> nevertheless, if we can test those examples in the integration tests we should though
00:25:21 <nitzmahone> That'd probably be considered a feature...
00:25:45 <nitzmahone> Better to ship your own copy of azure_rm_common in your role if that's what you need
00:26:04 <nitzmahone> Shouldn't generally be a reason to add APIs to module_utils if you're not adding new modules/features
00:26:12 <zikalino> ok, i will try to add sanity test when i find some time.
00:26:30 <Kylie_> #Bug fix approval
00:26:42 <Kylie_> #topic bug fix approval
00:28:05 <Kylie_> Last time, we discussed whether Zim, Yuwei as Azure module maintainer could approve small bug fix PR? Not sure whether this can be controlled (not sure ansibot can recognize it or not through tag??)
00:28:40 <Kylie_> How to define small? bug fix which will not change common file in other folders?
00:29:19 <nitzmahone> As far as the bot's concerned, you all have the same rights; two `shipit`s on an Azure module change from two authorized maintainers will cause the bot to merge.
00:30:02 <nitzmahone> So long as it's passing tests and doesn't have any outstanding Github reviews
00:30:05 <jborean93> I think because some are certified modules they won't be merged until someone from the core approved it
00:30:41 <nitzmahone> Yeah, that's probably true
00:31:37 <nitzmahone> So basically the ones we wrote (anything with `supported_by: certified` in the metadata) will require one of us to hit merge
00:31:53 <nitzmahone> But all the new ones you have full control over
00:31:57 <Kylie_> what are the certified modules? all under lib/ansible/modules/cloud/azure? Or modules out of this folder?
00:32:16 <jborean93> The metadata at the beginning of the module state whether they are certified or not
00:32:24 <nitzmahone> @thaumos might be able to shed more light on what that really means
00:32:44 <nitzmahone> Basically though, the modules that existed as of 2.3 are all certified IIRC
00:33:15 <nitzmahone> (the original set that were written by Red Hat employees)
00:34:00 <nitzmahone> We can talk about changing that- I think there will eventually be bot control over that, but I don't believe it's there today.
00:34:26 <thaumos> yes, something we'll definitely have to discuss.
00:34:31 <Kylie_> Quickly run a check. See supported_by: certified in lib/ansible/modules/cloud/azure/azure_rm_virtualnetwork_facts.py and some.
00:35:01 <thaumos> @Kylie_ we can discuss offline what certified means.
00:35:05 <Kylie_> Then who will decide to add "certified" in metadata field for a module? The author of the module?
00:35:18 <thaumos> let's discuss offline
00:36:07 <Kylie_> Ok. Hi thaumos, discuss on freenote? or email?
00:36:12 <thaumos> email
00:36:44 <Kylie_> Your email? Can you ping me (kyliel@microsoft.com)? Thank you.
00:37:05 <Kylie_> #topic meeting
00:37:14 <Kylie_> Jordan, what is your time now?
00:37:29 <Kylie_> I noticed you comment on https://github.com/ansible/community/pull/280?
00:37:40 <jborean93> 10:40am
00:37:44 <Kylie_> I thought 00:00 of UTC is my 8am, your 10am?
00:38:11 <jborean93> I think the issue is that you have said midnight of the previous day as it is the night of the previous day
00:38:44 <jborean93> So right now it is 0038 UTC time of Thursday morning (night of Wednesday)
00:38:50 <jborean93> Is that right?
00:41:21 <jborean93> if it is, then the day would be Thursday and not Wednesday
00:41:43 <Kylie_> Ok. SO 00:00 of Thursday. Thank you for reminder.
00:42:17 <Kylie_> I also would like to consult you about the meeting is how to attract other contributors join us?
00:42:22 <Kylie_> Any experience?
00:43:18 <Kylie_> Sorry for overrunning today meeting. I have another topic about documentation. We could put it to next meeting.
00:43:18 <jborean93> not too much, usually we point people to the github community page which contains the meeting info and ask them to come along
00:43:38 <Kylie_> understand. Thank you.
00:43:44 <jborean93> If you are aware of any meetups is various locations you could also have someone do a brief spiel there
00:44:00 <Kylie_> Great idea.
00:44:03 <Kylie_> Any other topic?
00:44:37 <jborean93> not from me
00:44:45 <nitzmahone> nope
00:44:58 <Kylie_> Thank you.
00:45:00 <Kylie_> #endmeeting