web-dev-qa-db-fra.com

Erreur de connexion MAAS et Juju après l'amorçage

Je travaille avec un problème plutôt étrange en utilisant MAAS et Juju où après le démarrage, la machine "0" a été créée avec succès, je ne peux déployer aucun service émettant un simple juju deploy mysql. Pour donner un bref aperçu de l'environnement, j'exécute MAAS sur Ubuntu Server 13.04 avec l'IP 10.0.0.10 et juju et juju-core s'exécutent sur le même serveur. Tout cela est également exécuté dans un laboratoire de test localisé. Émission d'un juju status révèle ce qui suit:

root@maas:~# juju status
2013-04-30 10:24:32,876 INFO Connecting to environment...
2013-04-30 10:24:33,439 INFO Connected to environment.
machines:
  0:
    agent-state: not-started
    dns-name: test4.master
    instance-id: /MAAS/api/1.0/nodes/node-ee044686-b100-11e2-9927-52540089abb8/
    instance-state: unknown
  5:
    instance-id: pending
services:
  mysql:
    charm: cs:precise/mysql-19
    relations: {}
    units:
      mysql/0:
        agent-state: pending
        machine: 5
        public-address: null
2013-04-30 10:24:33,496 INFO 'status' command finished successfully

L'instance reste indéfiniment dans un état pending et un examen du journal de débogage révèle qu'aucune connexion n'est établie pour provisionner l'instance:

2013-04-30 10:27:26,562: juju.agents.provision@ERROR: Cannot get machine list
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/juju/agents/provision.py", line 175, in process_machines
    provider_machines = yield self.provider.get_machines()
ProviderInteractionError: Unexpected ConnectionRefusedError interacting with provider: Connection was refused by other side: 111: Connection refused.

Maintenant que cette erreur est générée sur la machine "0" toutes les minutes environ, j'ai regardé un tcpdump pour essayer de découvrir ce qui se passait. Après avoir creusé, je suis tombé sur cela au moment exact où l'erreur était enregistrée:

10:27:26.561631 IP 127.0.0.1.33607 > 127.0.0.1.80: Flags [S], seq 1222093882, win 32792, options [mss 16396,sackOK,TS val 454628 ecr 0,nop,wscale 6], length 0
10:27:26.561651 IP 127.0.0.1.80 > 127.0.0.1.33607: Flags [R.], seq 0, ack 1222093883, win 0, length 0

Étant donné que la machine "0" a été déployée avec MAAS via Juju, je ne pense pas qu'elle exécuterait également MAAS. Pour résoudre le problème, j'ai créé un tunnel SSH sur la machine "0" en écoutant sur le port 80 (localhost) le port du serveur MAAS 80, par ex. 80: MAAS-Server-IP: 80. Après ça, juju status modifié pour afficher la nouvelle machine hors de l'état en attente:

  5:
    agent-state: not-started
    dns-name: test5.master
    instance-id: /MAAS/api/1.0/nodes/node-fe882bb2-b100-11e2-ba1c-52540089abb8/
    instance-state: unknown

Tout cela pour dire, quelqu'un peut-il m'aider à comprendre pourquoi la machine déployée "0" tente une connexion au port localhost 80 plutôt qu'au serveur MAAS? Est-ce dû au fait que j'exécute Juju et MAAS sur le même serveur?

serverjujumaas
2
Timothy Lambert

Lorsqu'un environnement est amorcé, vous devez faire attention au nom d'hôte dans le environnements.yaml, car il semble que c'est ce qui est poussé vers les machines suivantes. Dans mon cas, j'avais le serveur réglé sur http://localhost:80/MAAS, provoquant ainsi la machine "0", et toutes les autres machines d'ailleurs, à tenter de se connecter à localhost et non l'IP/nom d'hôte du serveur MAAS. Après avoir détruit mon environnement et l'avoir redémarré avec le serveur http://10.0.0.10:80/MAAS, tout semblait se déployer correctement. C'est tout à fait un oubli de ma part.

3
Timothy Lambert