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:53Z workload waiting waiting for machine 15 Dec 2016 00:18:53Z juju-unit allocating 15 Dec 2016 00:20:13Z workload waiting installing agent 15 Dec 2016 00:20:13Z workload waiting agent initializing 15 Dec 2016 00:20:14Z workload maintenance installing charm software 15 Dec 2016 00:20:14Z juju-unit executing running install hook 15 Dec 2016 00:20:46Z workload active ready 15 Dec 2016 00:20:46Z juju-unit executing running leader-elected hook 15 Dec 2016 00:20:47Z juju-unit executing 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> wrote: > On Thu, 1 Dec 2016 at 04:02 Nate Finch <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 > 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
