On 1 December 2016 at 14:39, Marco Ceppi <marco.ce...@canonical.com> wrote:
> On Thu, Dec 1, 2016 at 8:28 AM Free Ekanayaka < > free.ekanay...@canonical.com> wrote: > >> On 1 December 2016 at 13: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: >> >> >> 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. >> >> >> Yeah, and I think this is a good thing. >> >> >> Honestly, a handful of cached wheelhouses and some apt packages don't >> strike me as bloat >> >> >> No it's not per-se. However I think this highlights a more general issue >> with the current implementation of the reactive stack. It's not only the >> ubuntu charm that has slowed done, it's any reactive-based charm, because >> the steps required to "setup" reactive take longer than they used to. >> > > The problem we're hitting with wheelhouses is exactly the one that snaps > aim to solve: > > - apt packages are not cross distro, and we have reactive centos charms > - apt packages lag a bit meaning we can't get consistent features even > between trusty and xenial, let alone xenial and tip > > I see a couple of (possibly alternative) ways to improve the situation: >> >> 1) Make sure the dependencies of the base reactive layer are packaged, >> that should be much faster than pip install, and fall back to pip only for >> what's not there (i.e. dependencies added by the consumers of the base >> layer). Also, package the base layer itself. >> > > I'm very keen on a development in the snap world, where an unconfined > "classic" style package would be available. This means we could snap up all > the dependencies of the basic layer for every architecture and skip the > setup phase for reactive. I think this is probably our best bet going > forward. > Sounds good.
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
