00:01:10 <nitzmahone> #startmeeting Ansible Azure Working Group
00:01:10 <zodbot> Meeting started Thu Jun 21 00:01:10 2018 UTC.
00:01:10 <zodbot> This meeting is logged and archived in a public location.
00:01:10 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:01:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
00:01:10 <zodbot> The meeting name has been set to 'ansible_azure_working_group'
00:01:43 <nitzmahone> #chair Kylie_ jborean93 yuwei
00:01:43 <zodbot> Current chairs: Kylie_ jborean93 nitzmahone yuwei
00:01:53 <jborean93> hey
00:02:31 <Kylie_> 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 <nitzmahone> Tis the plan, yep
00:03:06 <Kylie_> Nice.
00:03:25 <Kylie_> Zim and Catherine, are you online?
00:03:50 <Kylie_> I know they have a topic. They want to listen to your feedback about their proposals for AnsibleFest.
00:04:00 <nitzmahone> #chair zikalino82
00:04:00 <zodbot> Current chairs: Kylie_ jborean93 nitzmahone yuwei zikalino82
00:04:09 <zikalino82> hello, seems like i am a little bit late
00:04:10 <Kylie_> Zim, do you want to share your proposal for AnsibleFest here?
00:04:34 <zikalino82> yes, i guess i can share here
00:04:38 <zikalino82> Session Title
00:04:39 <zikalino82> ible.
00:04:42 <zikalino82> ST API
00:04:57 <zikalino82> still working on refining it...
00:05:24 <nitzmahone> Looks like a formatting issue there- can't read what that says
00:05:55 <yungezz> hello
00:06:10 <zikalino82> oh, i don't know, i see it correctly here...
00:06:23 <nitzmahone> ible. ST API is all I saw
00:06:34 <Kylie_> Hi Catherine. You and Zim could share your proposals for AnsibleFest here.
00:06:38 <zikalino82> i will send you an e-mail
00:06:39 <yungezz> ok
00:06:40 <Kylie_> me too.
00:07:00 <yungezz> my session title is: Ansible resource secrets management with Azure Key Vault
00:07:09 <zikalino82> sent
00:07:20 <yungezz> 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 <zikalino82> nitzmahone have you received?
00:08:36 <yungezz> anyone talking? am i dropped out?
00:08:36 <nitzmahone> yep
00:09:05 <nitzmahone> @yungezz can you talk about that for 45m?
00:09:35 <nitzmahone> 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 <yungezz> yes. firstly the scenario, then how it works, then with a demo
00:10:05 <yungezz> 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 <yungezz> sorry, what attendee will learn
00:10:47 <jborean93> sounds like a bit more than just the key vault
00:11:14 <nitzmahone> OK cool
00:11:34 <yungezz> i want to combine others into one scenario, such as vscode extension etc. maybe i can update description to include those
00:12:26 <nitzmahone> 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 <yungezz> ok
00:12:59 <zikalino82> maybe i would add word "additionaly" or something like that
00:13:18 <Kylie_> 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 <nitzmahone> 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 <zikalino82> well i think "deep dive session" sounds like closest to hands-on
00:15:24 <nitzmahone> "deep dive" usually means code-level; probably not quite that involved
00:15:46 <nitzmahone> Like "how Ansible execution engine works" or something like that
00:16:48 <nitzmahone> @zikalino82 yours is maybe closer to a deep-dive, since it'll have raw-ish REST API stuff
00:16:53 <zikalino82> i thought my topic should be in "deep dive" track
00:17:05 <zikalino82> yes, exactly
00:17:53 <nitzmahone> @zikalino82 You probably want to clarify your session title with "with Ansible" somewhere just to be clear
00:19:19 <zikalino82> 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 <nitzmahone> Yeah, just so the reviewers are clear that you're not going to be up front with postman or something ;)
00:20:30 <nitzmahone> (demoing direct REST API calls) ;)
00:21:09 <zikalino82> hehe, yes
00:21:16 <nitzmahone> @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 <yungezz> ok,i thought it’s ansible integration, but let me look at best practice
00:22:52 <nitzmahone> I wouldn't worry about that part too much anyway- they'll shuffle things around as necessary. Content is more important
00:23:08 <yungezz> Got it
00:23:42 <nitzmahone> Anything else happening today?
00:23:46 <Kylie_> Thank you Matt and Jordan for feedback. Very useful. The team are very excited for this event.
00:23:59 <Kylie_> I have other 2 topics.
00:24:23 <Kylie_> We received some feedback about inventory.
00:25:29 <Kylie_> 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 <nitzmahone> It's specific to Azure unfortunately
00:25:58 <nitzmahone> Shortcomings of the REST API
00:26:38 <nitzmahone> 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 <nitzmahone> It will be in 2.7
00:27:11 <Kylie_> Great to know it. So you also noticed this issue:).
00:27:28 <nitzmahone> 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 <nitzmahone> Oh yeah, since the beginning!
00:28:28 <nitzmahone> 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 <nitzmahone> 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 <nitzmahone> (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 <nitzmahone> @Kylie_ you mentioned another topic?
00:31:58 <Kylie_> 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 <Kylie_> 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 <nitzmahone> yeah, it's already on the core Ansible roadmap, but you can duplicate there if you want
00:32:38 <nitzmahone> (should be published this week or next)
00:33:08 <Kylie_> The other topic is about PRs. I am wondering where we are for vm facts and storage facts.
00:33:36 <Kylie_> 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 <zikalino82> so vm facts is here: https://github.com/ansible/ansible/pull/38279
00:34:16 <zikalino82> i still make a few minor fixes.
00:34:42 <zikalino82> 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 <Kylie_> @nitzmahone, understand. I will keep eye one it. It is a good news for Azure.
00:35:06 <zikalino82> so i am thinking that just adding a few tasks in main vm test would be better solution.
00:35:07 <yungezz> Mine is still web app and key vault bug fixing
00:35:08 <jborean93> zikalino82: that sounds like a good idea
00:35:30 <zikalino82> actually i think we should test all facts together with main modules.
00:35:54 <yungezz> And there are 2 contribution to azure inventory, I have reviewed them, better Matt or Jordan could have a look
00:35:56 <yuwei> my is route table and autoscaling new modules
00:36:07 <nitzmahone> @zikalino82 yeah, testing those together is good so we don't have to create even more VMs
00:36:26 <zikalino82> .... and public ip addresses :-(
00:36:32 <nitzmahone> yep
00:37:35 <jborean93> 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 <nitzmahone> 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 <nitzmahone> 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 <jborean93> I thought the plan was to have an option that changed what was returned
00:40:27 <jborean93> but defaulted to the curated options
00:40:51 <zikalino82> you mean, we shouldn't have raw option?
00:41:44 <zikalino82> 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 <nitzmahone> https://docs.ansible.com/ansible/2.5/modules/ec2_instance_module.html
00:42:10 <jborean93> I personally think it makes things simpler if we don't
00:42:10 <zikalino82> but a kind of these 2 ideas appeared at the same time
00:42:35 <nitzmahone> 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 <nitzmahone> Without extra API-ish layers of gunk that users don't care about
00:43:07 <Kylie_> Could we document best practice or guidance how to write a facts module?
00:43:32 <zikalino82> the only problem is how to upgrade old facts modules....
00:44:03 <nitzmahone> yeah, goes back to the "return_type" value or something
00:44:16 <jborean93> for the old facts module it would be a matter of returning both and slowly deprecating the old return values
00:44:33 <jborean93> but that would require some more logic to warn users they are using a deprecated return value
00:44:36 <nitzmahone> 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 <nitzmahone> (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 <nitzmahone> Yeah, a few different ways we could deal with it.
00:46:08 <zikalino82> yes, so let's stick to these values, and just start deprecating raw
00:46:25 <nitzmahone> I scrubbed a core feature for deprecating return values in favor of working on Azure Stack support in 2.7
00:46:34 <jborean93> yep, still a good reason to ensure we are designing the vm facts module correctly
00:46:44 <nitzmahone> (for adding warnings on usage of deprecated return values)
00:46:46 <jborean93> instead of just getting something in and feeling the pain later
00:46:49 <nitzmahone> exactly
00:48:57 <Kylie_> Zim, you will start to take vacation soon. Could you please help have a version for vm facts before your vacation?
00:49:12 <zikalino82> yes, then i will do 2 things: 1) remove format option from vm facts 2) move tests to main module test
00:49:24 <zikalino82> it's mostly about removing things now :-)
00:50:28 <Kylie_> Thank you.
00:50:41 <nitzmahone> OK- anything else for today?
00:50:46 <Kylie_> Then we will leave other PRs (web app, route table...) to next meeting.
00:50:50 <Kylie_> No from me.
00:50:54 <Kylie_> Thank you all.
00:50:57 <jborean93> I'm good
00:51:06 <yuwei> thx
00:51:07 <nitzmahone> OK, thanks all! 'til next week!
00:51:11 <nitzmahone> #endmeeting