They're definitely not expected to be that slow. Can you run juju --debug status
and put the output in pastebin.ubuntu.com and send us the link? That will turn on verbose logging and will give us a better idea of what's going on. On Aug 30, 2013 3:31 AM, "Peter Waller" <[email protected]> wrote: > Hi Marco, > > My local machine is running 1.13.2-precise-amd64 and the bootstrap node > 1.13.2-raring-amd64. I've only ever used versions greater than 1.11 and > seen this kind of latency (half a minute or more). > > Thanks, > > - Peter > > > On 30 August 2013 00:22, Marco Ceppi <[email protected]> wrote: > >> Hi Peter (and ScraperWiki team!), >> >> Thanks for contact the list! I'm curious what version of juju do you all >> currently use at ScraperWiki? In version of juju < 1.0 we were creating SSH >> tunnels to the bootstrap node to create a socket for which to securely >> communicate with Zookeeper, which was what we used as our state server. >> Since 1.0 we've replaced Zookeeper with SSL secured Mongodb (and an API >> server), which means connections to the bootstrap node for querying unit >> information and performing actions has increased in speed quite a bit. So >> if you're using, say, juju 0.7 you'll still be creating this tedious SSH >> tunnels which create overhead in each juju command. If you're using, say, >> juju 1.12 then you shouldn't see much latency at all. >> >> As for garbage collection, I think this is still an issue with both our >> last 0.X release (0.7) and our latest 1.X release (1.13.2). I know that the >> 1.0 series of juju release are getting better at allowing you to clean up >> services that no longer exist in the topology but it's not quite there yet. >> >> Thanks, >> >> Marco Ceppi >> Canonical, Ltd. >> >> >> On Thu, Aug 29, 2013 at 6:57 AM, Peter Waller <[email protected]>wrote: >> >>> Hi All, >>> >>> I've just joined ScraperWiki where juju is used to manage our AWS >>> deployments. >>> >>> I don't have any prior juju experience. Is it expected that "juju >>> status" and "juju ssh" take more than 30 seconds to do anything? Everyone >>> in my organization is experiencing this. It is making it a frustrating tool >>> to use at times. >>> >>> If this isn't normal, are there any obvious culprits I can check to >>> diagnose the origin of this delay? >>> >>> Thanks in advance, >>> >>> - Peter >>> >>> p.s. To give some information about our setup: >>> >>> $ juju status | grep agent-state: | sort | uniq -c | sort -n >>> 1 agent-state: pending >>> 1 agent-state: pending >>> 7 agent-state: down >>> 9 agent-state: started >>> 10 agent-state: started >>> >>> We have quite some machines we're never going to use again, is there a >>> way to garbage collect this list? >>> >>> -- >>> 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 > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
