search

ansible / community

This repository is being archived. See https://github.com/ansible-community/presentations and https://github.com/ansible-community/meetings for the new locations
Apache License 2.0
489 stars 144 forks source link

Public Ansible Project Meeting Agenda - January 2018 #291

Closed thaumos closed 6 years ago

thaumos commented 6 years ago

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

When creating new agenda ensure core and meeting_agenda labels are set

thaumos commented 6 years ago

2018 - 01 - 02 Meeting

Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-02/ansible_core.2018-01-02-19.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2018-01-02/ansible_core.2018-01-02-19.00.txt Log: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-02/ansible_core.2018-01-02-19.00.log.html

itdependsnetworks commented 6 years ago

We will revisit this for the 2.7 release.

~Want to start back the conversations on gather_facts, current issue opened: https://github.com/ansible/ansible/issues/34109~

~Some backstory:~

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

~Meeting where it was previously decided not to change. https://meetbot.fedoraproject.org/ansible-meeting/2017-07-13/core_meeting.2017-07-13-15.00.log.html~

Relevant IRC logs:

[2017-04-20T12:45:26-0400] <sivel> I think regardless of 20717, there will still be a long tail on `setup`, since many people call setup directly
[2017-04-20T12:45:33-0400] <sivel> it may fix some problems immediately, but not all
[2017-04-20T12:45:58-0400] <@bcoca> sivel: _setup will be found for those using the action in module, but won't trip setuptools
[2017-04-20T12:46:08-0400] <@bcoca> ^ aliases!
[2017-04-20T12:46:13-0400] <@bcoca> first thing i implemented when hired
[2017-04-20T12:46:27-0400] <sivel> yeah, I was saying, if you still had a `setup.py`, people calling `setup` directly could still have problems
[2017-04-20T12:46:53-0400] <@bcoca> yes as it would still override
[2017-04-20T12:47:25-0400] <@bcoca> hence the 'long tail' of really getting rid of setup as we would have to push people to stop using it
[2017-04-20T12:48:10-0400] <@bcoca> itdependsnetwork: and at most it will be 2.4, we dont add features like that in minor versions
[2017-04-20T12:48:12-0400] <itdependsnetwork> ok, so that is why it is so long. It's not just "gather_facts: yes"
[2017-04-20T12:48:20-0400] <@abadger1999> bcoca: It will trip setuptools I think.  But the effect will be minimized
[2017-04-20T12:48:25-0400] <@bcoca> itdependsnetwork: if it were just that .. trivial
[2017-04-20T12:48:38-0400] <itdependsnetwork> ok, did not understand that
[2017-04-20T12:48:40-0400] <@bcoca> abadger1999: yes, that is the purpose of the PR, it will only trip for people explicitly using setup
[2017-04-20T12:48:42-0400] <@abadger1999> I think _setup.py and setup.py will still conflict in PluginLoader
[2017-04-20T12:48:58-0400] <@abadger1999> btut since ansible internally is calling gather_facts, it won't run into it internally
[2017-04-20T12:49:02-0400] <@abadger1999> <nod>
[2017-04-20T12:49:03-0400] <@abadger1999> yep.
[2017-04-20T12:49:05-0400] <@bcoca> my Pr makes setup an alias to allow for explicit calls, but removes it from implicit
[2017-04-20T12:49:05-0400] <@abadger1999> agreed
[2017-04-20T12:49:48-0400] <@bcoca> so it shoudl solve the problem for those in conflict with minor adjustment to playbooks that call setup explicitly
[2017-04-20T12:49:57-0400] <itdependsnetwork> If I am only worried about people doing a "gather_facts: yes" does 20717 fix?
[2017-04-20T12:50:00-0400] <@bcoca> for rest ... we need deprecation notice
[2017-04-20T12:50:08-0400] <@bcoca> itdependsnetwork: yes
[2017-04-20T12:50:13-0400] <itdependsnetwork> +1
[2017-04-20T12:50:23-0400] <itdependsnetwork> that is all I am worried about
[2017-04-20T12:50:40-0400] <@bcoca> sadly, we have to worry about more cases
[2017-04-20T12:50:42-0400] <@bcoca> but its a start
[2017-04-20T12:50:46-0400] <itdependsnetwork> I know :)
[2017-04-20T12:51:16-0400] <itdependsnetwork> and it is still considered too large to be considered for 2.3.X?

As per 6 month old subject to change info from: @thaumos should be looking to change in 2.5 

[2017-07-13T12:16:54-0400] <itdependsnetwork> just realized meeting is going on, did I miss facts vs setup talk?
[2017-07-13T12:17:02-0400] <thaumos> yep, issue was closed.
[2017-07-13T12:17:12-0400] <itdependsnetwork> meaning resolved?
[2017-07-13T12:17:20-0400] <thaumos> meaning we aren't merging in the change.
[2017-07-13T12:17:25-0400] <itdependsnetwork> why?
[2017-07-13T12:17:39-0400] <thaumos> because the plan is to change the way facts work in the near future.
[2017-07-13T12:17:54-0400] <thaumos> so it seemed silly to bikeshed around a name to have for something that won't exist in the future.
[2017-07-13T12:18:01-0400] <itdependsnetwork> in the meantime I am dealing with user issues that no one want to fix
[2017-07-13T12:18:12-0400] <itdependsnetwork> not so silly to me
[2017-07-13T12:18:43-0400] <thaumos> the intent is to change to the new framework within a release or two.
[2017-07-13T12:19:04-0400] <itdependsnetwork> I get it, I won't win
[2017-07-13T12:19:18-0400] <itdependsnetwork> just real frustrating on what will or won't get fixed
[2017-07-13T12:20:20-0400] <thaumos> It will get fixed by changing the framework.  The concept of "setup" as a module keyword won't exist in the next release.
[2017-07-13T12:21:28-0400] <itdependsnetwork> so there will or will not be a setup.py file in ansible module path in 2.4?
[2017-07-13T12:21:38-0400] <thaumos> in 2.4, there will be.
[2017-07-13T12:22:01-0400] <thaumos> in 2.5 there will most likely not

EDIT: @itdependsnetworks, thank you for bringing this to our attention again. This has been decided to put on hold until 2.7. I will cover this again on the 19 April meeting to start discussions on how to implement for that release.

jvanderhoof commented 6 years ago

~I'd like to talk through next steps for PR: https://github.com/ansible/ansible/pull/34280~

abadger commented 6 years ago

Would like a discussion and vote to deprecate and remove DEFAULT_MODULE_LANG and DEFAULT_MODULE_SET_LOCALE. MODULE_LANG was implemented to allow modules to screenscrape from CLI utilities that they invoked. However, that never worked well because our defaults used the local machine's locale which made the remote messages vary from user to user. We then created helper functions so that modules could set those environment variables prior to invoking any commands via AnsibleModule.run_command() and ported modules to use that. This was so successful that when people complained that we were setting LC_ALL, we were able to create MODULE_SET_LOCALE to let them completely disable the use of MODULE_LANG and modules continued to work. In 2.2 we changed the default of MODULE_SET_LOCALE to False and no one seems to have noticed. I think it's time that we deprecate these settings and get rid of them in 4 releases.

Deprecating this was approved at the January 9th meeting.

pilou- commented 6 years ago

I would like to discuss: - https://github.com/ansible/ansible/pull/25519 (filesystem module) - https://github.com/ansible/ansible/pull/33967 (add and use check_file_absent_if_check_mode method in lib/ansible/module_utils/basic.py)

discussed (1) and (2) was already merged.

maxamillion commented 6 years ago

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

~In Ansible 2.3, it appears that the function _get_hostgroup_vars from the Inventory class handled the scenario of a playbook that included another playbook and kept the path of the original playbook in scope. However, in 2.4 with the transition to inventory plugins, the basedirs for the playbook are determined by the DataLoader which doesn't appear to have any knowledge of the original playbook that did the include/import. I would like to discuss a preferred method to handle playbook adjacent group_vars directories in Ansible >2.4.~

~(Thanks to bcoca, jimi-c, and sivel for helping me get to the root cause of this)~

Decision: we won't bring this back, it's been classified as a bug that has been resolved. Porting guide for 2.4 will be updated.

sivel commented 6 years ago

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

~LooseVersion comparison in py3 is subject to exceptions due to comparing int and str. That PR implements a potential fix, but it applies elsewhere too, not just to galaxy role version comparison.~

~Do we go with that PR, move the new class to a different location for use elsewhere (module_utils)? Or do we want to think about using pypa/packaging instead. SafeLooseVersion would be easier to ship in module_utils for modules that can utilize it.~

Going to handle these LooseVersion issues on a case by case basis for now. Will evaluate galaxy version spec plans

gundalow commented 6 years ago

Deprecation

While working on https://github.com/ansible/ansible/pull/34100 it seems there is some confusion around what version means in terms of deprecation

Currently we have a few ways of notifying of deprecation in Ansible:

  • Module deprecation (git mv $foo.py _$foo.py & deprecation: in DOCUMENTATION block)
  • module.deprecate(("State 'removed' is deprecated. Using state 'absent' instead.", version="2.9")
  • display.deprecated('Use foo instead', version='2.4')
    • version here is used inconsistently to mean start or end of cycle.
  • Deprecation in config
  • anywhere else?

Since the original code was added for the above we have versioned documentation. Which makes some of the easier.

There is confusion if version means "start of deprecation cycle" or "end of deprecation cycle"

Questions/ideas

  1. Should the above all mean the same

    1. will_be_deleted_in_version
      • = (version of devel + 4)
      • If we ignore that there may not be a 2.9, and we jump straight to 3.0, is this OK?
    2. deprecated_as_of_version
      • When the code was updated = deprecated as of version
      • We now have versioned documentation
      • Are there ever any cases of wanting to give notice that something will be deleted, but we don't know exactly which release?

  2. Should we rename the variable to be clearer

  3. Better docs

    1. Deprecated modules to link to the porting page
    2. Porting page to link to Maintenance and releases page

  4. When devel version++ how can we detect the three cases and git rm as needed?

Porting page: http://docs.ansible.com/ansible/devel/porting_guides.html

Maintenance and releases page: https://docs.ansible.com/ansible/devel/release_and_maintenance.html

At today's meeting we decided to:

andreaso commented 6 years ago

Would like to bring up the _cloudflaredns bugfix https://github.com/ansible/ansible/pull/31800, and woulat it would take to get it merged.

My IRC nick is andol.

gundalow commented 6 years ago

The 2.5 freeze dates (merge deadlines) have been pushed out by a week.

Please see updated dates https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_5.rst

To see whats change please see https://github.com/ansible/ansible/commit/1826c27e6841eb313dc3a05dc7f19c96e42c7fbf

thaumos commented 6 years ago

2018 - 01 -09 Meeting

Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-09/ansible_core.2018-01-09-19.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2018-01-09/ansible_core.2018-01-09-19.00.txt Log: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-09/ansible_core.2018-01-09-19.00.log.html

tdtrask commented 6 years ago

I would like to discuss https://github.com/ansible/ansible/issues/34325 and the fix at https://github.com/ansible/ansible/pull/34419. The fix ensures that any packages set to 'present' are installed as top-level packages, not just as dependencies for other packages. The new concern raised by @abadger is for state 'absent'. For the Alpine Linux apk package manager, it is not possible to uninstall a package that is installed as a dependency. In fact, the add and del subcommands do not directly install or remove packages. What they do is add rules to the /etc/apk/world file, which are then implemented by the package manager based upon dependencies. The question is whether 'absent' should fail if the package is still installed as a dependency of another package.

Update of what happened in last week's meeting:

gundalow commented 6 years ago

Proposal: Standard way to influence return values From @dagwieers https://github.com/ansible/proposals/issues/93 At today's meeting we decided that we don't currently have enough use cases to tell if there should be an ansible-wide standard for this. Talked with dag about various ways that might work for the ACI modules as a local standard.

dagwieers commented 6 years ago

Another one: https://github.com/ansible/ansible/pull/26889

We talked about this at today's IRC meeting and it seemed most people were okay with addressing this use case. However, we were resistant to adding a new module/action plugin for it. If this could be merged into the existing pause or wait_for modules/action_plugins, that seems like something we can look at..

thaumos commented 6 years ago

2018 - 01 - 11 Meeting:

Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-11/ansible_core.2018-01-11-15.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2018-01-11/ansible_core.2018-01-11-15.00.txt Log: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-11/ansible_core.2018-01-11-15.00.log.html

abadger commented 6 years ago

2018 - 01 - 16 Meeting

sivel commented 6 years ago

~Inventory paths with commas: https://github.com/ansible/ansible/pull/35002~

Akasurde commented 6 years ago

~I would like to discuss an idea about new label to identify work progress of issue. This label can be applied to issue which has an open PR. Something like has_pr or working.~

~This will identify if there is a PR or not without even opening this issue's details page.~

We've created has_pr and will move forward with doing it manually during triage, and get bot functionality added.

gundalow commented 6 years ago

2018-01-18 Meeting:

gundalow commented 6 years ago

Autogenerated modules

https://github.com/ansible/ansible/pull/35014 (gundalow, 15:06:51)

* #35014 has till the "community" freeze as a) None of GCP is support: core b) module_util changes are only to new in 2.5 modules, therefore no risk of breaking anything else (gundalow, 15:47:10)

* OPTION 1) We have the bot and ANSIBLE_METADATA dictate auto closing issues or PRs for these modules. (requires a proposal) ~~* OPTION 2) 100% ignoring that they are auto generated (no exceptions), no pointing people elsewhere, just forgetting where they came from, treated like any other module Remember to consider how this applies to existing auto generated modules, such as network/avi~~

thaumos commented 6 years ago

2018 - 01 - 23 Meeting

Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-23/ansible_core.2018-01-23-19.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2018-01-23/ansible_core.2018-01-23-19.00.txt Log: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-23/ansible_core.2018-01-23-19.00.log.html

maxamillion commented 6 years ago

An user suggests that the service module should not error when taking action on services that are not installed on the remote host, but I disagree. However, I would be interested in the consensus from the community on this topic.

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

Decision is to leave behavior as is (failing when the service does not exist)

thaumos commented 6 years ago

Vote on changing Thursday's time from 1500 UTC. Suggesting 1600 or 1700 UTC.

EDIT Feb 1st: 2 more votes collected, bringing total to +1:6 , 0:2 , -1:2

maxamillion commented 6 years ago

+1 to either 1600 or 1700 UTC

eikef commented 6 years ago

I'd like to request a further review of ansible/ansible#33419 and merge if possible.

thaumos commented 6 years ago

2018 - 01 - 25 Meeting:

Minutes: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-25/ansible_core.2018-01-25-15.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-meeting/2018-01-25/ansible_core.2018-01-25-15.00.txt Log: https://meetbot.fedoraproject.org/ansible-meeting/2018-01-25/ansible_core.2018-01-25-15.00.log.html

Akasurde commented 6 years ago

~I would like to discuss these issues - related to Python 3.6 and LooseVersion. Following issues are occurred due to this -~

Basic cause of this is Python Bug

evrardjp commented 6 years ago

~I'd like to discuss the inclusion of config_template as a community action plugin. https://github.com/ansible/ansible/pull/35453 .~

~Discussion from previous PR https://github.com/ansible/ansible/pull/12555#issuecomment-224011966~

The decision here was that we are not sold on the current action plugin. Instead the recommendation would be to add yaml and json modules (not action plugins) that operate in the same manner as ini_file and xml.

sivel commented 6 years ago

Should we support old TLS/SSL versions: https://github.com/ansible/ansible/pull/35462