web-dev-qa-db-fra.com

L'environnement JUJU et ERROR n'a pas de clé d'accès ni de clé secrète

suivant le guide officiel:

et considéré que j'ai généré la clé ssh (ajoutée à l'interface utilisateur de MAAS) et la clé d'API, le fichier environment.yaml présente les informations suivantes:

environments:
  maas:
    type: maas
    maas-server: 'http://x.x.x.x/MAAS/'
    maas-oauth: 'NDPA86PsEzS7bFynSy:vqJLkyHUJbvYzbtY5Q:sXXXXXXXXXXXXXXXXXXXXXX
    admin-secret: 'nothing'
    default-series: precise
    authorized-keys-path: ~/.ssh/id_rsa.pub # or any file you want.

quand j'essaye de lancer la commande:

juju bootstrap

recevez l'erreur suivante:

ERROR environment has no access-key or secret-key

Quelqu'un peut m'expliquer où est le mal?

  • MAAS et JUJU sont installés à l'aide de leur ppa stable sur un serveur Ubuntu 12.04.3
  • J'ai déjà inscrit 2 machines sur ma mère et elles sont en statut de mise en service
  • Dans le fichier environment.yaml, la ligne "default" a pour valeur "maas"
jujumaas
3
Riccardo Magrini

Lorsque les nœuds dans MaaS sont à l'état de mise en service, ils ne sont pas disponibles pour l'utilisation de Juju. Lorsque les nœuds sont prêts pour l’affectation, ils apparaissent dans MaaS sous l’état Ready.

Lorsque vous bootstrap à l'aide de Juju, il crée un nœud qui mettra en file d'attente les commandes de déploiement et de paramétrage de relation à exécuter à la bonne heure lors de l'installation des différents services.

L'erreur gomaasapi: got error back from server: 409 CONFLICT est une erreur générique signifiant que Maas a rencontré une erreur en tentant de répondre à votre demande. Dans votre cas, étant donné que toutes vos machines sont dans un état de mise en service et non dans un état prêt, MaaS ne dispose d'aucun nœud que Juju puisse utiliser pour configurer la machine bootstrap. A cause de cela, vous obtenez l'erreur 409 CONFLICT.

Lorsque les nœuds sont dans l'état commissioning, ils doivent être démarrés, en exécutant une image du serveur MaaS qui les prépare à l'utilisation. Vous voudrez peut-être vérifier que les noeuds censés être en train de démarrer sont démarrés et non bloqués lors d'une invite de démarrage ou désactivés. S'ils fonctionnent, essayez de leur connecter un moniteur et voyez ce que vous pouvez voir.

S'ils ne fonctionnent pas, vérifiez si le paramètre d'alimentation défini dans MaaS est correct. MaaS peut ne pas être en mesure de signaler le démarrage des machines (à l'aide d'IPMI, WOL, etc.). Par conséquent, l'image de mise en service n'est jamais démarrée et exécutée. et les nœuds sont bloqués dans l'état de mise en service sans intervention humaine. (Si tel est le cas, vous pouvez le contourner manuellement (comme si physiquement, les machines sont physiques ou en indiquant à VirtualBox de démarrer le VM si vous l'utilisez)). qui sont bloqués dans l'état de mise en service.)

Si vous utilisez des machines virtuelles pour tester MaaS, faites-le moi savoir et je mettrai à jour ma réponse. Il y a quelques problèmes avec le fait de tester MaaS avec des machines virtuelles.

3
Azendale

D'après l'erreur spécifiée, je suppose que vous utilisez juju-core et essayez d'utiliser le fournisseur EC2 d'une manière ou d'une autre. Êtes-vous sûr de ne pas avoir d’autres environnements dans vos environnements.yaml? Vous devez spécifier default: maas au plus haut niveau de vos environnements.yaml, ou bien utiliser juju switch maas sur la ligne de commande. Il sera utile de poster votre fichier environment.yaml complet, ainsi que davantage de contexte à partir du résultat de la commande (quelle commande avez-vous exécutée?), En passant --show-log en tant qu'argument.

1
dimitern

J'ai pu le faire fonctionner en exécutant la commande juju switch local.

1
koxlient

Richard, si vous essayez toujours de tester MAAS dans un environnement virtuel, je pourrai peut-être vous aider. J'ai réussi à exécuter MAAS sur une machine virtuelle en interaction avec deux autres grands VM serveurs dotés de leurs propres machines virtuelles. Dans mon environnement, le serveur MAAS contrôle et démarre les ordinateurs virtuels sur mes VM serveurs. J'ai pu déployer avec succès Wordpress et un certain nombre d'autres petites applications sur mes serveurs VM (Virt-Manager, QEMU et KVM.). L’un des conseils essentiels consiste à utiliser le MAAS 13.10; le code est très stable et il existe un certain nombre de corrections importantes et de fonctionnalités supérieures à 12.04 LTS. J'ai constaté que l'utilisation de "default: maas" au début de mes environnements.yaml entraînait son échec. Je vous conseillerais donc d'utiliser le commutateur -e avec votre commande bootstrap si vous effectuez un déploiement sur un nuage. (par exemple Azure, AWS, HP Cloud).

Vous devrez modifier /etc/maas/pserv.yaml pour que le démarrage PXE fonctionne. Dans la section sur TFTP, décommentez la ligne désignant la "racine", la ligne désignant le "port" et la ligne définissant le générateur.

Le "Fast Installer" ne fonctionnait pas avec mes VM Serveurs. Par conséquent, si vous êtes virtualisé, vous risquez peut-être de laisser passer cette fonctionnalité dans un premier temps.

Les "Charms" ont leurs propres définitions intégrées ("contraintes") sur les CPU et la mémoire requise pour les exécuter. Cela n’est pas précisé dans la documentation, mais j’ai constaté que l’erreur générique 409 CONFLICT tentait de déployer Wordpress et mysql sur tout élément disposant de moins de 2 048 Mo de RAM. mes machines virtuelles. C'est peut-être différent pour vous, c'est ce que j'ai trouvé.

1
user240860

Il demande les informations d'identification des serveurs de cloud. Si vous aimez tester dans votre utilisation locale la commande suivante

Sudo apt-get install juju-local
0
Olcay Tarazan