-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
boostrap-os: badly formed task file included #11152
Comments
Through troubleshooting I was able to get beyond these errors by modifying - name: Include tasks
include_tasks: "{{ item }}"
with_first_found:
- <<: *search
paths:
- tasks/ubuntu.yml Obviously this is not desired nor how this should work so I assume that there is a bug or something in my environment causing this? |
I think this means the included tasks file is wrongly formatted (the no hosts matched is normal, it's compat stuff for legacy group names) Can you execute the playbook with more verbosity ( Maybe it's doing something and executing the vars/ files instead ? 🤔 Not sure why that would only happens in ARM64 but you never know... |
Attached is the output using |
Well still nothing on the included files... Does more verbosity show something else for that task specifically?
|
/retitle boostrap-os: badly formed task file included
|
hmm I did this on a whim as I also got the error, the steps below seem to resolve it i then ran the created inventory file from the inventory.py file in my case its i then set the env var then I ran the following command it should be noted that you don't need to have the i got this as the final output
and didn't get the warnings about the duplicate key dictionary hope this helps aid in the debugging hmm actually upon further tests, the error still persists |
Same issue. Unable to upgrade as the playbook terminates almost immediately. |
Re-reading the OP, it seems this happens in check mode. Is it also the case for you ?
|
I did not run it in check mode as I was applying to a non-production qualification cluster
is failing the way described by the OP |
Ok, so it would seem to be the interaction between symlinks (ubuntu, opensuse-* and openEuler tasks are symlinks) and the first_found lookup ?
This is pretty weird, and looks like and ansible bug. We should check if it's a known one. |
What's the Filesystem of the ansible controller ? (wondering if this could have an impact) |
I think I got it.
as a countermeasure to git CVE-2024-32004, high resetting git |
Ok, I see.
So that should only happens with core.symlinks false and using kubespray
from git, not with the container image or from an archive (and from
collections if we had a non-git collection installable)
|
What happened?
Running the command
ansible-playbook -i ./inventory/mycluster/hosts.yaml cluster.yml -K --check -b
results in the following output:What did you expect to happen?
I expect hosts to be matched and tasks to be included
How can we reproduce it (as minimally and precisely as possible)?
OS
Ansible Control Node (WSL2)
Target Hosts (ARM64)
Version of Python
Python 3.10.6
Version of Kubespray (commit)
91dea02
Network plugin used
calico
Full inventory with variables
Command used to invoke ansible
ansible-playbook -i ./inventory/mycluster/hosts.yaml cluster.yml -K --check -b
Output of ansible run
Anything else we need to know
Additionally, I modified
ansible.cfg
roles_path
provided by the kubespray repo and i have verified that this works as expected.The text was updated successfully, but these errors were encountered: