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