Avoir une configuration multi-node MAAS-JUJU-Openstack, c'est-à-dire que le contrôleur nova-cloud, le compute nova et la passerelle quantum/neutron sont sur des hôtes séparés. Dans cette configuration, MAAS et Openstack partagent 10.0.0.0/24 comme réseau de gestion, tandis que le charme de Quantum est connecté via eth0 au réseau public 10.0.10.0. Je suis capable de créer des instances et d'attribuer des adresses IP flottantes à celles-ci. Je peux également faire des pings depuis et vers le réseau public. De plus, les 2 instances de cirros, qui sont sur le même sous-réseau, peuvent se connecter en ssh l'une à l'autre. Cependant, je ne suis pas capable de me connecter en ssh aux instances soit à travers l'espace de noms du routeur, c'est-à-dire ip netns exec qr-xxxx ssh -i cirros@adresseipprivée, ou depuis l'extérieur. J'ai généré des paires de clés à la fois via le tableau de bord et nova, avec des résultats similaires. J'ai également essayé chmod 0600 clé, ssh-add clé sans succès. Un exemple de sortie est montré ici http://pastebin.ubuntu.com/7676660/, qui finit par expirer. En se connectant via vnc à l'image cirros, on peut voir, sous /var/log messages, ce qui suit :
Jun20 14:29:21 cir3 authpriv.info dropbear[364]: Connexion enfant depuis GatewayPrivateIp:32818
Jun20 14:29:21 cir3 authpriv.info dropbear[364]: Sortie avant l'authentification : Délai d'attente avant l'authentificationDes journaux similaires sont observés lors de la connexion en ssh depuis le réseau public. En cas d'accès au réseau public, Wireshark montre une répétition de retransmissions de ACK ssh de la source vers l'adresse publique de la VM, avec des appels ARP demandant qui possède soit la source soit l'adresse IP de la VM, et finalement, la VM envoie [FIN, ACK] et ferme la connexion.
J'ai configuré le serveur de métadonnées et suivi la 2ème méthode mentionnée dans Les instances cloud dans OpenStack ne peuvent pas importer la clé SSH publique, et je vois ce qui suit lors du démarrage, http://pastebin.ubuntu.com/7676789/. (Pas sûr que cela soit significatif : échec de la récupération de http://`169.254.169.254`/2009-04-04/user-data avertissement : aucune métadonnée EC2 pour les données utilisateur) Pour isoler les tests, j'ai créé un nouveau groupe de sécurité qui autorise toutes les plages tcp dans les deux sens d'entrée et de sortie. Il me semble que ce n'est pas un problème de pare-feu ou de politique car la connexion au port 22 est possible, je me demande si les mauvaises métadonnées sont générées lors du démarrage. Toutes suggestions sont les bienvenues. Cordialement,
