A (Very) Minimal Charm

[Aaron Bentley]

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
> <free.ekanayaka at canonical.com <mailto:free.ekanayaka at canonical.com>> wrote:
> 
>     On 1 December 2016 at 13:53, Marco Ceppi <marco.ceppi at canonical.com
>     <mailto:marco.ceppi at canonical.com>> wrote:
> 
>         On Thu, Dec 1, 2016 at 5:00 AM Adam Collard
>         <adam.collard at canonical.com <mailto:adam.collard at canonical.com>>
>         wrote:
> 
>             On Thu, 1 Dec 2016 at 04:02 Nate Finch
>             <nate.finch at canonical.com <mailto:nate.finch at 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
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20161201/414aee4e/attachment.pgp>