Make sure you also run on LXD with a decent delay to the APT archive.

That is what makes my local testing slow.


On 15/12/16 13:34, Marco Ceppi wrote:
So, I wanted to circle back around to this thread. I think a lot of good
feedback has come from this, and we're looking into making the reactive
framework leaner and better for charm authors. However, I ran a few
deploy tests and have the following results:

15 Dec 2016 00:18:53Zworkload waiting    waiting for machine
15 Dec 2016 00:18:53Zjuju-unitallocating
15 Dec 2016 00:20:13Zworkload waiting    installing agent
15 Dec 2016 00:20:13Zworkload waiting    agent initializing
15 Dec 2016 00:20:14Zworkload maintenanceinstalling charm software
15 Dec 2016 00:20:14Zjuju-unitexecuting  running install hook
15 Dec 2016 00:20:46Zworkload active     ready
15 Dec 2016 00:20:46Zjuju-unitexecuting  running leader-elected hook
15 Dec 2016 00:20:47Zjuju-unitexecuting  running start hook

I did this a few more times on Amazon, and the results were almost
identical. We have 80 seconds from machine requested to booted in cloud.
Less than a second for agent to initialize and 32 seconds to go from
install hook running to the workload being ready and active. While I'm
sure we can slim that down 10-15 seconds by not installing
build-essentials the largest time suck is still the cloud bringing up
the instance.

I plan on doing this across all the clouds I have access to, and track
in a spreadsheet. I'll share that sheet out in a bit.

Marco Ceppi

On Thu, Dec 1, 2016 at 5:00 AM Adam Collard <
<>> wrote:

    On Thu, 1 Dec 2016 at 04:02 Nate Finch <
    <>> wrote:

        On IRC, someone was lamenting the fact that the Ubuntu charm
        takes longer to deploy now, because it has been updated to
        exercise more of Juju's features.  My response was - just make a
        minimal charm, it's easy.  And then of course, I had to figure
        out how minimal you can get.  Here it is:

        It's just a directory with a metadata.yaml in it with these

        name: min
        summary: nope
        description: nope
          - xenial

        (obviously you can set the series to whatever you want)
        No other files or directories are needed.

    This is neat, but doesn't detract from the bloat in the ubuntu charm.

    IMHO the bloat in the ubuntu charm isn't from support for Juju
    features, but the switch to reactive plus conflicts in layer-base
    wanting to a) support lots of toolchains to allow layers above it to
    be slimmer and b) be a suitable base for "just deploy me" ubuntu.
    Juju-dev mailing list <>
    Modify settings or unsubscribe at:

Juju-dev mailing list
Modify settings or unsubscribe at:

Reply via email to