On 1 December 2016 at 19:53, Marco Ceppi <marco.ce...@canonical.com> wrote:
> 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. >> > > I'm happy to work though changes to the Ubuntu charm to decrease "bloat". > > >> 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. >> > > But it is to support the reactive framework, where we utilize newer Juju > features, like status and application-version to make the charm rich > despite it's minimal goal set. Honestly, a handful of cached wheelhouses > and some apt packages don't strike me as bloat, but I do want to make sure > the Ubuntu charm works for those using it. So, > > What's the real problem with the Ubuntu charm today? > How does it not achieve it's goal of providing a relatively blank Ubuntu > machine? What are people using the Ubuntu charm for? > > Other than demos, hacks/workarounds, and testing I'm not clear on the > purpose of an Ubuntu charm in a model serves. > The cs:ubuntu charm gets used on production to attach subordinates too. For example, we install cs:ubuntu onto our controller nodes so we can install subordinates like cs:ntp, cs:nrpe, cs:~telegraf-chamers/telegraf and others. Its also used in test suites for these sort of subordinates. The 'problem' is, like all reactive charms, the first thing it does is pull down approximately 160MB of packages and installs them (installing pip pulls in build-essentials, or at least a big chunk of it). Its very noticeable when working locally, and maybe in CI environments. If I knew how to solve this for all reactive charms, I would have suggested it already. It could be fixed in cs:ubuntu by making it non-reactive, if people think it is worth it (its not like it actually needs any reactive features. A minimal metadata.yaml and an install or start hook to set the status is all it needs). Maybe reactive is entrenched enough as the new world order that we can get specific cloud images spun for it, where a pile of packages are preinstalled so we don't need to wait for cloud-init or the charm to install them. We might be able to lower deployment times from minutes to seconds, since often this step is the main time sink. -- Stuart Bishop <stuart.bis...@canonical.com>
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
