I hope that as you implement this, you avoid making fat charms. Can you use "resources" for this?
Aaron On 2016-12-01 08:39 AM, Marco Ceppi wrote: > On Thu, Dec 1, 2016 at 8:28 AM Free Ekanayaka > <[email protected] <mailto:[email protected]>> wrote: > > On 1 December 2016 at 13:53, Marco Ceppi <[email protected] > <mailto:[email protected]>> wrote: > > On Thu, Dec 1, 2016 at 5:00 AM Adam Collard > <[email protected] <mailto:[email protected]>> > wrote: > > On Thu, 1 Dec 2016 at 04:02 Nate Finch > <[email protected] <mailto:[email protected]>> > 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 > >
signature.asc
Description: OpenPGP digital signature
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
