Hi Andrew, I've just tried this again on tip. I tried two separate providers that I'm signed up to. I tried to deploy the mongodb charm. Both seem to fail getting the private address? It happened on the wordpress charm as well so I guess it's juju related?
Deploying mongodb on digital ocean: 2013-09-25 14:27:06 DEBUG juju.agent agent.go:241 Reading agent config, format: format 1.16 2013-09-25 14:27:06 INFO juju.jujud unit.go:73 unit agent unit-mongodb-0 start 2013-09-25 14:27:06 INFO juju runner.go:253 worker: start "api" 2013-09-25 14:27:06 INFO juju apiclient.go:111 state/api: dialing "wss:// ec2-23-20-9-138.compute-1.amazonaws.com:17070/" 2013-09-25 14:27:06 INFO juju apiclient.go:121 state/api: connection established 2013-09-25 14:27:06 INFO juju runner.go:253 worker: start "upgrader" 2013-09-25 14:27:06 INFO juju runner.go:253 worker: start "logger" 2013-09-25 14:27:06 DEBUG juju.worker.logger logger.go:35 initial log config: "<root>=DEBUG" 2013-09-25 14:27:06 INFO juju runner.go:253 worker: start "uniter" 2013-09-25 14:27:06 DEBUG juju.worker.logger logger.go:60 logger setup 2013-09-25 14:27:06 DEBUG juju.worker.logger logger.go:45 reconfiguring logging from "<root>=DEBUG" to "<root>=WARNING" 2013-09-25 14:28:09 ERROR juju.worker.uniter modes.go:41 cannot get unit's private address: cannot get " http://169.254.169.254/2011-01-01/meta-data/local-hostname": Get http://169.254.169.254/2011-01-01/meta-data/local-hostname: dial tcp 169.254.169.254:80: connection timed out 2013-09-25 14:28:09 ERROR juju.worker.uniter.filter filter.go:117 tomb: dying Deploying mongodb in greenqloud: 2013-09-25 14:46:51 INFO juju.jujud unit.go:73 unit agent unit-mongodb-0 start 2013-09-25 14:46:51 INFO juju runner.go:253 worker: start "api" 2013-09-25 14:46:51 INFO juju apiclient.go:111 state/api: dialing "wss:// ec2-23-20-9-138.compute-1.amazonaws.com:17070/" 2013-09-25 14:46:52 INFO juju apiclient.go:121 state/api: connection established 2013-09-25 14:46:52 INFO juju runner.go:253 worker: start "upgrader" 2013-09-25 14:46:52 INFO juju runner.go:253 worker: start "logger" 2013-09-25 14:46:52 DEBUG juju.worker.logger logger.go:35 initial log config: "<root>=DEBUG" 2013-09-25 14:46:52 INFO juju runner.go:253 worker: start "uniter" 2013-09-25 14:46:52 DEBUG juju.worker.logger logger.go:60 logger setup 2013-09-25 14:46:53 DEBUG juju.worker.logger logger.go:45 reconfiguring logging from "<root>=DEBUG" to "<root>=WARNING" 2013-09-25 14:46:58 ERROR juju.worker.uniter modes.go:41 cannot get unit's private address: cannot get " http://169.254.169.254/2011-01-01/meta-data/local-hostname": bad http response 404 Not Found 2013-09-25 14:46:58 ERROR juju.worker.uniter.filter filter.go:117 tomb: dying Thanks Matt On Wed, Sep 18, 2013 at 2:21 AM, Andrew Wilkins < [email protected]> wrote: > On Wed, Sep 18, 2013 at 12:46 AM, Matthew Williams < > [email protected]> wrote: > >> Hi Andy, >> >> When you say >> "Currently you do need to have an existing, bootstrapped environment. >> Work on improving this situation is underway" >> >> What's the idea? >> > > So there's another couple of things in development: a "null" provider, and > "manual bootstrapping". The null provider is a provider that does not > manage or provide any means of automatically provisioning machines. Manual > bootstrapping means essentially the same as manual provisioning, but for > the bootstrap node. In its current manifestation (under review), manual > bootstrap only works with the null provider. You will configure an > environment.yaml that names the bootstrap machine, and "juju bootstrap" > will do something similar to "juju add-machine ssh:..." under the hood. > > I miswrote earlier: you'll always need an existing, bootstrapped > environment. But with the null provider/manual bootstrap, you can put > everything in your VPS, or what have you. You won't need to have a cloud > environment just for the bootstrap node. > > Cheers, > Andrew > > Matt >> >> >> On Mon, Sep 9, 2013 at 2:47 AM, Andrew Wilkins < >> [email protected]> wrote: >> >>> Hello everyone, >>> >>> As was noted in the 1.13.3 release notes thread, we did not announce one >>> the major features that made it into the release (manual provisioning). >>> This was intentional as we have not written any documentation yet. On the >>> other hand, it would be good to get some feedback so that we can make >>> changes if necessary, or feed into the documentation. >>> >>> So, below is a bit of a run-down. If you're interested in this feature, >>> try it out and let us know if you or have any issues or any thoughts for >>> improvement. >>> >>> ---- >>> >>> As of 1.13.3 you can now do this: >>> juju add-machine ssh:[user@]host >>> >>> and a series of commands will be carried out on that host, via SSH, to >>> provision the machine into the current juju environment. This will enable >>> you to compose a juju environment out of your existing systems. >>> >>> Here's a few things to bear in mind: >>> - Currently you do need to have an existing, bootstrapped environment. >>> Work on improving this situation is underway >>> - The machine you're provisioning must be able to route to machine 0 >>> (for the state/API), and storage (to get tools, etc.) >>> - There is no change in supported operating systems; the machine being >>> provisioned must be running Ubuntu 12.04+ >>> - Multiple invocations of ssh will be made, and sudo is used on the >>> remote host to install the machine agent. To reduce noisy prompts, you >>> should use public key authentication. To completely eliminate prompting, >>> you'll also need to enable passwordless sudo on the target host. >>> >>> Cheers, >>> Andrew >>> >>> -- >>> Juju mailing list >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >>> >> >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
