JuJu made deploying of machines in easy way..BUT!!! once somthing goes wrong with the bootstrap node, it will be quit difficult to handle for some reasons!!! I got this problem when I was reading about juju and first node as bootrap one and zookeeper basically will run on this node to orchestrate the others. I just shutdown my bootstrap node, and destroy the juju env. Once again, boot the machine and followed by juju bootraping. JuJu status in verbose mode shows something like that:
> ,665:1874(0x7f61904e1700):ZOO_INFO@zookeeper_init@727: Initiating > client connection, host=localhost:50835 sessionTimeout=30000 > watcher=0x7f618ffca700 sessionId=0 sessionPasswd=<null> > context=0x3259710 flags=0 > ,667:1874(0x7f6187fff700):ZOO_INFO@check_events@1585: initiated connection to server [127.0.0.1:50835] > ,672:1874(0x7f6187fff700):ZOO_INFO@check_events@1632: session > establishment complete on server [127.0.0.1:50835], > sessionId=0x13d45787f1d0002, negotiated timeout=30000 ,678 DEBUG > Environment is initialized. ,679 INFO Connected to environment. > ,929 ERROR Machine provider information missing: machine 1 > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line > 1045, in _inlineCallbacks > result = g.send(result) > File "/usr/lib/python2.7/dist-packages/juju/state/utils.py", line 257, in _get_node_value > returnValue(node_data.get(key, default)) > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line > 1022, in returnValue > raise _DefGen_Return(val) > _DefGen_Return ,975:1874(0x7f61904e1700)**:**ZOO_INFO@zookeeper_close@2302: Closing zookeeper** sessionId=0x13d45787f1d0002 to [127.0.0.1:50835]** machines: 0: **agent-state: not-started** dns-name: MaaS03 instance-id: /MAAS/api/1.0/nodes/node-3afe0928-859f-11e2-b241-0050561dd02a/ instance-state: unknown
Seems as zookeeper is not accepting session on the bootstraped node. This kind of problems could affect all the env.!!! is there any clue for thuis important point?