Standing Agenda, Public Core Meeting Meeting - January 2017

[gundalow]

Please leave a comment regarding any agenda item you wish to discuss. If you don't show up for the meeting, your item will be skipped.

If your IRC nick is different from your Github username, leave that as well.

See https://github.com/ansible/community/blob/master/meetings/README.md for the schedule

Once an item has been addressed it should get strike-though ~~strike-though~~

[gundalow]

Re-migrated ansible/ansible#19016

• From 12/13 meeting: currently waiting for JMainguy to have a chance to look.
• From 2/2 meeting: Waiting on one documentation change from submitter then readyto merge

[gundalow]

Re-migrated ansible/ansible#19020

• From today's meeting, ryansb has this one on his list.
• 01-11, ryansb done reviewing. Pinged jjshoe to give a +1 if he's satisfied.
• Jan 17: Waiting on jjshoe for several weeks, should we go ahead and merge?

Merged

[gundalow]

Unfortunately when I migrated he first time the original was deleted so I've had to create a new PR. ansible/ansible#19021

• From 12/15 meeting: This one is waiting on the submitter to make some changes.
• 01-11: Pinged submitter about making the requested changes
• Jan 17: Looks like this is ready, ryansb?

Merged

[gundalow]

Re-migrated ansible/ansible#19027

• From 12/15 meeting: abadger will review with some questions from bcoca's PR.
• Jan 11: abadger pinged committer about comments we've left.
• Decided that this module should go to galaxy. (resolved)

[gundalow]

Re-migrated ansible/ansible#19042 [postgresql module]and ansible/ansible#19043 [elasticache module]

• Elasticache module merged by ryansb. abadger looking over postgresql module
• Jan 11: Pinged submitter about requested updates
• Jan 12: ready for review
• Jan 12: Needs some changes
• Jan 16: Merged!

[gundalow]

Re-migrated PR ansible/ansible#19049

• Asking dav1x to review this one and decide between the two alternative implementations.
• deprecated by vmware_guest: module rewrite to add many features & fixes ansible#19228, no futher action needed

[gundalow]

Re-moved ansible/ansible#19070

• nitzmahone has this on his list.

[jasperla]

~~As mentioned in ansible/ansible#18924 (closed as of Jan. 3), I've now re-submitted the PR as ansible/ansible#19680 (merged as of Jan. 3). ~~
Merged

[bcoca]

ansible/ansible#19664 Support for jinja templatable dict keys

* ansible/ansible#19664 (comment) This introduces non-reproducibility into the system because dictionary keys could be templated in different orders in differnt runs leading to different values being used.

[bcoca]

ansible/ansible#19800
* This was approved in concept. Some changes were asked for. (listed here ansible/ansible#19800 (comment) )
* Jan 11: dag and bcoca working out one last change that needs to be made. (bcoca going to re-review today and point out where comment is missing)

Merged

[gundalow]

ansible/ansible#15432 "Ansible 2.0 no longer finds modules in library subdirectories"

Update 3 Jan 2017 Meeting
we had several proposals:

• Add subdirectory support to all Plugins
  • Con: This introduces complexity to the other plugins, roles, etc which doesn't that great. This wasn't available for non-modules in 1.9 either.
• add subdirectory support to just modules
  • Con: This introduces the complexity for modules in roles, not just LIBRARY_PATH. Resolving the module to a specific file is more difficult for the user to work out in the case of conflicts. Code-wise, we'd need to split or special case Modules in PluginLoader so that modules get this but not other plugins.
• Do not add subdirectory support but document multiple ANSIBLE_LIBRARY paths with rationale so that the user can control conflicts by ordering their ANSIBLE_LIBRARY appropriatley.
  • Con: Makes the user manually configure things

Update 12 Jan 2017 Meeting

• Decided to document ANSIBLE_LIBRARY. The user has to manually configure this way but (1) it's not common, (2) with the other ways, the user does not have control in the case of conflicting module names. This method gives them the necessary control.
  ** Update2 Feb 2017 Meeting~~
• Documentation is part of this PR: Module utils default path ansible#20913

[mattclay]

ansible/ansible#18147
merged

[mattclay]

Discuss extending the module "shipit" workflow to non-modules, such as:

• lib/ansible/plugins
• lib/ansible/module_utils
• contrib/inventory

The bot would need to be updated to support the updated workflow.

** Update 12 Jan 2017 Meeting **
All approved. We'll start with contrib/inventory as most of those are community maintained as it is. Alerting tower team of this as it could be relevant to them. Will come up with a list of dynamic inventory proposed metadata for next week.

[gundalow]

mount module feature request: allow to mount without adding to fstab ansible/ansible#19820

needs contributor

[gundalow]

ansible/ansible#19500 Update assemble to allow alternate source of files

• jan 5 meeting: Discussion lead to question of whether an alternate source of files is desirable for assemble. itdependsnetworks was pro and bcoca was con.
  • Everyone was okay with the subset of giving assemble a way to customize sorting (but haven't figured out implementation that is limited to this).
• 2 Feb meeting: Submitter doesn't want to truncate this particular PR to only be about sorting so we need to decide on the features that are present in the PR. We talked briefly about whether template includes can do the work that assemble src_files does and seemed like it could. We think we've gotten all the input we can so we started voting among the committers to decide whether to accept or reject:
  • -1 bcoca, abadger
  • +0 ryansb jctanner
  • +1 alikins
    Right now the decision could be weighted by which committers were attending the meeting so we'll ask for more votes next meeting before making a decision.

[ryansb]

When should we start removing submodule commands from various docs/scripts? The error messages for 2.3+ can be updated, but I'm not sure about the other commands in the arch PKGBUILD and the hacking script.

$ ack 'update --init --recursive'
docsite/rst/intro_installation.rst
342:    $ git submodule update --init --recursive

lib/ansible/parsing/mod_args.py
302:                        "run 'git submodule update --init --recursive' to correct this problem.",

lib/ansible/plugins/action/__init__.py
148:                                   "run 'git submodule update --init --recursive' to correct this problem." % (module_name))

packaging/arch/PKGBUILD
37:  git submodule update --init --recursive

hacking/update.sh
3:git submodule update --init --recursive

Discussed 2017-01-05

• PR raised a (docs) Remove/update mentions of git submodule in docs and error me… ansible#19941

[podlesh]

feature proposal: ansible/ansible#19707 (enhanced rolling updates)

• Jan 10 meeting: bcoca was for a sorting and grouping of hosts independent of serial.
  • Some flaws in the implementation were pointed out.
  • more discussion happening in ticket. To be discussed more in this meeting if the ticket discussion gets stuck.
• Jan 17 meeting: podlesh not on irc

[jbaublitz]

IRC nick: jbaublitzzz

feature proposal: Add google-api-python-client as a supported alternate back end for existing gce* modules alongside libcloud.

@ryansb: In case I don't make the meeting here is a description of the problem

There is a potential race condition in libcloud when deleting a subnetwork then a network from gce_net. This seems to stem from ex_destroy_subnetwork in libcloud and specifically this call. request in libcloud connection objects assume that the API is synchronous and if subnetwork deletion on Google is an async API (I'm assuming it is but @supertom can confirm this), the gce_net subnetwork deletion would "succeed" according to libcloud but would not be complete by the time ansible would start trying to delete the network. The network deletion would subsequently fail because the subnetwork would not be deleted yet. This is the behavior that I'm seeing and will work with libcloud to patch this but would also propose using the Google library as an alternate backend. As a side note, I've worked with both the library and some of the gce modules so I'm willing to do the alternate back end implementations for the modules I've been contributing to and potentially others when time permits.

• 10-Jan-2017: seek input from @supertom and @erjohnso (as the maintainers of the gce* modules)

[bcoca]

ansible/ansible#20004 cc @evgeni

Applied PR. Will eventually look into integrating docs with ansible-doc.

[evgeni]

IRC nick: Zhenech

[abadger]

SmartOS Timezone module: ansible/ansible#20105 Do we want this as a separate module or merged with the existing timezone module? merged as diff

[jasperla]

For your consideration in addition to @abadger 's comment, please note that other systems (e.g. OpenBSD) are not supported by the existing timezone module. For those systems it's merely a matter of reading/setting the /etc/localtime symlink and all the extras that timezone currently provides won't be used. sea bove

[bcoca]

ansible/ansible#18643

[abadger]

From @jtyr: ansible/ansible#19283 hosts module (for /etc/hosts)

20160124: Skipped as there are outstanding review issues. Some thoughts around do existing modules give people this functionality.

[abadger]

From luto: ansible/ansible#19297 Fix for wildcards inside of a path for fileglob lookup (ie: with_fileglob: "/tmp/*/some.conf")

[bcoca]

Decide which are valid directives on include (for execution or inheritance) and what to do when we decide they are not. This issue deals with one case, but i think we should deal with it in general ansible/ansible#20440

[rfleschenberg]

• Verisioned docs / readthedocs

  • Versioned docs would be great! Notes in the docs about which versions they apply to are good, but the default docs not applying to the default (released) Ansible version is a major UX problem.
    People skim through docs, and they are right to do so. Time constraints are a thing. Looking up module parameter names in the official docs to find out that the official release does not support them is no fun, especially not for newcomers.
  • People (at least Python people) are used to RTD
  • Ansible can build upon the experiences of other projects (e.g. Django)
  • Supporting RTD would be cool (I'm not affiliated with them)
  • irc nick: moldy

• 24 Jan Meeting:

  • Decisions:
    • Decided not to use readthedocs (Don't see a large amount of gain for it)
    • Everyone is in favor of limited versioned docs. (Seems to be unanimous support for stable and devel. Proposal made to also include stable -1 as we still make releases for security fixes there and no objections were raised [So currently: 2.1, 2.2, and devel].
    • From 2 Nov Meeting: Default documentation will be the latest stable release, with devel version being available but labeled.
  • Open questions/contentious items:
    • How much backporting to do? Currently doc changes only hit devel. We think that some of them should hit stable as well. Noted that module docs are the thing people complain most about when talking about non-versioned docs so perhaps that's what we should concentrate on applying docs bugfixes to.
      • No committers want doc bugfixes for docs which are "archived" (to be defined below).
      • Proposal made for rough guidance around backports:
        • "this is so totally broken and commonly used that we need to backport a fix for it" (affects main guide, infrequent)
        • Module doc fixes. more common and should be done more often if we have versioned docs.
    • Old docs/archiving: archived docs defined as no longer receiving changes
      • bcoca: champions taking down the html for old docs. Primary desire is: make upgrading more attractive by making it harder to read documentation for old versions.
      • bcoca proposes users should build old docs from git
      • dharmabumstead mentions that making the archived versions distinct and linking to the current version cuts confusion over what docs are for the current version down to near zero.
      • A few other committers (jimi-c, abadger) seem to be for keeping the archives as html with proper notes (as dharmabumstead mentioned)
      • dharmabumstead proposes tarball of old docs rather than making people build from git.
  • Actions:
    • Call to post ideas to: https://public.etherpad-mozilla.org/p/ansible-versioned_docs gundalow and dharmabumstead to work up a formal proposal from that.
    • dharmabumstead to report back on the header/footer work needed to link to versioned docs

[gundalow]

https://github.com/ansible/ansible/pull/20220/files module_utils/basic.py: Support logical or condition in required_if

Merged

[gundalow]

ansible/ansible#20673 Refurbish developing modules content - stage 1

Merged

[allanice001]

ansible/ansible#20737 Bugfix for ansible/hacking/test-module

Merged

[bcoca]

ansible/ansible#20058 Add systemd-nspawn connection driver

• 31 Jan: reviewed by abadger, waiting on submitter to fix up

[gundalow]

Orphaned mode process (uri)
ansible/ansibullbot#291

Merged

[willthames]

I would like to discuss custodianship of the AWS modules. In particular I would like:

• extra people with shipit
• extra people with commit rights
• someone to review my open PRs, many of which have been moved after months languishing in ansible-modules-core or ansible-modules-extras. The original authors have in some cases completely given up on the project, but their contributions are still valuable.

merged ansible/ansibullbot@11bbbbb

[bcoca]

ansible/ansible#18379 Feature/lookup keyring

Merged.

[gundalow]

Done
Feb 2017 agenda can be found at #150