Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Ansible2.8 #4778

Closed
rhockenbury opened this issue May 16, 2019 · 23 comments
Closed

Support Ansible2.8 #4778

rhockenbury opened this issue May 16, 2019 · 23 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Milestone

Comments

@rhockenbury
Copy link
Contributor

What would you like to be added:
Ensure kubespray is compatible with Ansible 2.8

Why is this needed:

@rhockenbury rhockenbury added the kind/feature Categorizes issue or PR as related to a new feature. label May 16, 2019
@schmitch
Copy link

schmitch commented May 17, 2019

Actually there is a regression for: ansible/ansible#50009 #1600

Currently it fails with:

TASK [bootstrap-os : Assign inventory name to unconfigured hostnames (non-CoreOS, Suse and ClearLinux)] ************************************************************************************************************************************************************
[DEPRECATION WARNING]: evaluating override_system_hostname as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in
version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: evaluating override_system_hostname as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in
version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: evaluating override_system_hostname as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in
version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: evaluating override_system_hostname as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in
version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: evaluating override_system_hostname as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in
version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
fatal: [master3]: FAILED! => {"changed": false, "msg": "hostname module cannot be used on platform Linux (Coreos)"}
[DEPRECATION WARNING]: evaluating override_system_hostname as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in
version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
fatal: [node1]: FAILED! => {"changed": false, "msg": "hostname module cannot be used on platform Linux (Coreos)"}
fatal: [master1]: FAILED! => {"changed": false, "msg": "hostname module cannot be used on platform Linux (Coreos)"}
fatal: [master2]: FAILED! => {"changed": false, "msg": "hostname module cannot be used on platform Linux (Coreos)"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "hostname module cannot be used on platform Linux (Coreos)"}
fatal: [node3]: FAILED! => {"changed": false, "msg": "hostname module cannot be used on platform Linux (Coreos)"}

btw. after dowgrading to ansible=2.7.9 pip install ansible==2.7.9 it works just fine.

@puneethkosaraju
Copy link

mine is failing with below error with ansible 2.8.0, works fine with 2.7.10

"reason": "'delegate_to' is not a valid attribute for a TaskInclude\n\nThe error appears to be in '/tmp/ansible.OCmOWrk8s_setup/kubespray-2.8.3/roles/download/tasks/download_container.yml': line 2, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n---\n- name: container_download | Make download decision if pull is required by tag or sha256\n ^ here\n"

@rhockenbury
Copy link
Contributor Author

@puneethkosaraju - See #3985

rodrigc pushed a commit to portworx/kubespray that referenced this issue May 22, 2019
rodrigc pushed a commit to portworx/kubespray that referenced this issue May 22, 2019
@rhino5oh
Copy link

rhino5oh commented May 23, 2019

@rhockenbury the issue you linked has been closed just FYI (although it does have some good info about the errors seen when using ansible 2.8, i.e. "'delegate_to' is not a valid attribute for a TaskInclude"). This issue should probably be the go-to for ansible 2.8 support

@MarkusTeufelberger
Copy link
Contributor

The hostname module for Ansible 2.8.0 is still broken on CoreOS, OpenSUSE Leap and ClearLinuxOS (ansible/ansible#42726).

Their names are a bit different now in ansible_os_family, so this might throw the bootstrap-os role off a bit. Either we could wait for Ansible 2.8.1 and require this as minimum Ansible version or I could add a few more exceptions to the current workaround and then remove it all later when Ansible >= 2.8.1 is being required.

@MarkusTeufelberger
Copy link
Contributor

ansible_os_family is used quite a bit within kubespray, I expect a LOT more things to break in subtle ways since the names in there could have changed.

@samdoran
Copy link

We had to switch to using distro since platform.distribution() is being deprecated by upstream Python.

ansible_os_family should not change, but distribution information may change slightly. If ansible_os_family is incorrect, please open an issue.

@pwyoung
Copy link

pwyoung commented Jun 17, 2019

EDIT: Release 2.10.4 was just released and does pin Ansible to 2.7.x
https://github.com/kubernetes-sigs/kubespray/blob/v2.10.4/requirements.txt

FWIW, the latest 2.10 branch does pin the Ansible version, but the commits in the official releases (e.g. 2.10, 2.10.3) don't pin Ansible version

Kubespray does not support Ansible 2.8

#4778

Due to a change in Ansible behaviour (noted in Ansible deprecation docs),

Kubespray will fail if run with Ansible 2.8

#3985

The latest commit in the 2.10 branch pins the Ansible version (to 2.7.x)

https://github.com/kubernetes-sigs/kubespray/blob/release-2.10/requirements.txt

But the official release commits do not pin the Ansible version

https://github.com/kubernetes-sigs/kubespray/blob/v2.9.0/requirements.txt
https://github.com/kubernetes-sigs/kubespray/blob/v2.10.0/requirements.txt

Latest, as of today, 2019-06-17

https://github.com/kubernetes-sigs/kubespray/blob/v2.10.3/requirements.txt
https://github.com/kubernetes-sigs/kubespray/blob/d53782a7f1791d46c0e3779cbc9a258ad492c2b9/requirements.txt

So, if folks run the official versions, and don't already have Ansible 2.7 installed they are going to hit this issue.

@MarkusTeufelberger
Copy link
Contributor

MarkusTeufelberger commented Jun 24, 2019

Should 2.8 support be exclusive (2.7.x no longer supported) or should Kubespray work with both 2.7 and 2.8?

Edit: Hostname fixes made it in for 2.8.2 (ansible/ansible#58211), if Ansible >=2.8.2 gets targeted, we could drop a small workaround in bootstrap-os! :-)

@Atoms
Copy link
Member

Atoms commented Jul 10, 2019

if possible we should make 2.7 stay supported

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 8, 2019
@hedayat
Copy link
Contributor

hedayat commented Oct 8, 2019

I just wanted to mention that I used kubespray (a pre-2.10.3 version) with ansible 2.8.5 with no issues under Fedora deploying to Ubuntu.

I also see that all mentioned bugs are fixed, although at least 2 of them are reported against ansible 2.7.5 and 2.6 versions; nothing new for 2.8

@fentas
Copy link

fentas commented Oct 19, 2019

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 19, 2019
@muff1nman
Copy link
Contributor

FYI I ran into this issue with ansible 2.8.5:

TASK [download : prep_kubeadm_images | Copy kubeadm binary from download dir to system path] ************************************************************************************************************************************************
fatal: [XXXX->XXXX]: FAILED! => {"changed": false, "cmd": "sshpass", "msg": "[Errno 2] No such file or directory", "rc": 2}

Even after installing sshpass I still had troubles with a broken pipe error which I believe is the same as this:

ansible/ansible#56629

Downgrading to ansible 2.7 does not have this issue.

@GerardoGR
Copy link

Using the Vagrantfile to run local VMs, ansible version 2.8.5 works fine.

@Miouge1
Copy link
Contributor

Miouge1 commented Nov 21, 2019

FYI I'm working on Ansible 2.9 support in #5361

@Miouge1
Copy link
Contributor

Miouge1 commented Dec 12, 2019

Now that #5361 is merged can we consider this resolved?

@MarkusTeufelberger
Copy link
Contributor

Does it work on all supported platforms?

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 21, 2020
@Miouge1 Miouge1 removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 27, 2020
@Miouge1 Miouge1 added this to the 2.14 milestone Mar 27, 2020
@Miouge1
Copy link
Contributor

Miouge1 commented Mar 27, 2020

Related to #5842

@champtar
Copy link
Contributor

For people watching this issue, if you want to comment in #5847, I bump ansible to latest 2.9 so that the CI tests the latest and greatest

@Miouge1
Copy link
Contributor

Miouge1 commented Apr 14, 2020

Since #5847 Kubespray is using Ansible 2.9

/close

@k8s-ci-robot
Copy link
Contributor

@Miouge1: Closing this issue.

In response to this:

Since #5847 Kubespray is using Ansible 2.9

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests