00:01:10 #startmeeting Ansible Azure Working Group 00:01:10 Meeting started Thu Jun 21 00:01:10 2018 UTC. 00:01:10 This meeting is logged and archived in a public location. 00:01:10 The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 00:01:10 The meeting name has been set to 'ansible_azure_working_group' 00:01:43 #chair Kylie_ jborean93 yuwei 00:01:43 Current chairs: Kylie_ jborean93 nitzmahone yuwei 00:01:53 hey 00:02:31 Hi Matt and Jordan, firstly I would like to check with you whether Ansible 2.6 is on track to be released on 6/28? 00:02:38 Tis the plan, yep 00:03:06 Nice. 00:03:25 Zim and Catherine, are you online? 00:03:50 I know they have a topic. They want to listen to your feedback about their proposals for AnsibleFest. 00:04:00 #chair zikalino82 00:04:00 Current chairs: Kylie_ jborean93 nitzmahone yuwei zikalino82 00:04:09 hello, seems like i am a little bit late 00:04:10 Zim, do you want to share your proposal for AnsibleFest here? 00:04:34 yes, i guess i can share here 00:04:38 Session Title 00:04:39 ible. 00:04:42 ST API 00:04:57 still working on refining it... 00:05:24 Looks like a formatting issue there- can't read what that says 00:05:55 hello 00:06:10 oh, i don't know, i see it correctly here... 00:06:23 ible. ST API is all I saw 00:06:34 Hi Catherine. You and Zim could share your proposals for AnsibleFest here. 00:06:38 i will send you an e-mail 00:06:39 ok 00:06:40 me too. 00:07:00 my session title is: Ansible resource secrets management with Azure Key Vault 00:07:09 sent 00:07:20 session description: Ansible user need store secrets like SSH keys on control machines. This introduces security concern, big maintenance effort, and complex key rolling operation. This session will describe Ansible integration with Azure Key Vault: Keep secrets in Azure Key Vault, a cloud service that works as a secure secrets store. Ansible retrieves secrets from Azure on matter where ansible is running. The integration 00:08:20 nitzmahone have you received? 00:08:36 anyone talking? am i dropped out? 00:08:36 yep 00:09:05 @yungezz can you talk about that for 45m? 00:09:35 Ideally that topic should take a couple minutes of introduction and a few minutes of demo- so what's the rest of the time? 00:09:38 yes. firstly the scenario, then how it works, then with a demo 00:10:05 how attendee will learn: - How to securely store resource secrets in Azure Key Vault, then use those secrets in Ansible. - How the integration works: syntax of secrets in ansible playbook, data flow of secrets retrieving. - VSCode Ansible extension: playbook authoring with auto-completion and running playbook from anywhere. Azure on Ansible status and roadmap 00:10:42 sorry, what attendee will learn 00:10:47 sounds like a bit more than just the key vault 00:11:14 OK cool 00:11:34 i want to combine others into one scenario, such as vscode extension etc. maybe i can update description to include those 00:12:26 If that's the primary thing, I'd stick with that, but leave the Ansible VSCode extension and stuff in the long description. 00:12:38 ok 00:12:59 maybe i would add word "additionaly" or something like that 00:13:18 It seems all are talks, no hands-on-lab. If there is hands-on-lab, we could guide developers how to use Ansible extension accelerate Ansible playbook development in VS Code. 00:14:15 We've talked about doing HoL kind of content before at Fest, but I don't think they're doing them yet 00:14:39 well i think "deep dive session" sounds like closest to hands-on 00:15:24 "deep dive" usually means code-level; probably not quite that involved 00:15:46 Like "how Ansible execution engine works" or something like that 00:16:48 @zikalino82 yours is maybe closer to a deep-dive, since it'll have raw-ish REST API stuff 00:16:53 i thought my topic should be in "deep dive" track 00:17:05 yes, exactly 00:17:53 @zikalino82 You probably want to clarify your session title with "with Ansible" somewhere just to be clear 00:19:19 yeah, we were wondering whether include Ansible or not in title, as this is Ansible conference so it's a kind of obvious, but i think you are right 00:20:17 Yeah, just so the reviewers are clear that you're not going to be up front with postman or something ;) 00:20:30 (demoing direct REST API calls) ;) 00:21:09 hehe, yes 00:21:16 @yungezz yours probably best belongs in the Best Practices or maybe Ansible Integrations track (but I'm not even 100% sure what that last one is) 00:22:26 ok，i thought it’s ansible integration, but let me look at best practice 00:22:52 I wouldn't worry about that part too much anyway- they'll shuffle things around as necessary. Content is more important 00:23:08 Got it 00:23:42 Anything else happening today? 00:23:46 Thank you Matt and Jordan for feedback. Very useful. The team are very excited for this event. 00:23:59 I have other 2 topics. 00:24:23 We received some feedback about inventory. 00:25:29 It took long to receive information about inventories. We will look into it. Here I am curious how about the performance in on-premise. Any similar issue or specific for cloud environment? 00:25:53 It's specific to Azure unfortunately 00:25:58 Shortcomings of the REST API 00:26:38 I have a prototype for the inventory plugin that uses the undocumented batch API (same way portal does) to make larger Azure dynamic inventories an order of magnitude faster 00:26:42 It will be in 2.7 00:27:11 Great to know it. So you also noticed this issue:). 00:27:28 Boto + AWS REST API lets us get things like IP addresses and power state in a single batch round trip, but Azure (public) API does not, so multiple round trips required for each host. 00:27:35 Oh yeah, since the beginning! 00:28:28 I talked with Laurent to see if SDK might support the batch API (not the same as the thing they call 'batch' today)- he was going to look into if it was allowed, but last I heard it was kinda "not really" 00:28:58 But I have a working prototype, and will change it to fall back to individual requests if the batch wrapper fails for some reason. 00:29:33 (good news is that the batch API the portal uses is a very old API version, like 2015 or something with no changes, so seems quite stable, just undocumented) 00:31:44 @Kylie_ you mentioned another topic? 00:31:58 Understand. It is really great to know it. Could you please share your prototype for inventory plugin to the team when you think it is a good timing? If needed, we could check with Azure computing team about batch API used by the portal. 00:32:15 And is it ok to write into the roadmap for 2.7? https://github.com/ansible/community/wiki/Azure%3A-Action-plan 00:32:31 yeah, it's already on the core Ansible roadmap, but you can duplicate there if you want 00:32:38 (should be published this week or next) 00:33:08 The other topic is about PRs. I am wondering where we are for vm facts and storage facts. 00:33:36 And Yuwei, Catherine and Zim, any PR you want to discuss this week? or do it next week after 2.6 is out? 00:34:04 so vm facts is here: https://github.com/ansible/ansible/pull/38279 00:34:16 i still make a few minor fixes. 00:34:42 and i am wondering about not having separate test, but just add it to vm test. i think tests are already too heavy. 00:34:46 @nitzmahone, understand. I will keep eye one it. It is a good news for Azure. 00:35:06 so i am thinking that just adding a few tasks in main vm test would be better solution. 00:35:07 Mine is still web app and key vault bug fixing 00:35:08 zikalino82: that sounds like a good idea 00:35:30 actually i think we should test all facts together with main modules. 00:35:54 And there are 2 contribution to azure inventory, I have reviewed them, better Matt or Jordan could have a look 00:35:56 my is route table and autoscaling new modules 00:36:07 @zikalino82 yeah, testing those together is good so we don't have to create even more VMs 00:36:26 .... and public ip addresses :-( 00:36:32 yep 00:37:35 would also have the added benefit of improving the vm module as well if you are testing the actual details of a vm 00:38:55 I think we don't want to merge the vm_facts module with the raw API response. We need to stop doing that 00:39:35 The amount of stuff someone has to do to get something simple like the IP address from the API response is just ridiculous 00:40:10 I thought the plan was to have an option that changed what was returned 00:40:27 but defaulted to the curated options 00:40:51 you mean, we shouldn't have raw option? 00:41:44 actually, to be honest, at some point, i just thought.... maybe we shoudn't. if somebody wants raw, they could use azure_resource_facts and REST 00:42:10 https://docs.ansible.com/ansible/2.5/modules/ec2_instance_module.html 00:42:10 I personally think it makes things simpler if we don't 00:42:10 but a kind of these 2 ideas appeared at the same time 00:42:35 ec2_instance gives all the necessary detail, as well as surfacing some of the most-used things at the top of the instance 00:42:55 Without extra API-ish layers of gunk that users don't care about 00:43:07 Could we document best practice or guidance how to write a facts module? 00:43:32 the only problem is how to upgrade old facts modules.... 00:44:03 yeah, goes back to the "return_type" value or something 00:44:16 for the old facts module it would be a matter of returning both and slowly deprecating the old return values 00:44:33 but that would require some more logic to warn users they are using a deprecated return value 00:44:36 once we have proper return types, we can default to the old value, then deprecate it so people know they need to switch to the new ones 00:45:44 (so they'll get a runtime warning that says something like "return_type: raw is deprecated; switch to return_type: curated" or whatever we want to call it 00:46:04 Yeah, a few different ways we could deal with it. 00:46:08 yes, so let's stick to these values, and just start deprecating raw 00:46:25 I scrubbed a core feature for deprecating return values in favor of working on Azure Stack support in 2.7 00:46:34 yep, still a good reason to ensure we are designing the vm facts module correctly 00:46:44 (for adding warnings on usage of deprecated return values) 00:46:46 instead of just getting something in and feeling the pain later 00:46:49 exactly 00:48:57 Zim, you will start to take vacation soon. Could you please help have a version for vm facts before your vacation? 00:49:12 yes, then i will do 2 things: 1) remove format option from vm facts 2) move tests to main module test 00:49:24 it's mostly about removing things now :-) 00:50:28 Thank you. 00:50:41 OK- anything else for today? 00:50:46 Then we will leave other PRs (web app, route table...) to next meeting. 00:50:50 No from me. 00:50:54 Thank you all. 00:50:57 I'm good 00:51:06 thx 00:51:07 OK, thanks all! 'til next week! 00:51:11 #endmeeting