Ansible: Rapport de bogue: le module ec2 est cassé avec "ERREUR! Le module n'a pas de ligne d'interprétation"

Créé le 14 oct. 2015  ·  3Commentaires  ·  Source: ansible/ansible

Type de probleme:

Bug Report

Version Ansible:

ansible 2.0.0 (devel 2963bba901) last updated 2015/10/14 15:07:35 (GMT +300)
  lib/ansible/modules/core: (devel 95b10c9fdd) last updated 2015/10/14 10:52:54 (GMT +300)
  lib/ansible/modules/extras: (devel 15480e3d04) last updated 2015/10/14 10:52:56 (GMT +300)
  config file = /etc/ansible/ansible.cfg
  configured module search path = None

Configuration Ansible:

Le problème existe même avec la version github de ansible.cfg

Environnement:

MacOSX Yosemite 10.10.5

Résumé:

Dans les développements les plus récents, l'utilisation du module ec2 est interrompue. Essayer d'utiliser même les exemples de base de la page ec2_module produit un message:

 fatal: [localhost]: FAILED! => {"failed": true, "msg": "ERROR! module is missing interpreter line"}

L'erreur se produit avant même que les options du module ne soient analysées.

La fonctionnalité a été interrompue depuis le commit 18e2ee16ef0895831ead312550eb5de44c99524c. Je n'ai pas pu déchiffrer pourquoi ce commit a cassé le module ec2.

Étapes à suivre pour reproduire:

- hosts: localhost
  tasks:
   - ec2:
      key_name: mykey
      instance_type: t2.micro
      image: ami-123456
      wait: yes
      group: webserver
      count: 3
      vpc_subnet_id: subnet-29e63245
      assign_public_ip: yes

Résultats attendus:

Les modules ec2 doivent fonctionner comme avant et permettre la création d'instances.
Résultats actuels:

L'erreur suivante est imprimée et l'exécution du playbook se termine.

fatal: [localhost -> localhost]: FAILED! => {"failed": true, "msg": "ERROR! module is missing interpreter line"}
bug
Source
picture Pallokala

Commentaire le plus utile

Juste une note, vous pouvez obtenir cette erreur si vous manquez le:

#!/usr/bin/python

hashbang en haut de votre fichier de module. Probablement pertinent uniquement pour les personnes qui développent leurs propres modules. Mais ça m'a fait trébucher!

picture toast38coza le 2 févr. 2016
👍4

Tous les 3 commentaires

Impossible de répliquer. Cette erreur indique que le module n'a pas le chemin requis, mais en fait: https://github.com/ansible/ansible-modules-core/blob/devel/cloud/amazon/ec2.py#L1

Cela peut être dû à un problème de chemin et / ou à un problème de configuration. Cela se produit-il avec d'autres modules?

OSX: 10.10.2

TÊTE testée:

PLAY ***************************************************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [ec2 aws_secret_key=***** count=1 aws_access_key=****** group=All key_name=***** region=us-west-1 vpc_subnet_id=subnet-64e9d522 instance_type=t2.micro assign_public_ip=True image=ami-df6a8b9b wait=True] ***
changed: [localhost] => {"changed": true, "instance_ids": ["i-249c1196"], "instances": [{"ami_launch_index": "0", "architecture": "x86_64", "block_device_mapping": {"/dev/sda1": {"delete_on_termination": true, "status": "attached", "volume_id": "vol-c611fe3e"}}, "dns_name": "ec2-54-193-42-241.us-west-1.compute.amazonaws.com", "ebs_optimized": false, "groups": {"sg-f2953597": "All"}, "hypervisor": "xen", "id": "i-249c1196", "image_id": "ami-df6a8b9b", "instance_type": "t2.micro", "kernel": null, "key_name": "*****", "launch_time": "2015-10-20T05:02:16.000Z", "placement": "us-west-1a", "private_dns_name": "ip-172-31-10-161.us-west-1.compute.internal", "private_ip": "172.31.10.161", "public_dns_name": "ec2-54-193-42-241.us-west-1.compute.amazonaws.com", "public_ip": "54.193.42.241", "ramdisk": null, "region": "us-west-1", "root_device_name": "/dev/sda1", "root_device_type": "ebs", "state": "running", "state_code": 16, "tags": {}, "tenancy": "default", "virtualization_type": "hvm"}], "tagged_instances": []}

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0

Commit testé: 18e2ee16ef0895831ead312550eb5de44c99524c

PLAY ***************************************************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [ec2 aws_secret_key=***** count=1 aws_access_key=*****group=All key_name=***** region=us-west-1 vpc_subnet_id=subnet-64e9d522 instance_type=t2.micro assign_public_ip=True image=ami-df6a8b9b wait=True] ***
changed: [localhost] => {"changed": true, "instance_ids": ["i-9d911c2f"], "instances": [{"ami_launch_index": "0", "architecture": "x86_64", "block_device_mapping": {"/dev/sda1": {"delete_on_termination": true, "status": "attached", "volume_id": "vol-7468878c"}}, "dns_name": "ec2-54-193-61-87.us-west-1.compute.amazonaws.com", "ebs_optimized": false, "groups": {"sg-f2953597": "All"}, "hypervisor": "xen", "id": "i-9d911c2f", "image_id": "ami-df6a8b9b", "instance_type": "t2.micro", "kernel": null, "key_name": "*****", "launch_time": "2015-10-20T05:21:45.000Z", "placement": "us-west-1a", "private_dns_name": "ip-172-31-5-245.us-west-1.compute.internal", "private_ip": "172.31.5.245", "public_dns_name": "ec2-54-193-61-87.us-west-1.compute.amazonaws.com", "public_ip": "54.193.61.87", "ramdisk": null, "region": "us-west-1", "root_device_name": "/dev/sda1", "root_device_type": "ebs", "state": "running", "state_code": 16, "tags": {}, "tenancy": "default", "virtualization_type": "hvm"}], "tagged_instances": []}

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0

PLAYBOOK:

- hosts: localhost
  connection: local
  tasks:
   - ec2:
      aws_access_key: '*****'
      aws_secret_key: '*****'
      region: us-west-1
      key_name: *****
      instance_type: t2.micro
      image: ami-df6a8b9b
      wait: yes
      group: All
      count: 1
      vpc_subnet_id: subnet-64e9d522
      assign_public_ip: yes
stajkowski picture stajkowski le 20 oct. 2015

J'ai finalement résolu le bogue. J'avais ec2.ini dans le répertoire 'library' et pour une raison quelconque, ansible le choisissait quand il cherchait ec2 -module. Renommer ec2.ini en ec2_dynamic_inventory.ini et exécuter «export EC2_INI_PATH = library / ec2_dynamic_inventory.ini» a résolu le problème.

Pallokala picture Pallokala le 4 nov. 2015

Juste une note, vous pouvez obtenir cette erreur si vous manquez le:

#!/usr/bin/python

hashbang en haut de votre fichier de module. Probablement pertinent uniquement pour les personnes qui développent leurs propres modules. Mais ça m'a fait trébucher!

toast38coza picture toast38coza le 2 févr. 2016
👍4
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

jiwong picture jiwong  ·  3Commentaires
mverwijs picture mverwijs  ·  3Commentaires
rokka-n picture rokka-n  ·  3Commentaires
adamprato picture adamprato  ·  3Commentaires
yatesr picture yatesr  ·  3Commentaires