Community: Public Core Meeting Agenda - Feb 2017

Created on 2 Feb 2017  路  37Comments  路  Source: ansible/community

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

core meeting_agenda

Most helpful comment

I think a new discussion is in order on how to tackle the "modules are used for adding, changing, removing and giving information about an object".

Discussion triggered by: https://github.com/ansible/ansible/pull/20399#pullrequestreview-18432297

We have modules that allow state=list (or state=info), other (sets of) modules have _facts or _stat variants and here the contributor was requested to leave it out and assume that an undefined "state" means returning information, rather than making changes.

Migrated to https://github.com/ansible/community/issues/156

All 37 comments

Re-migrated ansible/ansible#19016

  • 2016-12-13: currently waiting for JMainguy to have a chance to look.
  • 2017-02-02: Waiting on one documentation change from submitter then ready to merge
  • 2017-02-09: Waiting on one documentation change from submitter then ready to merge.
  • 2017-02-14: Waiting on one documentation change from submitter then ready to merge.
  • 2017-02-16: Waiting on one documentation change from submitter then ready to merge.

Merged to devel

Re-moved ansible/ansible#19070 win_file: fix error when creating an existing dir

  • nitzmahone has this on his list.
  • 21 Feb: nitzmahone should be able to get to this later this week (likely Thursday)

Moved to https://github.com/ansible/community/issues/153

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

  • Decision: to document ANSIBLE_LIBRARY as the official way to achieve this functionality.
  • abadger: Documentation is part of this PR: ansible/ansible#20913

Merged

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

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

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)

https://github.com/ansible/ansible/pull/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, sivel

    • +0 ryansb jctanner, gundalow

    • +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.

    • Community votes (not counted but advisory) , +1 jtyr, -1 allanice001

Decision made to reject this new feature. abadger to update the ticket.

feature proposal: https://github.com/ansible/ansible/pull/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 31 meeting: podlesh has some examples of use case that don't seem to be solvable by merely enhancing sorting and grouping independent of serial. bcoca and jimi-c not present. Will discuss at meeting feb 7
  • Feb 7 meeting: Discussed how to perform examples without serial_group_by... seemed possible but rather complex. After more discussion we decided that this may be a mismatch of feature and existing concept. Advised looking into implementing this as a strategy plugin rather than a new play-level keyword. There were some reservations about whether we'd accept that into the core codebase either but outlook for it was better (a plugin is isolated whereas a keyword's code is present for everyone) and a plugin can also be shipped via a role on galaxy if it is not accepted.

We decided to reject this new feature. abadger will close out the ticket.

From @jtyr: https://github.com/ansible/ansible/pull/19283 hosts module (for /etc/hosts)

  • 2 Feb meeting: All issues that are solvable by code resolved.

    • Need to make a decision on whether this overlaps too much with existing modules/roles. Will discuss and probably call for a vote on Thursday (9-Feb) meeting (jtyr cannot make Tuesday meeting)

2017-02-09

<@bcoca> -1
< thaumos> -1 imo, a module like this is redundant. There's template or lineinfile (which I dread).
<@rcarrillocruz> -1, imho modules should be base building blocks, tthere are enough foundations to do this with a role and/or current modules
<@jtanner> -1 because i don't want to deal with all the tickets complaining about $ODDBALL_HOSTS _SCHEMA
< allanice001> -1 (non-core vote)
< akasivel> -1 I don't believe it necessary and I personally wouldn't use it. (none-core vote)

<@mattclay>+0 I see a little benefit of the validation, but it's not much more than just template/lineinfile
< shertel> +0
<@gundalow> +0 For the points that jtanner said, though I think it has some use

abadger1999 +1

< albertom> +1 while line in file does the job, i etc_hosts saves me from the regex
jtyr +1 (the creater

-1:5, 0:3, +1:1, so this module was not accepted for merge due to redundancy with template and concerns about cross-platform maintainability. can still be hosted on galaxy (and hopefully we'll have a time frame for when ansible-installer can make things hosted on galaxy more discoverable).

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

  • 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

Moved to https://github.com/ansible/community/issues/156

From 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 https://github.com/ansible/ansible/issues/20440

also document once decided so users KNOW what to expect

Migrated to https://github.com/ansible/community/issues/156

From rfleschenberg versioned docs
Summarizing previous discussion

Migrated to https://github.com/ansible/community/issues/156

https://github.com/ansible/ansible/pull/20058 Add systemd-nspawn connection driver

  • 31 Jan: reviewed by abadger, waiting on submitter to fix up
  • 9 Feb: Updated made, abadger to review
  • 2017-02-14: Waiting for updates to address code review
  • 2017-02-16: Waiting for updates to address code review
  • 2017-02-21 MERGED
  • Plugin reverted, seems that systemd nspawn creates a new container on every command. With no persistence ansible's model doesn't work with the nspawn containers.

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

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.

Migrated to https://github.com/ansible/community/issues/156

@bcoca Yeah, such process would be really useful because I'm not happy about the result of the Proposal #50 at all ;o(

Not an agenda item

@jtyr this is not a revision on that decision (I suggest you open your own agenda item for that) but on the process that should be followed on proposals and the time needed to allow for community feedback.

Not an agenda item

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


This PR was discussed at length internally and we couldn't come to an agreement one way or another, so putting it on the agenda for wider discussion. I'll try to summarize some of the key points of the discussion here:

  • environment variables are not a secure place for secrets, use a file with proper permissions
  • standard practice on many CI systems is to expose credentials in environment variables
  • having the feature would encourage misuse (use in situations other than CI systems)
  • if the feature is supported, a runtime warning should be given which can't be disabled
  • the feature isn't needed (see work-around provided in the PR comments)
  • lack of the feature may increase chances of logging the password (bash -x), CI artifacts

Apologies if I missed any key points from the discussion, it ran over the course of ~1 hour.

Rejected by vote of -4 +2
Use the work-around provided in the PR comments.

I'd like to discuss ansible/ansible#19264. "Added in bullet of Python 2.4+ support discontinuation"

Merged

I would like to discuss https://github.com/ansible/ansible/pull/20834 Add swupd plugin
my irc nick is albertom

Discussed 9th Feb 2017

ACTION: bcoca (if he has time) to review the code. albertom knows we are close to the 2.3 cut off, so we can't guarantee it will make it in for 2.3
ACTION: albertom to review feedback from meeting, continue discussion in #ansible-devel

MERGED

I would like to discuss https://github.com/ansible/ansible/pull/20703 Fixing broken bind mount on CentOS 7

Edit: Discussed in the #ansible channel with @abadger and it seems to be "good to go".

https://github.com/ansible/ansible/issues/18453 "pycrypto not listed in the Python package requirements list"

How do we:

  1. Update the requirements in documentation
  2. Prevent future desync between setup.py and docs

14 Feb Meeting

  • This issue highlighted: 1) Update the requirements in documentation 2) Prevent future desync between setup.py and docs
  • Sivel suggested: Maybe we could move the requirements to install into a requirements.txt file that is referenced by setup.py as well as the instructions specifying to utilize the requirements.txt instead of listing the packages separately in 2 locations? Just a thought, as I've seen this done elsewhere
  • ACTION: abadger and sivel to figure out how to implement docs and stup.py using the same requirements.txt to install dependencies.
  • https://github.com/google/google-apputils
  • Docs side we change it to: pip install -r requirements.txt

Post meeting https://github.com/ansible/ansible/pull/21430 "Move to using a requirements.txt to install the python packages. " was merged

https://github.com/ansible/ansible/issues/21299 Add "idempotence check" section to module docs

14th Feb Meeting

  • a) not all modules are idempotent
  • b) that can get complicated
  • c) notes; already exist as well as you can add to descriptions of 'state'
  • d) all the more docs to become outdated with
    Votes:
    -1: jtanner, thaumos, ryansb, gundalow, abadger2000, mattclay, sivel, allanice001 (8) (gundalow, 19:52:23)
    +0: bcoca (gundalow, 19:52:30)
  • AGREED: No to updating a new field
  • ACTION: gundalow to add some words to developing_modules_documenting.html's notes: regarding "for example if check_mode is only supported with some

Can we merge wait_for_connection action plugin ? ansible/ansible#20011

16th Feb Meeting

  • ACTION: dag / jhawkesworth to talk mattclay about integration test

Has been merged

Facts modules not using ansible_fact argument to exit_json https://github.com/ansible/ansible/pull/19910#issuecomment-278496104

16th Feb Meeting

  • The new azure facts modules are offenders in this area- IIRC in that case it was done purposely. Returning everything as facts automatically pollutes the global namespace and means you're carrying everything and forever that module returns.
  • ACTION: @dagwieers to write a proposal

Will be tracked via proposal

How to get this going: ansible/community#152 Windows Working Group

16th Feb Meeting

21 Feb Meeting

  • Alternating weeks of Monday afternoon and Friday morning (US Pacific time) have been agreed upon
  • nitzmahone and mattclay will update public calendars with the exact times and dates.

It lives: https://github.com/ansible/community/issues/153

https://github.com/ansible/ansible/pull/21764 CyberArk Initial Support

IRC nickname is enunez-cyberark

Has been reviewed waiting on updates. Will now follow standard review process

I would like to discuss https://github.com/ansible/ansible/pull/20405 (win_copy: Add force parameter and check-mode support), specifically to see if we can

  • reach an agreement about the copy action plugin behavior.
  • Would adding an optional 'check_method' parameter be acceptable?
  • Or is there a better way to solve this problem?

Merged, no further discussion needed

Ansible Core 2.1.5RC1 and 2.2.2RC1 are available for testing
https://groups.google.com/forum/#!topic/ansible-devel/VnHIVtzuyzs

I'd like to discuss https://github.com/ansible/proposals/issues/14 Proposal: Module Rename Lifecycle
IRC nick == ryansb

I would like to discuss

  • merging aws_api_gateway

    • status - more or less ready for an initial merge / somewhat limited functionality

  • merging lambda_policy

    • status - had initial feedback ; about to start making fixes

  • improving other aws modules in particular

    • getting RDS module to use boto3 / support SSD

I would like to discuss what the process is when

  • Original module author not responding to PRs (i.e. authors possibly left community)
  • Assign new module maintainers to an existing module

Migrated to https://github.com/ansible/community/issues/156

I think a new discussion is in order on how to tackle the "modules are used for adding, changing, removing and giving information about an object".

Discussion triggered by: https://github.com/ansible/ansible/pull/20399#pullrequestreview-18432297

We have modules that allow state=list (or state=info), other (sets of) modules have _facts or _stat variants and here the contributor was requested to leave it out and assume that an undefined "state" means returning information, rather than making changes.

Migrated to https://github.com/ansible/community/issues/156

Related to https://github.com/ansible/ansible/pull/21874 we disabled the standard expanduser/expandvars in a lot of internal module_utils functions. And it appeared that (at least) none of the integration tests rely on this specific expanding of user/vars of paths. Since we usually expand directly as part of processing parameters, it seems we don't actually need this on different levels (and in the case of unarchive in this specific case it was undesirable and potentially a security problem).

The question being: can we get rid of these expanduser/expandvars calls here ? And if so, what's the process to get it done.

Migrated to https://github.com/ansible/community/issues/156

Update to the metadata format: https://github.com/ansible/proposals/issues/54

Want to update the metadata format prior to 2.3 to get rid of some warts that have been identified post-implementation.

Migrated to https://github.com/ansible/community/issues/156

Open items have been moved to March's agenda https://github.com/ansible/community/issues/156
Windows Community is up and running, please see https://github.com/ansible/community/issues/153

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mscherer picture mscherer  路  6Comments

dagwieers picture dagwieers  路  26Comments

pm98zz-c picture pm98zz-c  路  5Comments

gundalow picture gundalow  路  11Comments

jillr picture jillr  路  8Comments