After deploying a charm, either locally or not, juju status lists "Pending". It seems to sit in this state for awhile, longer in my experience in the cloud, a bit shorter locally. What is juju doing during this time?

For local instances it's a couple minutes or less, longer with cloud instances, up to 10 minutes in some cases. I am just curious if deploy's stay pending when the VM is being setup or is something else going on?


What you're seeing looks normal to me.

Juju needs to not only provision the OS, but also install its client, updates, and whatever the charm you're deploying. On top of that it depends on the cloud you're deploying to, and how many resources the instance type has. Up until that happens juju shows Pending.

With the local provider the very first time you do this takes the longest, since it needs to download the ~300mb of Ubuntu server image before it can even begin. After that the bundled apt-cacher-ng bits make deployments after that quicker, so a few minutes for local is normal.

On Amazon Web Services the images are already in their cloud, and they also have certified mirrors in all their regions, which means it can be relatively quick (LAN speed) updates and installation. Some other providers don't have local Ubuntu mirrors, so it really depends on internet speed on that day, so this time can vary widely.

Even with fast mirrors there are other factors. If your charm is doing a bunch of stuff, like say, installing an entire Java stack but you're on a relatively small instance (especially t1.micros) this can take longer than on instances that have higher IO available to Ubuntu.

When doing live demos on AWS I usually get ~5 minute deployment times, enough to fire off some instances, then go back to my presentation.

Here are some things we're doing to make this better:

  • As of Juju .6 we now use cloud images to install instead of a normal ubuntu-server install that has to go through an entire installation and install and configure packages.
  • We work closely with cloud providers to ensure that instance boot time is as fast as it can be.
  • With the go rewrite this means Juju won't need to install the associated Java dependencies on each instance, which might lead to faster boot times and less memory consumption for instances. (I haven't tested this personally)
  • Encouraging charm authors to mention long downloads/installs in their Charm's README when appropriate.

Usually getting the instance up and running is relatively quick, you can find out exactly what's going by sshing into the image as soon as you can and checking out the juju log files, you can just tail them and find the culprit; in my experience it's been waiting for things to download and install via apt.

  • Thanks, that's exactly what I wanted to know. Also, I assume that juju caches the images locally? My local deployments seem to be fairly quick (couldn't tell you how long the first one took) – mfisch Nov 25 '12 at 23:49
  • and how can I see progress of these image downloads and other house hold works that running in background ? – user1868 Oct 22 '14 at 10:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.