19:00:32 <gundalow> #startmeeting Ansible Molecule Working Group
19:00:32 <zodbot> Meeting started Wed Apr 17 19:00:32 2019 UTC.
19:00:32 <zodbot> This meeting is logged and archived in a public location.
19:00:32 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:32 <zodbot> The meeting name has been set to 'ansible_molecule_working_group'
19:01:37 <gundalow> Who's around?
19:01:47 <mteufelberger> *raises hand*
19:01:53 * tima waves
19:01:53 <nwilburn> I'm here. Not sure if I count though =P
19:01:57 <gundalow> zbr: smyers decentral1se ?
19:02:10 <gundalow> nwilburn: I'm not sure why you wouldn't count :P
19:02:17 <gundalow> mteufelberger: Hi :)
19:03:41 <gundalow> #chair nwilburn mteufelberger
19:03:41 <zodbot> Current chairs: gundalow mteufelberger nwilburn
19:04:36 <pabelanger> o/
19:04:40 <gundalow> #chair pabelanger
19:04:40 <zodbot> Current chairs: gundalow mteufelberger nwilburn pabelanger
19:04:49 <gundalow> Anyone got anything for today?
19:05:07 <gundalow> mteufelberger: I believe you raised a few issues recently
19:05:39 <mteufelberger> Maybe more a difference in perspective between me and webknjaz...
19:06:00 <gundalow> #topic Molecule Community
19:06:03 <mteufelberger> The bigger issue I have is maybe about how to contribute and how contributions are decided about
19:06:06 <smyers> internet was busted, seems good now
19:06:14 <gundalow> #chair smyers
19:06:14 <zodbot> Current chairs: gundalow mteufelberger nwilburn pabelanger smyers
19:06:16 <gundalow> Hi :)
19:06:51 <mteufelberger> Meaning: DCO is annoying as hell and was simply added in there with a "it's legally required" note.
19:07:15 <mteufelberger> And in some other cases, people try to contribute and then are met with "but I don't wanna".
19:07:40 <gundalow> mteufelberger: DCO is on my list to find a better solution to
19:08:00 <gundalow> 1) Remove the hard requirement for `--sign-off` - This might be OK for a "smaller" project like Molecule
19:08:01 <mteufelberger> This makes it a bit hard to do bigger changes, especially in your free time if you can't even know that this will make it in
19:08:29 <gundalow> 2) Use a Bot so you only need to sign off once - I've been hacking on this in my fork https://github.com/gundalow/molecule/pull/10
19:08:35 <mteufelberger> or that it might get refused on principle or technicalities.
19:09:29 <gundalow> mteufelberger: would (1) or (2) make DCO better for you?
19:09:35 <mteufelberger> In the longer run I'd be really interested to know which direction Molecule should take on in general - a very large part of its functionality could be already done by an Ansible playbook running on localhost.
19:09:59 <zbr> o/
19:10:11 <pabelanger> a user .gitconfig can be updated to auto handle --sign-off, if a user doesn't want to use git commit -s
19:10:12 <mteufelberger> I'd prefer number 1, because Molecule is the only project that I contribute to that requires this
19:10:17 <smyers> I like the idea of the DCO, but having to do it for every commit in just this project is definitely annoying. Short of just not using it, having the ability to just say "any commit I make is under the DCO" via a bot or wahtever would be good.
19:10:22 <gundalow> So Molecule will be the testing framework for Ansible Collections. There will be
19:10:22 <pabelanger> maybe documentation should updated to include that
19:10:53 <smyers> pabelanger, I haven't yet been able to make the git config do that for only the molecule clone
19:10:55 <gundalow> I need to write an email to Red Hat legal with the various options and get clarrifications. It's possible we can just remove it
19:11:04 <mteufelberger> I don't want my mail address in even more places.
19:11:24 <nwilburn> I agree with smyers and think #2 is a good choice, personally
19:11:33 <mteufelberger> By default it ends up as the content in pull requests for example, and I get enough spam mail as is
19:11:51 <smyers> Any tips would be appreciated there. Adding sign-offs is definitely not something I can (or want to) do systemwide.
19:12:16 <gundalow> #action gundalow to email Red Hat legal to see what our true requirements are for DCO
19:12:25 <zbr> DCO also breaks edit-in-browser contributions which are very handy for one-liners fixes.
19:12:27 <gundalow> Based on ^ we can then look at removing/ updating docs etc as needed
19:12:52 <fabianvf> here, lost track of time
19:12:58 <mteufelberger> Especially weird is that AWX requires it too, but has no bot enforcing that and their commits are rarely signed off...
19:13:05 <zbr> considering that ansible itself does not have them, and that legal already reported that as "desired" and not mandatory,.....
19:13:08 <gundalow> Not tested though for Chrome https://chrome.google.com/webstore/detail/dco-github-ui/onhgmjhnaeipfgacbglaphlmllkpoijo
19:13:19 <gundalow> OK, let me get clarification from Legal
19:13:33 <gundalow> mteufelberger: after DCO, what was next
19:13:37 <zbr> gundalow: ok, thanks.
19:14:10 <gundalow> So regarding linting
19:14:11 <mteufelberger> I think soonish there will be enough linters and formatters and tests and checks in place to move forward with the general project design
19:14:16 <gundalow> yes
19:14:43 <gundalow> All, please take a moment to read https://github.com/ansible/molecule/pull/1919#issuecomment-484132810
19:14:56 <gundalow> I hope we can move forward
19:17:15 <pabelanger> smyers: sorry, stepped away, you need to setup an alias
19:17:20 <pabelanger> in your .git/config
19:17:31 <zbr> gundalow: here is what I propose: in case of conflicts, additional votes are needed. Example, if change has one -1, it would be merged only if has at least 2x +1 (assuming uploader is core)
19:17:57 <gundalow> zbr: I think if a single `-1` is present then merging is blocked
19:18:15 <gundalow> hum, though maybe only `-1`'s from people with commit block
19:18:16 <zbr> gundalow: any core can remove the negative review before pressing the merge.
19:18:40 <gundalow> Have to click `dismiss` and add comments why
19:19:19 <zbr> i am not advocating for ignoring feedback, but this can unblock some reviews instead of leaving them lingering forever.
19:20:13 <gundalow> I wouldn't expect `dismiss review` to be used often
19:20:54 <gundalow> #info If people have non-technical issues with any part of the project feel free to send me a direct message
19:21:19 <smyers> The conflict in this case seems to have been between a personal opinion and the linter, with the effective guidance being "the linter wins." I don't know if a broad conflict resolution strategy would help (or would have helped) here.
19:21:36 <smyers> It's not a bad idea, I just don't think it's specifically relevant.
19:21:59 <gundalow> Nod, just want people to know that I'm always available if need be
19:22:56 <fabianvf> Perhaps it would be good to add that to the CONTRIBUTING.md
19:23:05 <gundalow> #chair fabianvf
19:23:05 <zodbot> Current chairs: fabianvf gundalow mteufelberger nwilburn pabelanger smyers
19:23:21 <gundalow> Good point
19:23:29 <gundalow> What exactly would people like to see there?
19:23:55 <mteufelberger> I'd also love it if also "core" members require their contributions to be reviewed btw.
19:24:10 <mteufelberger> A "governance" section maybe?
19:24:20 <gundalow> mteufelberger: As of last week every PR must have a review by at least one other person
19:24:27 <gundalow> ie I can't merge my own PRs anymore
19:25:05 <fabianvf> I don't think we should go too crazy with process (that can be just as bad or worse), just add a note that if you have issues you can contact someone
19:25:14 <gundalow> Works for me
19:25:20 <tima> +!
19:25:23 <tima> +1
19:25:26 <tima> less is more.
19:25:38 <smyers> That's a great change, I think. Unreviewed PRs that get instamerged are scary (and why even open a PR?), but I'm digressing a bit...
19:25:48 <mteufelberger> Yeah, and if a PR is stuck with no reviews or comments, people should join this meeting or post on the agenda issue
19:25:58 <gundalow> As a reminder, all of gh/ansible/ and related mailing lists, IRC, etc, etc are covered by https://docs.ansible.com/ansible/latest/community/code_of_conduct.html
19:26:24 <nwilburn> That would be a good thing to put in CONTRIBUTING if its not. Where to get help with moving a PR forward if its not being reviewed / commented on
19:27:02 <mteufelberger> In practice this tends to be the more relevant issue - or a contributor not fixing up their code.
19:27:17 <gundalow> nwilburn: just to clarify, that if your PR gets stuck ask on IRC?
19:27:45 <gundalow> I'm happy to put some bits into CONTRIBUTING just would like to know what bits
19:29:23 <gundalow> 1) If your PRs get stuck join us in IRC or add to agenda
19:29:39 <gundalow> 2) Coding standard is what's enforced by CI, everything else is off topic
19:29:53 <fabianvf> +1 we should avoid debates on style, IMO anything that is architecturally sound, passes CI, and is accepted in terms of substance (ie, the change is desired), should merge. Any stylistic nits deemed important enough to block a merge should be part of CI.
19:29:56 <zbr> gundalow: if you write something there: i suggest: simple fixes like one liners or stuff that are very low risk, ok to merge with only one review. for the rest like features/... at least 2.
19:30:11 <gundalow> 3) All PRs must be reviewed by one other person. This is enforced by GitHub
19:30:21 <smyers> "low risk" is subjective, just have one standard
19:30:33 <smyers> +1 to gundalow's suggestions
19:30:41 <nwilburn> gundalow: yea. +1 for all of the above
19:30:41 <gundalow> anyone got a (4) to add?
19:30:48 <tima> agreed @fabianvf
19:31:10 <mteufelberger> COC is the one from the Ansible project at [URL]
19:31:21 <tima> (4) read 1 thru 3 again?
19:31:23 <tima> ;)
19:31:24 <smyers> hah
19:33:00 <mteufelberger> It might get easier with the linting stuff etc. in the future anyways, once the "pre-commit" stuff gets added, that way people can already check locally instead of suddenly getting a red X from travis.
19:35:03 <Not-e6c6> [molecule] gundalow opened issue #1992: Contributors.md Governance updates - https://git.io/fjY51
19:35:08 <gundalow> https://github.com/ansible/molecule/issues/1992
19:35:11 <gundalow> oh, thanks bot :)
19:35:18 <smyers> well that was fast
19:35:26 <gundalow> smyers: just an issue, not a PR
19:35:32 <smyers> still though
19:35:34 <smyers> nice
19:35:39 <gundalow> #info If people think of anything else feel free to add to https://github.com/ansible/molecule/issues/1992
19:35:46 <gundalow> GitHub issue or it never happened :)
19:35:50 <gundalow> Right
19:35:55 <gundalow> Thanks for all the suggestions
19:35:59 <gundalow> Anything else on that?
19:37:06 <mteufelberger> Not from my side
19:38:34 <gundalow> Cool
19:38:44 <gundalow> #topic Ansible Collections update
19:40:06 <gundalow> #info There will be a PR raised in the next week or so that adds support for `molecule init collection`. We are also working on some public docs for this. This will be a reboot of https://github.com/ansible/molecule/pull/1671
19:40:23 <fabianvf> awesome
19:40:55 <tima> nice
19:40:56 <nwilburn> Good to hear!
19:41:16 <gundalow> For those that are wondering what I'm going on about, we will have some details to follow
19:41:19 <gundalow> #topic Open Floor
19:41:44 <gundalow> #info Ansible Fest is in Atlanta and call for papers is open https://www.ansible.com/ansiblefest
19:42:09 <pabelanger> I finally had some time to run some molecule testing from zuul.ansible.com, if people are intersted in the results: https://github.com/ansible-network/sandbox/pull/31#issuecomment-484197743
19:42:23 <tima> what is the status of bringing over the ansible-test functions into molecule to test collections?
19:42:23 <pabelanger> that is just a small snapshot based on the tox.ini file
19:42:36 <gundalow> tima: that's Ansible 2.9 work
19:42:57 <tima> ok. so molecule will be able to init collections but not test them?
19:43:23 <gundalow> tima: How exactly that will be done is TBC, though possibly something like `molecule lint ansible-test` or `molecule lint sanity`
19:44:14 <mteufelberger> I assume that collections will also contain playbooks and inventories... that's a bit harder to test I guess.
19:44:29 <zbr> btw, i think I found(made) a solution for the missing selinux in tox environments: https://pypi.org/project/selinux/ feel free to take a look.
19:44:32 <gundalow> mteufelberger: roles, modules, plugins, yup
19:44:33 <tima> ok. i don't want to split hairs but ansile-test wraps a bunch or lint and other tools most that aren't of the ansible projects making.
19:44:58 <tima> collections do not @mteufelberger
19:45:07 <tima> certainly not in v2.8
19:47:09 <mteufelberger> I thought of a collection more like a standardized folder structure just like a role (where you don't have to tell Ansible that templates are in the "templates" folder), at least when looking at https://github.com/bcoca/collection as an example
19:47:37 <tima> anyways, so i'm curious if it makes sense to have one big massive tool or all of the individuals one ansible-test uses be implemented as a collection of linters etc.
19:48:00 <tima> roles are portable. collections are the successor (of sorts) of roles.
19:48:02 <bcoca> mteufelberger: you realize templates/ vars/ and files/  are not specified?
19:48:12 <tima> neither playbooks or inventory are portable assets.
19:48:24 <gundalow> tima: we will be using proposals for the larger blocks of Molecule work https://github.com/ansible/molecule/issues/new/choose that's where the use-cases will be defined
19:48:34 <bcoca> tima: i would argue that point
19:48:56 <mteufelberger> Most of the roles I write and use are not portable and not intended to be.
19:49:09 <mteufelberger> At least not widely
19:49:16 <fabianvf> inventories are pretty unportable, but I end up distributing a lot of playbooks
19:49:50 <tima> i know. that's you for you. ;)
19:49:54 <mteufelberger> But I guess I'll wait until I see the actual documentation or specs for collections.
19:50:22 <smyers> ^ is my thinking. Save these discussions for the actual molecule proposals
19:50:38 <mteufelberger> I just wonder where molecule would enter there
19:50:58 <mteufelberger> in the "tests/molecule/[scenario_name]" folder?
19:51:10 <nwilburn> zbr: oh man this is awesome. That was such an annoying "bug". Does that solution work as of today?
19:51:56 <fabianvf> On another topic, the Ansible verifier PR (https://github.com/ansible/molecule/pull/1714) has been open for quite a while now, and started failing CI for reasons unrelated to the PR. I've already rebased a few times and would really love to get this in before it bitrots to death
19:52:29 <tima> ugh. yes we should get that merged. i see no reason not to personally.
19:52:32 <zbr> yep, but is very new, managed to make it work for both py27/py36 only yesterday.... so only time will tell. but please try it and let me know.
19:53:38 <smyers> +1 to merging #1714 before another rebase is needed
19:53:58 <zbr> funny note, the module was empty for ~1 month, and it did had >300 installs from pypi :D
19:55:26 <zbr> nwilburn: feel free to audit the magic from https://github.com/ssbarnea/selinux/blob/master/selinux/__init__.py#L55
19:55:30 <gundalow> If people give positive reviews I'll look at merging
19:55:46 <gundalow> fabianvf: Let me know once it's rebased/CI green/whatever and I'll hit merge
19:56:21 <gundalow> ok, I need to drop off now
19:56:27 <fabianvf> gundalow: I think it's rebased already, not sure what I need to do to make CI green (maybe someone just needs to kick the build off again, if the underlying issue has been resolved in master)
19:56:36 <gundalow> fabianvf: OK, I'll kick CI
19:57:08 <pabelanger> if people are interested in learning more about the molecule testing under zuul above, feel free to reach out.
19:57:16 <smyers> The underlying issue has been solved with tox 3.9.0
19:57:26 <smyers> (at least I think that's the version, but whatever, it's solved on master)
19:57:36 <gundalow> smyers: ah, yes,thanks
19:57:37 <tima> cool. thanks @pabelanger
20:00:38 <mteufelberger> Where can I find the config for the zuul tests above? Also it seems a bit wasteful to have linters fail and then still run unit tests.
20:00:56 <gundalow> #endmeeting