Make sure you also run on LXD with a decent delay to the APT archive.
That is what makes my local testing slow. Tim 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. Thanks, Marco Ceppi On Thu, Dec 1, 2016 at 5:00 AM Adam Collard <adam.coll...@canonical.com <mailto:adam.coll...@canonical.com>> wrote: On Thu, 1 Dec 2016 at 04:02 Nate Finch <nate.fi...@canonical.com <mailto:nate.fi...@canonical.com>> 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 contents: name: min summary: nope description: nope series: - 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 Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
