web-dev-qa-db-fra.com

Juju bloqué dans l'état "en attente" lors de l'utilisation de LXC

J'essaie donc de démarrer avec Juju, et j'ai essayé de le faire localement en utilisant LXC.

J'ai suivi les instructions ici: Comment configurer juju pour une utilisation locale?

Malheureusement, cela ne semble pas fonctionner pour moi.

le statut montre ce qui suit:

$ juju status
machines:
  0:
    agent-state: running
    dns-name: localhost
    instance-id: local
    instance-state: running
services:
  mysql:
    charm: cs:precise/mysql-1
    relations:
      db:
      - wordpress
    units:
      mysql/0:
        agent-state: pending
        machine: 0
        public-address: null
  wordpress:
    charm: cs:precise/wordpress-0
    exposed: true
    relations:
      db:
      - mysql
    units:
      wordpress/0:
        agent-state: pending
        machine: 0
        open-ports: []
        public-address: null
2012-05-10 14:09:38,155 INFO 'status' command finished successfully

Comme vous pouvez le constater, l'état de l'agent est "en attente" et il n'existe aucune adresse publique permettant d'accéder au site nouvellement créé. Est-ce que j'ai râté quelque chose?

UPDATE: J'ai essayé de détruire l'environnement et de tout refaire (plusieurs fois). Voici le résultat pour debug-log:

~$ juju debug-log 
2012-05-11 08:50:23,790 INFO Enabling distributed debug log.
2012-05-11 08:50:23,806 INFO Tailing logs - Ctrl-C to stop.
2012-05-11 08:50:42,338 Machine:0: juju.agents.machine DEBUG: Units changed old:set([]) new:set(['mysql/0'])
2012-05-11 08:50:42,339 Machine:0: juju.agents.machine DEBUG: Starting service unit: mysql/0 ...
2012-05-11 08:50:42,459 Machine:0: unit.deploy DEBUG: Downloading charm cs:precise/mysql-1 to /home/andre/.juju/data/andre-local/charms
2012-05-11 08:50:42,620 Machine:0: unit.deploy DEBUG: Using <juju.machine.unit.UnitContainerDeployment object at 0x9c54b6c> for mysql/0 in /home/andre/.juju/data/andre-local
2012-05-11 08:50:42,648 Machine:0: unit.deploy DEBUG: Starting service unit mysql/0...
2012-05-11 08:50:42,649 Machine:0: unit.deploy DEBUG: Creating master container...
2012-05-11 08:54:33,992 Machine:0: unit.deploy DEBUG: Created master container andre-local-0-template
2012-05-11 08:54:33,993 Machine:0: unit.deploy INFO: Creating container mysql-0...
2012-05-11 08:56:18,760 Machine:0: unit.deploy INFO: Container created for mysql/0
2012-05-11 08:56:19,466 Machine:0: unit.deploy DEBUG: Charm extracted into container
2012-05-11 08:56:19,569 Machine:0: unit.deploy DEBUG: Starting container...
2012-05-11 08:56:22,707 Machine:0: unit.deploy INFO: Started container for mysql/0
2012-05-11 08:56:22,707 Machine:0: unit.deploy INFO: Started service unit mysql/0
2012-05-11 08:56:23,012 Machine:0: juju.agents.machine DEBUG: Units changed old:set(['mysql/0']) new:set(['wordpress/0', 'mysql/0'])
2012-05-11 08:56:23,039 Machine:0: juju.agents.machine DEBUG: Starting service unit: wordpress/0 ...
2012-05-11 08:56:23,154 Machine:0: unit.deploy DEBUG: Downloading charm cs:precise/wordpress-0 to /home/andre/.juju/data/andre-local/charms
2012-05-11 08:56:23,396 Machine:0: unit.deploy DEBUG: Using <juju.machine.unit.UnitContainerDeployment object at 0x9c519cc> for wordpress/0 in /home/andre/.juju/data/andre-local
2012-05-11 08:56:23,620 Machine:0: unit.deploy DEBUG: Starting service unit wordpress/0...
2012-05-11 08:56:23,621 Machine:0: unit.deploy INFO: Creating container wordpress-0...
2012-05-11 08:58:24,739 Machine:0: unit.deploy INFO: Container created for wordpress/0
2012-05-11 08:58:25,163 Machine:0: unit.deploy DEBUG: Charm extracted into container
2012-05-11 08:58:25,397 Machine:0: unit.deploy DEBUG: Starting container...
2012-05-11 08:58:27,982 Machine:0: unit.deploy INFO: Started container for wordpress/0
2012-05-11 08:58:27,983 Machine:0: unit.deploy INFO: Started service unit wordpress/0

Voici le résultat de la commande status (avec indicateur détaillé):

~$ juju -v status
2012-05-11 08:51:53,464 DEBUG Initializing juju status runtime
2012-05-11 08:51:53,625:4030(0xb7345b00):Zoo_INFO@log_env@658: Client environment:zookeeper.version=zookeeper C client 3.3.5
2012-05-11 08:51:53,625:4030(0xb7345b00):Zoo_INFO@log_env@662: Client environment:Host.name=andre-ufo
2012-05-11 08:51:53,625:4030(0xb7345b00):Zoo_INFO@log_env@669: Client environment:os.name=Linux
2012-05-11 08:51:53,625:4030(0xb7345b00):Zoo_INFO@log_env@670: Client environment:os.Arch=3.2.0-24-generic-pae
2012-05-11 08:51:53,625:4030(0xb7345b00):Zoo_INFO@log_env@671: Client environment:os.version=#37-Ubuntu SMP Wed Apr 25 10:47:59 UTC 2012
2012-05-11 08:51:53,626:4030(0xb7345b00):Zoo_INFO@log_env@679: Client environment:user.name=andre
2012-05-11 08:51:53,626:4030(0xb7345b00):Zoo_INFO@log_env@687: Client environment:user.home=/home/andre
2012-05-11 08:51:53,626:4030(0xb7345b00):Zoo_INFO@log_env@699: Client environment:user.dir=/home/andre
2012-05-11 08:51:53,626:4030(0xb7345b00):Zoo_INFO@zookeeper_init@727: Initiating client connection, Host=192.168.122.1:41779 sessionTimeout=10000 watcher=0xb7780620 sessionId=0 sessionPasswd=<null> context=0x9242ee8 flags=0
2012-05-11 08:51:53,627:4030(0xb6b90b40):Zoo_INFO@check_events@1585: initiated connection to server [192.168.122.1:41779]
2012-05-11 08:51:53,649:4030(0xb6b90b40):Zoo_INFO@check_events@1632: session establishment complete on server [192.168.122.1:41779], sessionId=0x1373ae057d90007, negotiated timeout=10000
2012-05-11 08:51:53,651 DEBUG Environment is initialized.
machines:
  0:
    agent-state: running
    dns-name: localhost
    instance-id: local
    instance-state: running
services:
  mysql:
    charm: cs:precise/mysql-1
    relations:
      db:
      - wordpress
    units:
      mysql/0:
        agent-state: pending
        machine: 0
        public-address: null
  wordpress:
    charm: cs:precise/wordpress-0
    relations:
      db:
      - mysql
    units:
      wordpress/0:
        agent-state: pending
        machine: 0
        public-address: null
jujucharms
8
Andre

Je rencontrais la même erreur et, avec l'aide des gens de #juju, j'ai pu déterminer que l'activation de mon pare-feu sur l'ordinateur hôte empêchait le gardien de zoo de se reconnecter à l'hôte.

Essayez de courir:

Sudo ufw disable

puis:

Sudo juju destroy-environment

et ensuite les choses en arrière. De plus, s'il s'agit du premier démarrage d'un environnement sur votre ordinateur, notez que le téléchargement du charme initial prend un certain temps; accordez-le 15 à 20 minutes après le déploiement d'une unité.

C'est aussi maintenant un bogue ouvert , car juju devrait gérer cette situation automatiquement.

10
nathwill

Si c'est la première fois que vous démarrez votre environnement local, il faudra plusieurs (en fonction du temps nécessaire pour télécharger environ 400 Mo de données Server Image) pour créer la première image principale. Dans votre chemin "data-dir" (défini dans votre fichier environment.yaml), il y a un machine-agent.log qui décrit ce processus:

2012-05-09 10:04:03,848: juju.agents.machine@INFO: Machine agent started id:0
2012-05-09 10:05:08,175: juju.agents.machine@DEBUG: Units changed old:set([]) new:set(['mysql/0'])
2012-05-09 10:05:08,176: juju.agents.machine@DEBUG: Starting service unit: mysql/0 ...
2012-05-09 10:05:08,222: unit.deploy@DEBUG: Downloading charm cs:precise/mysql-1 to /home/marco/.juju/local/marco-local/charms
2012-05-09 10:05:08,314: unit.deploy@DEBUG: Using <juju.machine.unit.UnitContainerDeployment object at 0x9cccbec> for mysql/0 in /home/marco/.juju/local/marco-local
2012-05-09 10:05:08,375: unit.deploy@DEBUG: Starting service unit mysql/0...
2012-05-09 10:05:08,376: unit.deploy@DEBUG: Creating master container...

Quelques instants plus tard, vous verrez ce qui suit:

2012-05-09 10:09:40,699: unit.deploy@DEBUG: Created master container marco-local-0-template
2012-05-09 10:09:40,699: unit.deploy@INFO: Creating container mysql-0...
2012-05-09 10:10:31,429: unit.deploy@INFO: Container created for mysql/0
2012-05-09 10:10:31,483: unit.deploy@DEBUG: Charm extracted into container

Quelques détails plus tard, quelques minutes plus tard, le conteneur maître a été créé.

Enfin, tous les boostps "locaux" ne fonctionnent pas, essayez de lancer juju destroy-environment puis de réexécuter juju bootstrap.

3
Marco Ceppi

J'ai eu le même problème. J'ai trouvé dans master-customize.log échec d'apt-get en raison de paquets corrompus dans apt-cacher-ng (je ne suis pas sûr que je pense que cela est arrivé parce que mon ordinateur portable a été suspendu pendant le téléchargement). J'ai pu corriger le problème en visitant http://localhost:3142/acng-report.html, en vérifiant:

  • Valider par nom de fichier ET répertoire de fichiers (non recommandé),
  • puis valider le contenu du fichier par la somme de contrôle (SLOW), en détectant également les fichiers corrompus,
  • puis tronquer les fichiers endommagés immédiatement.

et en cliquant sur Lancer l'analyse et/ou l'expiration. Ensuite, j'ai pu détruire l'environnement juju et le redéployer avec succès.

1
Dan Nuffer

Au lieu de désactiver ufw, on peut essayer d'autoriser le réseau de juju (libvirt) avec:

Sudo ufw allow from `ip addr show virbr0|tail -n 1 |cut -d' ' -f 6` to any

Fonctionne dans mon cas sur Ubuntu 12.04

0
suside