Community: Public Core Meeting Agenda - June, July 2017

Created on 6 Jun 2017  路  59Comments  路  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

All 59 comments

@gundalow would like to discuss https://github.com/ansible/proposals/issues/65

@erasmix would like to discuss PR#21857 and PR#21764

@pilou- would like request reviews for PR#23862.

@dagwieers would like to discuss "guidance on ordered dictionaries for Windows modules. I prefer a common solution. ansible/ansible#25265 (comment)"

@dagwieers

Would like to discuss:

The purpose of connection: local -- ansible/ansible#24083
Allowing host-lists (rather than dicts) in YAML inventories -- ansible/ansible#22567

@cyberark-bizdev would like to discuss PR#21857 and PR#21764

@erasmix will be attending
@cyberark-bizdev will be in standby for discussion

@azaghal would like to discuss if there is anything else they could do to have the following pull requests merged:

@alikins would like to discuss the fact related prs at

Both add more detail about storage devices and mount points to facts that could be useful, but could also be too much.

I'd like to discuss autotagging roles with their name: https://github.com/ansible/ansible/pull/25132

Edit:
Follow-up in proposal https://github.com/ansible/proposals/issues/66

@cben I'd like to discuss https://github.com/ansible/ansible/pull/25106,
first step of contributing ManageIQ modules from https://github.com/dkorn/manageiq-ansible-module/

Ansible Contributor Summit 4 (Part of AnsibleFest 2017 London)

Agenda for Contributor Summit has finalised can be found at https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-agenda.

As a reminder, it will be in #ansible-meeting and BlueJeans

Note that there are sub pages for each topic. It's on the sub pages where you can add any topics there, rather than on the main agenda page.

NO MEETING: Tuesday 20th June

NO MEETING: Thursday 22th June

NEXT MEETING: Tuesday 27th June

@thaumos I think you mean June :)

And is there a core meeting today (Thursday 15th June)?

Can you add the review of:

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

to the list?

@cben, there is one today.

Of course I meant June! I don't know why you all are saying otherwise ;-)!

@itdependsnetworks, I am going to review this PR. So stand by.

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.

Simple to merge

  1. https://github.com/ansible/ansible/pull/23339 - a trivial bug fix in hacking - a docs question arose, but that should be a separate PR merged
  2. https://github.com/ansible/ansible/pull/23988 - a bug fix for postgresql - this lacks tests, however that in no way makes the situation worse than currently. The tests will require creating an RDS so really depend on https://github.com/ansible/ansible/pull/25646 below - thus waiting for them will considerably delay this. merged
  3. https://github.com/ansible/community/pull/187 - community / needs AWS

Needs AWS CI Permissions then should be reasonable merge

  1. https://github.com/ansible/ansible/pull/25646 - RDS split updated with new integration tests
  2. https://github.com/ansible/ansible/pull/24951 - Lambda policy with tests
  3. https://github.com/ansible/ansible/pull/24722 - Lambda integration tests
  4. https://github.com/ansible/ansible/pull/26059 - Lambda using new aws utils

Needs comments and reviews.

  1. https://github.com/ansible/ansible/pull/25780 - aws module with AnsibleAWSModule class in module utils
  2. https://github.com/ansible/ansible/pull/26594 - rds.py utilities file

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

I would like to discuss PR# 21857 and 21764

I would like to discuss PR ansible/ansible#25950 and PR ansible/ansible#26028

we need to discuss getting rid of docstring format for metadata for 2.4 (this was only added for 2.4).

* Docstring format is currently unwritable by tools as it was added without updating metadatatool.py to handle the format.
* The docstring format adds a third way that metadata could be implemented (in addition to dict format and yaml string format).
* The docstring format is unnecessary for metadata. It was added for making documentation of filters and tests. Unlike documentation, we do not want each individual filter in a file to have its own metadata. Trying to tell people (and the bots) that "only these three functions in filters/mathstuff.py are supported by core. All the rest are supported by community" will be horridly painful. We should just separate out the filters that have different metadata into different files.

I would like to discuss https://github.com/ansible/ansible/pull/24576 and https://github.com/ansible/ansible/pull/25791 which both attempt to tackle the same issue (making a subset of documentation).

Discuss changing current behavior of failed filter now that core engine ignores the rc task return value- current implementation of failed triggers on nonzero RC, but it probably shouldn't anymore. (win_command/win_shell failure tests were false-passing in devel due to this issue)

ansible/ansible#26335

Apologies, I won't make the meeting (5am) but would like to get it either merged or feedback as to any further improvements / alternative implementations.

Could you please add ansible/ansible#20717 to today's agenda? I will try and be on.

Improve YAML inventory support: https://github.com/ansible/ansible/pull/22567~~

Hello, I would like to speak about a project I began : KIKIN
KIKIN helps to start with Ansible.
It manages user database, ssh keys generation, hosts connections and SSH parameters.

I think it can help system admins to quickly test Ansible and simply begin to use it. Code in very beta state is available here : https://owncloud.liberasys.com/index.php/s/IqmOWKJQ6X44HI8

Nickname I will use : ghusson (Liberasys is the commercial name of my company)

For next meeting I would like to speak about https://github.com/ansible/ansible/pull/26641

Introducing testing suite for openssl_* modules https://github.com/ansible/ansible/pull/26684

Introducing https://github.com/ansible/ansible/pull/22756 (support multiple vault passwords)

For the next meeting I'd like to talk about the HPE OneView FcNetworkModule https://github.com/ansible/ansible/pull/26026~~

I would like to discuss merging https://github.com/ansible/ansible/pull/25323 (new xml module)

I would like to discuss: ansible/ansible#26729 (fix searched paths in DataLoader.path_dwim_relative).

@dagwieers, we'll still cover your item when you hop onto the next meeting!

I would like to discuss introducing https://github.com/ansible/ansible/issues/15460~~

When the fetch module downloads a single file to a directory specified without a trailing slash it currently downloads the file and then errors out. One of those is a bug, we need to decide which one in order to fix it. Full details: https://github.com/ansible/ansible/issues/27312~~

Where is the issue for the next meetings in August, has that already been created?

If we get august ticket , add this https://github.com/ansible/ansible/pull/18662 (mostly to bikeshed on option name)

Add PR# 27519 for discussion: https://github.com/ansible/ansible/pull/27519~~

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
python~~ ~~ansible_os_distribution~~ ~~
becomes accessible as
python~~ ~~facts.os_distribution~~ ~~
rather than the existing implementation
python~~ ~~ansible_facts.ansible_os_distribution~~ ~~
This will be a lot more convenient writing playbooks then the current implementation.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

gundalow picture gundalow  路  3Comments

dagwieers picture dagwieers  路  26Comments

thaumos picture thaumos  路  26Comments

gundalow picture gundalow  路  11Comments

decentral1se picture decentral1se  路  16Comments