Public Core Meeting Meeting - April, May 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.md for the schedule

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

[gundalow]

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

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

Migrated from

• Public Core Meeting Agenda - Feb 2017 #150 (comment)
• Public Core Meeting Meeting - March 2017 #156 (comment)

Update 12 Jan 2017 Meeting

• All approved. We'll start with contrib/inventory as most of those are community maintained as it is.
  • Will come up with a list of dynamic inventory proposed metadata for next week.
  • bcoca created spreadsheet; will update us on status.

Update 9th Feb 2017 Meeting
For contrib/inventory

• Spreadsheet exists
• bcoca to speak with @abadger to find out how we add python metadata to config files
• bcoca to organise meeting (internally?) to vote and get metadata agreed

Feb 21 Meeting

• For dyn inventory config files, abadger proposes that the config files use the asociated script's metadata.
  • Note: There are both yml and ini config files. Need to make sure both are handled by the metadata code.
  • ryansb will rename the one outlier, consul.ini to consul_io.ini to match with the script consul_io.py. (code will look for both file names for backwards compat) Completed

Mar 2 Meeting

• Nothing new to discuss while we wait on module metadata to be reworked.

Mar 14

• Metadata rework is done.

2017-03-23

• jtanner to evaluate and write bot workflow for non-module shipits
• tracked in implement shipit workflow for !modules ansibullbot#437
• need more info on what 'rework is done' means
  • Metadata rework done means that the final draft of metadata 1.0 was accepted and the modules have that form of the metadata.
    2017-04-18
• jtanner, are there any other decisions that need to be discussed here? Or are we at the point where everything is approved just needs to be implemented?

[gundalow]

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

Note this is for stable-2.2 and stable-2.3

Migrated from #150 (comment)

• 24 Jan Meeting: bcoca had two observations which need to be considered as the code is reviewed:
  • (1) bcoca: dwim code always needs careful consideration because it can break a lot of things and isn't always obvious why it's doing things.
    • Submitter (rupran) says: "what it basically does is factor out a part of path_dwim_relative_stack (leaving the functionality untouched) to use it in with_fileglob"
  • (2) bcoca: lookups should use same function, once you start diverting them they become unpredictable but just on consistency with lookups, not happy to duplicate and modify functionality
• 9 Feb: @bcoca to review
• 21 Feb: Still on @bcoca's radar to review
• 2 Mar: Still on @bcoca's radar to review
• 7 Mar: Recently rebased. Still on bcoca's radar.
• 4 Apr: Alternative fix from bcoca [WIP] Allow fileglob of dirs ansible#23265
• 11 Apr: Lots of options on how this should work, @abadger to enumerate and revisit in future meeting
• enumeration and pros/cons of alternatives: https://gist.github.com/abadger/7f9466272d84fad9ab7c4207a65a67fd
• 18 Apr: @abadger and @bcoca discussed and think that there's pretty big cornercases for all the strategies except erroring. They agree that we can handle wildcards in absolute paths but not relative paths. So bcoca will update the PR to error in that case.

[gundalow]

Define and document proposals process i.e ansible/proposals#50 was created and 'agreed' to immediately, w/o giving time for community feedback, which is happening now after implementation.

Migrated from #150 (comment)

We might need to review/update this:
https://github.com/ansible/proposals/blob/master/proposals_process_proposal.md

7 Feb Meeting

Discussed at the meeting. Many problems with the meta-proposal for creating proposals were discussed. Minimum timeframes were proposed but no agreement could be come to. Proposal documenting the new proposal process was asked for.

14 Feb Meeting

• ACTION: allanice001 has kindly offered to raise a PR to update proposals_process_proposal.md
• In the future we can look at moving this under docs.ansible.com/ansible/NEWDIR/process_proposal.html , Details about our release process, proposal process, etc will go there, rather than under dev_guide. Need to bikeshed a name. This is something for after Ansible 2.3 is released.

2 Mar Meeting

• No updates from allanice001. Still waiting on PR to update proposal.

2017-03-23
reviewed: ansible/proposals#59
no consensus, some feedback (see meeting notes) to be posted on ticket.

20174-04

• Create proposal-process.md proposals#59 needs updating based on review comments

[gundalow]

from @bcoca How should paths work? https://github.com/ansible/ansible/pull/22546

2017-04-04

• Not just a bugfix, it's setting expectations on how pathing works
• tkuratomi thinks that relative paths have too much ambiguity and would not expect many of the paths to be relative to the config file. Would rather have relative paths that cannot be made relative to playbook error.
• bcoca and tkuratomi both voiced tentative support for alikins' idea of having placeholders for relative to CONFIG, CWD, etc that could be used.
  2017-04-18
• Deferred for now (ansible config may interfere with prototyping). To be put back on the agernda when we're ready to code/make a decision.

[gundalow]

expand doc fields
ansible/proposals#58

2017-03-21:
types +1 as long as they are strict list
config: @bcoca to provide more examples as it seems to overlap with existing options

2017-03-23:
new proposal seems close to consensus, some details to discuss:

• priorities
• shared docs (fragments?)
• field naming (bikeshed away)

Ticket is open to updates/discussion and once those are done it will be brought back for final approval

2017-04-11:

• abadger/bcoca/nitzmahone are OK with proposal as-is, ready for implementation?
  2017-04-18
• No objections/further comments have been raised this week.. Asked at meeting if anyone else had something to say and nothing was added. Calling this approved. Go forth and implement!

[gundalow]

From bcoca

Now that we support docs for many more plugin types, should we require all new plugins of those types to have docs included?

2017-03-30

• All new plugins should have docs
• Should be enforced by CI
• We should not just add placeholder docs to existing to make them pass - will be difficult to know what requires work.
• Therefore CI requires skip-list

2017-04-18

• Note: not all plugins support docs yet. Use andible-doc -h to figure out which types of plugins need to be tested

• This seems to be approved once CI can enforce it. Leaving this on the agenda until we know mattclay is aware of it, then can remove.

[gundalow]

From @mattclay

ansible/ansible#9563 (Adding nested dictionary lookups) - Do we want to accept this PR?

NOTE: Tests were passing until more strict checks were added recently. Docs will need to be updated to reference the 2.4 release instead of 2.2.

[gundalow]

~~From @bmildren ~~

Hi all, I'm trying to find how to progress this PR past community review, and it was suggested I add it here as an item to discuss.. ansible/ansible#19872

(my irc handle is productiondba)

2017-04-04 Merged

[gundalow]

Ansible 2.3.0 FINAL has been released. Thank you for all your help with this release
https://groups.google.com/forum/#!topic/ansible-project/aKnggI-Y8dk

[nitzmahone]

Revisit frequency/timing of core meetings- participation and efficacy feels pretty low lately.

Decided on keeping current schedule for now.

[thaumos]

2017-04-25 Meeting

Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2017-04-25/ansible_core_team_meeting.2017-04-25-19.00.html
Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2017-04-25/ansible_core_team_meeting.2017-04-25-19.00.txt
Log: https://meetbot.fedoraproject.org/ansible-meeting/2017-04-25/ansible_core_team_meeting.2017-04-25-19.00.log.html

[gundalow]

Module option validation. passed on to @privateip as shown below

I've recently seen a few modules that:

• Ensure an int is within a specific range
• Ensure a option is an IPv4 (or IPv6) address

Should class AnsibleModule in basic.py be updated to support these?

201705-02

• This would be good, though not in basic.py
• Solution should be based on Provide functions for IP address or port range validating (fixes #16256) ansible#17731 (comment) + Provide functions for IP address or port range validating (fixes #16256) ansible#17731 (comment)~~