On Thu, Dec 1, 2016 at 6:53 AM, 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, > I think a minimal wheelhouse to provide a consistent charm hook runtime is very reasonable and definitely not the problem here. There are too many packages that get installed by default with the reactive framework that most charms don't need. When I deploy the ubuntu charm (but this applies to any charm built with reactive and layer:basic), I also get: 2016-12-01 17:45:47 INFO install The following NEW packages will be installed: 2016-12-01 17:45:47 INFO install binutils build-essential cpp cpp-5 dpkg-dev fakeroot g++ g++-5 gc c gcc-5 2016-12-01 17:45:47 INFO install libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-mer ge-perl 2016-12-01 17:45:47 INFO install libasan2 libatomic1 libc-dev-bin libc6-dev libcc1-0 libcilkrts5 l ibdpkg-perl 2016-12-01 17:45:47 INFO install libexpat1-dev libfakeroot libfile-fcntllock-perl libgcc-5-dev libgomp1 2016-12-01 17:45:47 INFO install libisl15 libitm1 liblsan0 libmpc3 libmpx0 libpython3-dev libpython3.5-dev 2016-12-01 17:45:47 INFO install libquadmath0 libstdc++-5-dev libtsan0 libubsan0 linux-libc-dev make 2016-12-01 17:45:47 INFO install manpages-dev python-pip-whl python3-dev python3-pip python3-setuptools 2016-12-01 17:45:47 INFO install python3-wheel python3.5-dev None of my charms need build-essential or a g++ compiler, that's a lot of unnecessary dependencies! Can we get rid of most of these? Would installing the bare minimum with --no-install-recommends help? > 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. > > Marco > > -- > 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
