On 20 January 2016 at 17:46, William Reade <[email protected]> wrote:
> On Wed, Jan 20, 2016 at 8:46 AM, Stuart Bishop <[email protected]> > wrote: >> It happens naturally if you structure your charm to have a single hook >> that does everything that needs to be done, rather than trying to >> craft individual hooks to deal with specific events. > > Independent of everything else, *this* should *excellent* advice for > speeding up your deployments. Have you already been writing charms like > this? I'd love to hear your experiences; and, in particular, if you've > noticed any improvement in deployment speed. The theoretically achievable > speedup is vast, but the hook runner wasn't written with this approach in > mind; we might need to make a couple of small tweaks [0] to get the best out > of the approach. The PostgreSQL charm has now existed in three forms. Traditional, services framework, and now reactive framework. Using the services framework, deployment speed was slower than traditional. You ended up with one very long string of steps, many of which were unnecessary. I felt it easier to maintain and understand, but logs noisier and it was slower. The reactive framework is much faster deployment wise than all other versions, as you can easily have only the necessary steps triggered for the current state. The execution thread is harder to follow, since there isn't really one, but it still seems very maintainable and understandable. There is less code than the other versions. It does drive you to create separate handlers for each hook, but advice is to keep hooks at the absolute bare minimum to adjust the charms state based on the event and put all the actual logic in the state driven handlers. -- Stuart Bishop <[email protected]> -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
