19:01:32 <decentral1se> #startmeeting Ansible Molecule Working Group
19:01:32 <zodbot> Meeting started Wed Feb 20 19:01:32 2019 UTC.
19:01:32 <zodbot> This meeting is logged and archived in a public location.
19:01:32 <zodbot> The chair is decentral1se. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:32 <zodbot> The meeting name has been set to 'ansible_molecule_working_group'
19:01:43 <decentral1se> #info Agenda https://github.com/ansible/community/labels/molecule
19:01:49 <decentral1se> so, who is around?
19:01:55 <decentral1se> let's get some chairs going
19:02:01 <themroc> \o<
19:02:06 <zbr> hi!
19:02:37 <fabianvf> howdy
19:03:13 <decentral1se> #chair themroc zbr fabianvf
19:03:13 <zodbot> Current chairs: decentral1se fabianvf themroc zbr
19:03:21 <tima> hello.
19:03:32 <decentral1se> #chair tima
19:03:32 <zodbot> Current chairs: decentral1se fabianvf themroc tima zbr
19:03:43 <Goneri> #chair goneri
19:04:00 <decentral1se> hmmmm
19:04:04 <decentral1se> #chair goneri
19:04:04 <zodbot> Current chairs: decentral1se fabianvf goneri themroc tima zbr
19:04:23 <decentral1se> achieving maximum velocity
19:04:42 <decentral1se> so, what's up for discussion?
19:04:47 <decentral1se> I saw https://github.com/ansible/community/issues/427#issuecomment-465603717 was pretty comprehensive
19:05:24 <themroc> argh i have a baby crying situation :/ i prepared topics in aforementioned link
19:05:34 <themroc> brb
19:06:05 <smyers> here, albeit slightly late
19:06:27 <decentral1se> #chair smyers
19:06:27 <zodbot> Current chairs: decentral1se fabianvf goneri smyers themroc tima zbr
19:06:39 <decentral1se> no worries themroc
19:06:58 <decentral1se> ok, let's move through the topics you prepared
19:07:18 <decentral1se> #topic final issues for v2.20 release
19:07:44 <decentral1se> #info https://github.com/ansible/molecule/issues/1609
19:07:50 <decentral1se> #info https://github.com/ansible/molecule/pull/1691
19:07:57 <decentral1se> #info https://github.com/ansible/molecule/issues/1727
19:09:08 <decentral1se> AFAIK, we wanted to push #1609 to v2.21 because we were not getting a reply from @retr0h
19:10:00 <tima> what reply to we need from @retr0h?
19:11:18 <tima> Re: 1609? (I'm not seeing what we need from him.)
19:11:41 <smyers> As I read it, it looks like #1609 will be fixed with the next release. What am I missing? #1616 mentions retr0h, but also is determined in-issue to not be a blocker
19:11:46 <decentral1se> ah, yes, it was being tracked also in #1616
19:11:47 <decentral1se> #info https://github.com/ansible/molecule/issues/1616
19:11:56 <zbr> i propose to use same values as ansible package, unless we get feedback that something else is desired. we can always fix it later.
19:12:06 <decentral1se> ah, I see https://github.com/ansible/molecule/issues/1616#issuecomment-461166084
19:12:28 <decentral1se> we're good to move on then?
19:12:28 <tima> ah yes. Seeing that now.
19:12:36 <tima> Hadn't clicked thru.
19:12:53 <tima> +1 @zbr
19:13:47 <decentral1se> #agreed resolve #1609 by using same values as ansible
19:13:51 <tima> I can take up pinging @retr0h. I have his contact info from working through the adoption.
19:14:27 <decentral1se> oh really? nice, thanks, that would be gree
19:14:29 <decentral1se> great*
19:14:47 <decentral1se> #agreed tima to chase up @retr0h regarding #1609
19:15:01 <decentral1se> ok, #1691
19:15:02 <decentral1se> #info https://github.com/ansible/molecule/pull/1691
19:15:16 <decentral1se> themroc: you about?
19:16:44 <decentral1se> it's looks mergeable then, no?
19:17:57 <zbr> weird... I did a "python setup.py sdist" and one CPU core seems to get stuck forever.
19:18:26 <zbr> now I dicovered few ugly things: source distribution contains a 10MB mollie.psd file,.... wth!
19:18:48 <zbr> i doubt we need to include assets in sdist
19:19:32 <zbr> the final tar.gz was ~4MB which is huge, imho.
19:20:21 <smyers> #1691 looks mergeable, provided no further changes are requested, but given what it's changing and that travis liked it it seems good to go
19:20:28 <mjohnson> decentral1se: thats the *one* variation i didn't try. Thanks!
19:20:32 <mjohnson> decentral1se++
19:20:43 <tima> @decentralise I don't see why not: Re:1691
19:20:57 <decentral1se> solid, thanks folks, I'll merge #1691
19:21:12 <decentral1se> ok, #1727
19:21:18 <decentral1se> #info https://github.com/ansible/molecule/issues/1727
19:21:29 <decentral1se> can we push this out to v2.21?
19:23:13 <zbr> decentral1se: +1 to move to next. supporting devel is not a priority.
19:23:36 <decentral1se> yeah, agreed and it seems well triaged, so we'll get a fix when it comes
19:24:03 <decentral1se> #agreed push #1721 out to v2.21
19:24:06 <tima> i think we have to push 1727 out.
19:24:13 <tima> cool.
19:24:18 <decentral1se> nice :)
19:24:22 <decentral1se> I should wait a bit hehe
19:24:50 <decentral1se> ok, further topics? There is a lot of triage on that ticket from themroc
19:24:53 <tima> the use of testinfra and its implementation is a much bigger issue we'll need to address soon, but not now.
19:25:05 <decentral1se> any PRs we want to prioritise for people present?
19:25:26 <decentral1se> tima: fair enough, please raise a ticket with your thoughts if you fancy, would be happy to hear
19:25:38 <decentral1se> you also worked on this project before or?
19:25:47 <tima> @decentral1se: for 2.3 or 2.2.1?
19:26:04 <themroc> 1691, yes mergeable, last fix done this afternoon, and build got green
19:26:32 <decentral1se> themroc: merged :)
19:26:52 <tima> I was the Ansible PM that evaluated molecule and worked through the adoption process here and with @retr0h and Cisco.
19:26:52 <decentral1se> well it's open floor really tima - I feel like we have v2.20 ready to rip
19:27:04 <decentral1se> oh yeah, nice one! :)
19:27:11 <smyers> +1 2.20 :)
19:27:24 <tima> agreed @decental1se. I was just clarifying what you meant.
19:27:37 <smyers> If it's open floor, I could use feedback on https://github.com/ansible/molecule/pull/1739#issuecomment-465627829, but understand if you see the wall of text and run screaming.
19:27:51 <smyers> But, y'know, probably not right here right now
19:28:12 <zbr> before making the release can we please assure that we do not include assets in source distribution?
19:28:22 <decentral1se> #topic PR triage
19:28:37 <decentral1se> zbr: could you please raise an issue?
19:28:44 <zbr> sure
19:28:49 <decentral1se> thanks a lot
19:28:51 <decentral1se> #info https://github.com/ansible/molecule/pull/1739#issuecomment-465627829
19:28:56 <decentral1se> let's give this a look over then
19:30:09 <smyers> short version is that I had the idea that it'd be great to be able to use roles in create/destroy, and that thought has led me down an interesting path
19:30:57 <smyers> so before going nuts about it, I'd love to know things like "does this even sound like a good idea, worth pursuing?" :)
19:31:37 <fabianvf> I'm curious
19:32:01 <zbr> i have nothing against it as long it does not break things, sounds reasonable to do deps first.
19:32:10 <decentral1se> so our major issue here is that the destroy step removes the roles directory that is called by dependency
19:32:20 <decentral1se> %s/called/created/
19:32:50 <decentral1se> yeah, dependency first is a nice change, I think
19:33:41 <smyers> yeah, there's a prune method on molecule.commands.base.Base that cleans out the ephemeral dir on destroy, which seems like a great idea, but in cases where destroy is run before create, create will fail if it depends on a role
19:34:24 <smyers> another super simple option that I didn't mention in my ridiculous list of options is to just put dependency in the sequence again, but like all the things I've tried it just doesn't seem like a great solution
19:34:34 <themroc> hmm, i would say tradition requests make clean before make dep, so inverting all of that is not so evident
19:35:38 <smyers> yep, the pruning seems like a good idea to prevent previous-run cruft from skewing test results
19:35:55 <decentral1se> is the prune functionality the bulk of the destroy sequence? What does it do further? Blows aways the instances and?
19:36:17 <smyers> yeah, basically it runs the destroy playbook and prunes iirc
19:36:42 <themroc> that make all the sense of destroy btw: remove everuthing and start from scratch;  if the destroy stops removing dependencies then you could have bad surprises of the "works on my laptop" kind
19:36:43 <decentral1se> what is the purpose of the prune? To have a clean slate for re-download of dependencies?
19:37:00 <themroc> decentral1se, imho yes
19:37:16 <decentral1se> I see, right
19:37:50 <asmacdo> destroy first is helpful to me-- I require an external playbook that fails linting if it's there
19:37:51 <themroc> but given the fact that galaxy and gilt don't work the same way, impact is different
19:38:38 <smyers> It may have other side-effects, too. It cleans out anything in the ephemeral dir that isn't an inventory, state file, etc
19:38:41 <themroc> gilt keeps a cache of the external repositories outside the view, so destroy/recreate is not costly
19:38:48 <themroc> fir galaxy it's another story
19:39:57 <decentral1se> so, it seems this is not a case of "reorder and we're done"
19:40:16 <smyers> asmacdo, either configuring the linter to explicitly exempt that playbook rather than depending on the sequence timing seems like a good idea, since in that scenario you couldn't manually converge/verify/lint, only test would work I think
19:40:22 <themroc> indeed. i didn't even catch it before this meeting
19:40:35 <zbr> btw, i found something that worries me: requires-python = >=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*,!=3.5.*
19:40:40 <smyers> s/either//
19:40:43 <decentral1se> more brains and eyes = good :) :) :)
19:41:11 <zbr> this could be a huge issue with the new release: centos-7 has python-3.4 !!!
19:41:25 <smyers> but not 2.7?
19:41:35 <themroc> this is based on what ansible is supporting
19:41:41 <zbr> that last 2 conditions needs to be removed
19:42:02 <zbr> it will prevent installation on LOTS of systems.
19:42:20 <decentral1se> zbr: looks like another issue if you please
19:42:24 <decentral1se> nice catch
19:42:48 <zbr> decentral1se: found it while trying to fix the sdist package :p
19:43:01 <themroc> ansible supports 2.7, 3.5, 3.6, 3.7, we can't suppirt what ansible does not support
19:43:02 <decentral1se> hehe, you're down in the mud there alright :)
19:43:24 <decentral1se> themroc: ah, interesting
19:43:37 <decentral1se> smyers: looks like we're rather stumped on #1739 then as it looks
19:43:42 <jborean93> yea that won't change, Ansible is 2.7, 3.5+
19:43:47 <tima> sorry i'm dense and also getting up to speed on this. the issue is that destroy removes roles/ (what's in roles doesn't matter here)
19:44:15 <themroc> https://github.com/ansible/ansible/blob/devel/setup.py ->  python_requires='>=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*',
19:44:18 <zbr> people forget that we also have ansible 2.5! that is what we use on openstack now.
19:44:28 <smyers> destroy calls prune, prune cleans out all non-"safe" files from the ephemeral dir, which includes roles/
19:44:30 <decentral1se> tima: yep, that's it
19:44:34 <zbr> you cannot put there requirements of ansible 2.7.
19:45:13 <jborean93> zbr: 2.5 is about to go end of life relatively soon
19:45:14 <themroc> https://github.com/ansible/ansible/blob/stable-2.5/setup.py -> same
19:45:27 <themroc> python_requires='>=2.6,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*'
19:45:29 <jborean93> 3.5 was also the minimum py3 version supported
19:46:30 <zbr> I am saying: don't break the tool on purpose, we don't want to make enemies ;)
19:46:47 <jborean93> we are saying molecule can't support what Ansible doesn't
19:46:53 <zbr> there is a difference between not-supported and preventing execution.
19:47:03 <themroc> this python version discussion is coming on the table quite often, i guess it is not enough visible on the ansible documentation :)
19:47:31 <jborean93> https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#control-machine-requirements << right there
19:47:53 <decentral1se> smyers: to answers regarding design/strategy - there isn't much other than us right now :)
19:48:26 <smyers> that's still very useful information
19:48:30 <themroc> indeed, and for 2.5 also https://docs.ansible.com/ansible/2.5/installation_guide/intro_installation.html#control-machine-requirements
19:48:59 <jborean93> the only requirement change made recently was that Python 2.6 was dropped on the controller in devel/2.8
19:49:22 <jborean93> but working with 3.4 won't ever be a valid scenario
19:49:29 <zbr> py26 can RIP afaik
19:49:35 <smyers> I'll just have to take some time and think about it. The two main conclusions I'm coming away with are the ones I was working with, so that agreement is helpful: 1) prune is useful, and should stick around. 2) being able to run roles in create/destroy sounds useful
19:49:58 <jborean93> so if you want to run on Centos 7, continue with python 2.7
19:50:23 <smyers> ^ +1
19:50:38 <themroc> smyers, +1
19:51:03 <zbr> ok, i give up. lets see if someone complains.
19:51:33 <decentral1se> ok, solid feedback
19:51:37 <smyers> thanks for the feedback on my pr, I consider the question answered and the topic closed
19:52:12 <decentral1se> anyone else wanna take the floor with a PR?
19:52:36 <zbr> decentral1se: yeah, the defaults scenario name?
19:52:41 <themroc> so dependency, then destroy, then dependency again is the safe scenario
19:52:56 <decentral1se> oh yeahhhh
19:53:01 <zbr> https://github.com/ansible/molecule/pull/1745
19:53:16 <decentral1se> #info https://github.com/ansible/molecule/pull/1745
19:53:27 <decentral1se> I just feal uneasy about this some reason. Call me cautious
19:53:52 <zbr> mainly this is to remove current requirement to have "name: foo" inside molecule.yml files. -- to make it optional.
19:54:14 <zbr> the default value would be the folder name hosting the molecule.yml
19:54:27 <themroc> ah ok i understand now your point
19:54:30 <zbr> zero impact because ATM name is mandatory
19:55:11 <zbr> the funny part is that molecule had code for an implicit 'default' value but it was never used  before field was mandatory.
19:55:35 <decentral1se> woops, didn't meant to set the scene for this negatively! :/
19:55:48 <zbr> why we want this? becase it allows use to reuse the molecule.yml files between scenarios.
19:56:06 <themroc> i know there was some discussion about creating a config file to define default values, but i don't remember where the conversation ended
19:56:07 <zbr> reuse via symlinks.
19:56:13 <smyers> for feedback on that, so far 100% of the many scenarios I've written fit the pattern where the scenario name matches the directory name in which the molecule.yml resides
19:56:22 <tima> sorry got distracted here.
19:56:27 <decentral1se> that's good to know smyers
19:56:42 <smyers> and to that latest point, many molecule.yml files only differ by the scenario name field
19:56:43 <decentral1se> so, we 'make it optional' here by making it match the parent folder
19:56:43 <tima> thinking outloud here @smyers --  would creating `/roles` if not present in `create`smooth things out?
19:56:51 <decentral1se> not by actually making the logic take it as optional?
19:57:28 <zbr> smyers: i used the same pattern myself, I am not even sure if it would be possible to not have folders matching scenario names.
19:57:44 <themroc> zbr, +1
19:57:46 <asmacdo> smyers: this change would let me delete and symlink one of my molecule.yml files too :)
19:58:55 <decentral1se> ok, looks like no blocker on this then!
19:59:47 <smyers> tima, that or something like that, yeah
19:59:51 <decentral1se> zbr: you're OK to get that PR in shape then?
19:59:58 <decentral1se> further question: does this go into v2.20?
20:00:17 <zbr> sure! glad we all agreed on that.
20:00:21 <themroc> zbr, some fixes need to be done to satisfy travis, though
20:00:39 <zbr> it would be really nice to include it in v2.20.
20:01:17 <decentral1se> if no one is against it, I am in favour
20:01:17 <zbr> i will fix it tomorrow morning with the sdist one, to avoid a 4MB distribution file.  ok?
20:01:29 <decentral1se> I reckon we have more days to wait before it's clear what the release process is even
20:01:36 <themroc> if the ci get green before the 2.20 final process, why not :)
20:01:39 <decentral1se> but that may not be case if webknjaz is on point
20:02:34 <decentral1se> #agreed put #1745 on the v2.20 release schedule
20:02:56 <decentral1se> ok folks, I'm outta time, I'm gonna end this one
20:03:01 <themroc> Goneri, https://github.com/ansible/molecule/pull/1716 ?
20:03:03 <decentral1se> thank you all for your time!
20:03:06 <decentral1se> #endmeeting