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. > 2) Add support for images, so when you deploy some vanilla charm there's > an associated "pre-built" image that will be very fast. I guess this is in > the juju road map anyways. > Sure, a build step is an interesting one, but it still incurs the same wait for a setup, you just don't feel it as much. > We always need to keep in mind that this experience will be compared with > things like Kubernetes and Docker, and speed-y deployments really unlock > velocity when iterating on charm development (think for instance running > integration tests). > Speed is just one facet of the experience, though an important one. For the speed of Kubernetes we win, hands down: 10 mins to deploy a full k8s cluster (with Juju) is only really outpaced by SAAS. I know that's not the point you were making, but it's the true speed comparison of what we're doing. That being said, we're very keen on making charm development, and deployment, faster. Reactive 1.0 was a first leap in that direction, as we round off work in 2.0 and leveraging other technologies like unconfined snaps, we can start to speed up the bootstrap process of reactive charms. I'll file bugs to track these items Marco
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
