00:01:06 <jborean93> #startmeeting Ansible Azure Working Group
00:01:06 <zodbot> Meeting started Thu Jan 31 00:01:06 2019 UTC.
00:01:06 <zodbot> This meeting is logged and archived in a public location.
00:01:06 <zodbot> The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:01:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
00:01:06 <zodbot> The meeting name has been set to 'ansible_azure_working_group'
00:01:11 <jborean93> howdy all
00:04:28 <zikalino82> hi all :-)
00:04:39 <jborean93> #chair zikalino82
00:04:39 <zodbot> Current chairs: jborean93 zikalino82
00:04:40 <jborean93> hey
00:06:02 <zikalino82> a kind of silent today. we almost have chinese new year holidays here
00:06:08 <jborean93> ahh ok
00:06:24 <jborean93> Matt is feeling a bit under the weather today as well so he won't be joining
00:06:25 <zikalino82> i just have 3 prs for review
00:07:30 <zikalino82> two devtest labs modules: https://github.com/ansible/ansible/pull/51462
00:07:50 <zikalino82> super simple vmss instance module https://github.com/ansible/ansible/pull/51461
00:08:02 <zikalino82> it just has one option right now, so it's super simple
00:08:02 <jborean93> heh, the devtest one is causing some issues in CI right now
00:08:10 <jborean93> it automatically puts a delete lock on the resources
00:08:42 <zikalino82> and upgraded cosmos db https://github.com/ansible/ansible/pull/47181
00:08:54 <zikalino82> yes, dtl service is a kind of weird in many ways.......
00:10:56 <jborean93> yea, currently modifying our cleanup script to be able to handle it
00:11:38 <zikalino82> i think when the test is not failing it should clean up properly
00:12:03 <zikalino82> but i have to admit i have one instance of the lab right now which i can't delete in any way, even through the portal
00:12:07 <jborean93> the trouble is that our cleanup script is trying to delete the resource group but there are some locks on the child resource
00:12:24 <jborean93> so we need to handle that exception, remove the locks on whatever has it and then delete the group again
00:12:58 <zikalino82> i think also, dtl may create some resource groups on its own
00:13:55 <jborean93> is that NetworkWatcherRG?
00:14:55 <jborean93> that looks like it's for something else
00:19:49 <zikalino82> well, i will do some more checks on that, i just saw some random resources
00:20:46 <Kylie_> Hi all, sorry for late. Just confirmed our blog for Ansible solution template in Azure Marketplace was live - https://azure.microsoft.com/en-us/blog/ansible-solution-now-available-in-the-azure-marketplace/.
00:22:18 <jborean93> cool, will have a look at it later today
00:24:31 <jborean93> I do need to talk about https://hub.docker.com/r/microsoft/ansible
00:25:12 <Kylie_> I think this is used by Ansible extension.
00:25:42 <jborean93> here is the Dockerfile that creates it https://github.com/VSChina/vscode-ansible/blob/master/docker/Dockerfile_latest
00:26:02 <jborean93> the docker container `ansible/ansible:ubuntu1604` is deprecated and should not be used to generate this image
00:26:31 <zikalino82> yes
00:27:04 <zikalino82> i think we could switch to centos as well
00:27:38 <jborean93> Is there a reason why you chose that container
00:27:41 <jborean93> as the source
00:28:08 <zikalino82> i don't think there's any specific reason
00:28:23 <Kylie_> Ansible cannot be installed on Windows (except Ubuntu sub on Windows).
00:29:07 <Kylie_> This is to provide a way to run Ansible in container environment whatever your lcoal machine is Windows or not.
00:29:11 <zikalino82> yes, maybe that's why we stick to the same version...
00:29:12 <jborean93> yep, the trouble is that the source container is not maintained by us and isn't designed to be used in this case
00:29:39 <jborean93> you should be maintaining your own from the base container image from Centos, Ubuntu, etc
00:29:59 <jborean93> you can use our test containers as a reference to see how we do it but I would use them as the FROM part https://github.com/ansible/distro-test-containers/blob/master/ubuntu1804-test-container/Dockerfile
00:30:02 <zikalino82> yes, that can be done easily
00:30:40 <Kylie_> Double confirm, you mean you guys don't own images on ansible/ansible in dockerhub. Right?
00:30:56 <jborean93> we did but they are older images that aren't maintained
00:31:14 <jborean93> we now use quay.io to host our test images but they still shouldn't be used for this scenario as a base
00:32:05 <jborean93> you can use that link I gave you as a guideline to create your own/chop and change whatever you need to include the Azure deps
00:32:21 <Kylie_> I see. Thank you.
00:32:57 <Kylie_> For each Ansible release, will the Ansible team test its installation on major LInux distro (e.g. RHEL latest versions, CentOS, Ubuntu)?
00:33:26 <zikalino82> it's tested by ci
00:33:31 <jborean93> yep
00:33:54 <jborean93> this has our matrix of tests https://github.com/ansible/ansible/blob/devel/shippable.yml
00:34:19 <jborean93> Cloud stuff isn't tested on each distro but it shouldn't really matter there
00:34:29 <Kylie_> Do you also verify ansible[azure] on them?
00:34:52 <jborean93> no, cloud tests are done on a single distro but on both Python 2 and 3
00:35:00 <jborean93> those modules shouldn't be affected by distro changes
00:35:15 <Kylie_> There is a thread to discuss python depdencies  on RHEL8 ( I have not read all details yet).
00:35:30 <Kylie_> What is that single distro?
00:35:53 * jborean93 checks
00:36:28 <mattclay> Ubuntu 16.04 is the base for our image used to test cloud modules.
00:36:37 <jborean93> thanks
00:37:04 <mattclay> But the distro doesn't really matter, since everything is installed via pip.
00:37:28 <mattclay> The cloud tests aren't intended to test distro specific behavior.
00:37:44 <mattclay> We're mostly interested in testing Python 2.x (currently 2.7) and 3.x (currently 3.6).
00:39:09 <mattclay> We're using Ubuntu 16.04 as the base for our cloud testing container because it's trivial to install Python 2.6, 2.7, 3.5, 3.6 and 3.7 in the container.
00:39:39 <Kylie_> Do you have any plan to validate them on RHEL family?
00:40:36 <jborean93> I would have thought that's not really something that's up to us
00:40:48 <jborean93> it's up to the packagers of the Azure Python SDK
00:41:06 <jborean93> Ansible is just a consumer of that
00:41:39 <Kylie_> I see. Thank you for information.
00:41:49 <Kylie_> I don't have other topics. Thanks.
00:42:58 <yuwei> btw, as py 2.7 will retire in th the end of this year. Is there any influence?
00:43:33 <mattclay> We'll continue testing on Python 2.7 until the distributions which ship with it are no longer supported.
00:43:57 <jborean93> and RHEL 7 will be around for a while
00:44:20 <mattclay> Although support from the Python Foundation is ending in 2020 for Python 2.7, there are distros which ship with Python 2.7 which will be supported past that -- thus Python 2.7 on those distros will still be supported.
00:44:34 <mattclay> The same goes for Python 2.6.
00:45:09 <yuwei> I see
00:46:45 <mattclay> We do make some exceptions for modules which are only capable of running on the controller (many of our network modules). All the rest of the modules are expected to support every python version that their dependencies support.
00:48:55 <yuwei> thanks! I don't have other topics
00:49:11 <jborean93> ok, will close the meeting if there's nothing else
00:49:50 <yuwei> oh one thing
00:50:22 <yuwei> next week we will in Chinese new year holiday, will not attend this meeting
00:50:45 <jborean93> no worries, hope you have a good time
00:50:54 <yuwei> Thanks
00:53:55 <jborean93> have a good one everyone
00:53:58 <jborean93> #endmeeting