Public Core Meeting Agenda - August 2017

[thaumos]

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~~

[thaumos]

bcoca wants https://github.com/ansible/ansible/pull/18662 discussed

[thaumos]

@cyberark-bizdev wants https://github.com/ansible/ansible/pull/27519 reviewed

[thaumos]

@bcoca wants https://github.com/ansible/ansible/issues/27537 discussed

[thaumos]

@dagwieers wants to discuss

Can we reconsider the new ansible_facts namespace and shorten it to just facts ? Since we are in Ansible anyway, having to specify ansible_facts for every fact seems pretty redundant.

Could we also get rid of the ansible_ prefix for each fact in the new namespace? Since we now have the ansible_facts namespace that pretty much defeats the purpose of having that prefix.

So in the end, I would prefer that

ansible_os_distribution

becomes accessible as

facts.os_distribution

rather than the existing implementation

ansible_facts.ansible_os_distribution

This will be a lot more convenient writing playbooks then the current implementation.

• decided to keep ansible_facts; not shorten it to facts
• Decided to remove the ansible_ prefix from within the facts inside the new namespace
• Decided not enough time to remove the prefix before 2.4 so we're reverting the ansible_facts namespace change and will put it back in for 2.5 along with removal of the prefix. (this delay will allow us to only release it when we're confident of backwards compat.)

[marc-sensenich]

I'd like to discuss adding the module from ansible/ansible#27636

• @s-hertel offered to review this

[thaumos]

2017-08-01 Meeting

Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-01/ansible_meeting.2017-08-01-19.00.html 12:58 Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2017-08-01/ansible_meeting.2017-08-01-19.00.txt 12:58 Log: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-01/ansible_meeting.2017-08-01-19.00.log.html

[thaumos]

2017-08-03 Meeting

Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-03/ansible_meeting.2017-08-03-15.00.html 09:23 Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2017-08-03/ansible_meeting.2017-08-03-15.00.txt 09:23 Log: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-03/ansible_meeting.2017-08-03-15.00.log.html

[abadger]

Discuss whether we want to allow a PR to implement a ~stdout/stderr~ STDIN parameter for command: https://github.com/ansible/ansible/issues/14380 (and several associated PRs) Can be done via piping in with the shell module but doing it in command makes quoting easier.

• 8 Aug: delayed talkig about this until we can have more core maintainers (bcoca and jimi-c)
• 10 Aug: delayed talkig about this until we can have more core maintainers (bcoca and jimi-c)

Decided: that we will take a PR to do this. @jimi-c favored data as the name and @bcoca favored stdin so they'll have to duke it out sometime. But otherwise this is good to move forward. There are several open PRs on this so someone will have to gather them all together and try to choose between them. (I'll try to start on that tomorrow. If I don't feel free to get in touch with me on irc.freenode.net #ansible-devel channel [abadger1999] to remind me I took this on).

[dagwieers]

I would like to discuss merging ansible/ansible#25323 (new xml module). It has been re-licensed, re-worked, made python3-compatible and comes with a lot of integration tests out-of-the-box.

• 8 Aug: @abadger1999 to take a quick look and merge. (already has one shipit from resmo) Merged

[abadger]

This issue is about the replace module https://github.com/ansible/ansible/issues/27779 but there's an overall question of what encoding strategy to take with modules. SInce at least 1.7, our strategy has been utf-8 everywhere. Recently i've merged a few patches that allow specifying an encoding parameter to choose one specific encoding other than utf-8 for what specific plugins read and write. The issue submitter above asks about two other cases:

• Files that have mixed encodings (/etc/passwd with one line having utf-8 and a different line having latin-1, for instance)

• Files that aren't text.

• 8 Aug: @abadger to write a proposal and put it on the contributor summit agenda.

• 10 Aug: pushed to contributor summit or proposal process, this is too big for this forum

[cyberark-bizdev]

Please add following PRs for discussion:

https://github.com/ansible/ansible/pull/21857 https://github.com/ansible/ansible/pull/27519

Either @cyberark_bizdev or @erasmix will be attending

• Discussed some changes to 21857 in the meeting. with @erasmix. After those are taken care of, hoping that ~@bcoca~ @abadger can do a final review of this one
• @abadger to review 27519 Merged

[liquidat]

The link to the meeting agenda is broken, please fix that. Otherwise, new community members have no chance of attending.

Fixed.

[abadger]

@liquidat, which link? I probably can fix it but I need to know what link it is I need to change

addressed out of meeting (cannot strike email)

[liquidat]

@liquidat, which link? I probably can fix it but I need to know what link it is I need to change

@thaumos It was the link in the original posting, the one pointing to the agenda. It was originally pointing at "https://github.com/ansible/community/blob/master/MEETINGS.md", and if I am not mistaken @dagwieers just changed it to the new, proper link. So everything is fine now. address out of meeting

[bcoca]

https://github.com/ansible/ansible/issues/27897

This was approved.

[mikedlr]

Moved forward from July where there wasn't a chance to discuss: I'd like some support to merge some of my PRs. Maintaining and rebasing them unmerged is getting to be a pain and quite a few of them are "ready" to merge with a few dating back to May.

Should be ready to merge

1. https://github.com/ansible/ansible/pull/24951 - Lambda policy with tests
2. https://github.com/ansible/ansible/pull/26059 - Lambda using new aws utils
3. ~https://github.com/ansible/ansible/pull/26532 - EC2 group error reporting improvement~ <- Needs to be updated to reflect that ec2_group is now a boto3 module.
4. https://github.com/ansible/ansible/pull/26871 - AWS module Guidelines fixes

Needs comments and reviews.

1. https://github.com/ansible/ansible/pull/26594 - rds.py utilities file
2. https://github.com/ansible/ansible/pull/27910 - or this version

Waiting for other merges above

1. new RDS modules need rds utility merge first 1.1. https://github.com/ansible/ansible/pull/26598 - new rds_instance_facts module 1.2. https://github.com/ansible/ansible/pull/26599 - new rds_snapshot_facts module 1.3. https://github.com/ansible/ansible/pull/26602 - new rds_instance module 1.4. https://github.com/ansible/ansible/pull/26604 - new rds_snapshot module 1.5. https://github.com/ansible/ansible/pull/26606 - integration tests for RDS modules
2. merge needed: https://github.com/ansible/ansible/pull/26059 - Lambda using new aws utils 2.1 https://github.com/ansible/ansible/pull/24722 - Lambda integration tests

Needs more from me then merge

1. ~https://github.com/ansible/community/pull/187 - community / needs AWS~ merged

Ideas for how to get more of these through quicker appreciated. N.B. in the meantime quite a bit has been merged so things are not nearly all bad.

• 8 Aug: had a brief discussion of these. @s-hertel started reviewing.
  • Also discussed whether we can get these in for 2.4 so that we can get people using and testing these new things for 2.4. Going to be tight. @mikedlr, @s-hertel, and rest of AWS SIG to discuss how much work and let us know if they may need a freeze exception to get it in on time.

Priorities before Ansible 2.4 freeze discussed on AWS IRC channel (some positive comments - no objections yet)

1. merge rds_split (all four modules) so that we can announce that it is the future
2. put a comment into RDS that it will be deprecated.
3. s3 with boto3 (https://github.com/ansible/ansible/pull/21529) - since it's broken without that
4. lambda_policy - since without it you can't actually deploy working lambdas
5. test case sets ( lambda/ lambda_policy etc)

the other priority that has been mentioned is getting the roadmap updated. s-hertel is working on that.

• Aug 10: @ryansb took this item for aws channel

[resmo]

~Use apt-get as fallback for apt upgrade https://github.com/ansible/ansible/pull/27962~ merged

[jtyr]

I would like to discuss https://github.com/ansible/ansible/pull/24967 - simple extension of the yum_repository module.

• Aug 10: got a few core members to review PR

[bcoca]

Meeting ended Thu Aug 10 15:55:47 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-10/ansible_core.2017-08-10-15.05.html Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2017-08-10/ansible_core.2017-08-10-15.05.txt Log: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-10/ansible_core.2017-08-10-15.05.log.html

[abadger]

Backwards incompatibility for status='preview'

Who decides whether a backwards incompatibility is okay for a module that is status='preview'? Are there any project-wide rules we want to document regardless of who decides?

Alternatives:

• Leave it to the module maintainers (so the authors of the packet_device module) to discuss and decide
• Leave it to the domain experts (so the authors of modules that live inside of cloud/packet) to discuss and decide
• Decide on something(?) project-wide with case-by-case exceptions

Relates to: https://github.com/ansible/ansible/pull/23127

• Decided: Project wide rule: incompatibilities must be documented

• Decided: Incompatibilities mean that it's incompatible with a previous release of Ansible (if something has only existed in devel then it's fine to change).

• Decided: For modules which are supported-by: community and status: preview, the maintainer can decide whether (and how) to break backwards compatibility. However, they must follow these two rules:

  • The module must clearly document the backwards incompatible changes
  • The module must not make backwards incompatible changes in a minor release. (So 2.4.1 will maintain backwards compatibility with 2.4.0. But 2.5.0 could break compatibility).

Other than those two rules, maintainers are free to do what they think best, whether a deprecation period or introducing the break in the next major release.

[dagwieers]

I'd like to discuss: https://github.com/ansible/ansible/pull/25089 for v2.4. And also: https://github.com/ansible/ansible/pull/27738

• https://github.com/ansible/ansible/pull/25089
  • at today's meeting and general consensus was that we dislike this feature of the command module. We don't really want to add more commands to warn about because we don't like the general facility. There was some talk of ways to make it better but I estimate that the feature is low priority so if the warning mechanism was enhanced, it would probably have to be community contributed.
• https://github.com/ansible/ansible/pull/27738
  • We were more favorable towards this but we have to keep backwards compatibility. That probably means the change needs to be reworked to leave the old url_argument_spec() alone and write a new one that has the reduced set of parameters. we also talked about wanting to rework the urls API, that could be done at the same time or independently of creating a new url_argument_spec().
  • We didn't discuss, but I have looked at the url_argument_spec() before. I had troubles figuring out how to refactor it because making http requests is very generic and not every module will be able to implement every feature. For instance, some modules hardcode a http:// url which means they don't need either of the ability to specify a URL or the ability to tuoggle validate_certs.

[gundalow]

Ansible Contributor Summit 5 (Part of AnsibleFest 2017 San Francisco)

When: 2017-09-06: Notes: https://public.etherpad-mozilla.org/p/ansible-summit-september-2017 Event will be in person + online (Video + IRC)

Agenda is open for topics for the next Contributors Summit

Please add (and vote +1) for any topics.

[kustodian]

Modules set_facts and include_vars have misleading names and it would be a lot easier if they were renamed:

• set_facts -> set_host_vars
• include_vars -> include_host_vars because they actually do set/include host variables. This would be very easy to do, because modules can have aliases, so the modules can be renamed and because of compatibility reasons aliases to old names could be added (and maybe in future those aliases removed).

I was talking about this with @bcoca a few weeks ago, he told me that he wants to do this.

• Aug 17: so no opposition and some support, the names are in contention though .. no real agreement on what they should be. Looking at wider discussion to see if someone can come up with better/accurate/less misleading naming.

[mkrizek]

https://github.com/ansible/ansible/pull/22206

[dagwieers]

I'd like to get the Core team's opinion on functionality we need: https://github.com/ansible/ansible/pull/26889

• Aug 17: more support than opposition. wait_for and pause docs amended to indicate the existing ways of doing this. More discussion in future meetings.

[bcoca]

Meeting ended Thu Aug 17 16:19:12 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-17/core_community_meeting.2017-08-17-15.02.html Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2017-08-17/core_community_meeting.2017-08-17-15.02.txt Log: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-17/core_community_meeting.2017-08-17-15.02.log.html

[bcoca]

NOTE: meetings are canceled for the week Aug 21st to 25th due to 'all hands' meeting for the core team. We will resume normal schedule after that.

[abadger]

https://github.com/ansible/ansible/pull/26613 Digital Ocean module refactor is pulling code from modules (licensed GPLv3+) to module_utils. We currently require those to be BSD licensed. efforts to contact the authors are missing agreement from one person. We need to figure out what options we have here.

Last author gave consent. Code now relicensed and moved to module_utils

[dagwieers]

Another pass at the sleep module: https://github.com/ansible/ansible/pull/26889 I added "Benefits vs Drawbacks" to hopefully help making a decision next meeting.

@bcoca Feel free to amend that issue with your list of drawbacks.

[dagwieers]

I would like to discuss new functionality needed by the xml module:

• Introduce new 'required_by' param_spec option https://github.com/ansible/ansible/pull/28662

• Aug 29: Not enough support to add now, tabled to 2.5

[dagwieers]

Two items to raise that often come up during review (i.e. https://github.com/ansible/ansible/issues/20160 or https://github.com/ansible/ansible/pull/26675)

• From time to time new parameters are proposed with the unit as part of the parameter name, e.g. expire_seconds in win_toast or pre_reboot_delay_sec in win_reboot and two sides of preferences. (Same issue for return values).

• A common practice I have seen in modules is that the input parameters are put in the result output dictionary (usually at the start of the module). IMO there is no real value in returning the input parameters as return values again. (The user already has that information, why return it back to the user ?)

Can we come up with a guideline related to these to improve the documentation ?

• Aug 29:
  • Decided no 'unit' postfix on options
  • migrate existing 'unit suffixed' options to aliases and make 'unitless' the main focus
  • Proposed duration and datetime argspec types
  • Document that modules should not return their input arguments, invocation feature already does this

[bcoca]

@dagwieers those shoudl only appear on certain verbosity levels, they should NOT be done by module authors as ansible does this automatically. This is done because the inputs can be variables, but the 'invocation information' would be the actual values.

[bcoca]

Meeting ended Tue Aug 29 20:00:25 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-29/ansible_public_core_meeting.2017-08-29-19.05.html Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2017-08-29/ansible_public_core_meeting.2017-08-29-19.05.txt Log: https://meetbot.fedoraproject.org/ansible-meeting/2017-08-29/ansible_public_core_meeting.2017-08-29-19.05.log.html

[dagwieers]

Reopening as there is no new agenda created.

[kustodian]

All file modules should have a sane default follow parameter

https://github.com/ansible/proposals/issues/69