On Tue, 16 Feb 2016 at 18:40 Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote:
> Thanks, Adam. > > Playing devil's advocate to my own question here: why isn't this 1 charm > broken up into separate charms that handle the different bits of the > workflow? It sounds like you'd want to break this up into different charms > along lines of modeled responsibility and then deploy using bundles? > Well we do have a few bundles too, but these are different services inside the one charm. There are several advantages to using this approach 1) we can fail over services without user intervention 2) when the architecture of services inside Landscape changes, there is no user intervention required (i.e. one upgrade-charm hook to write, config files take over from there). 3) we encapsulate the details of Landscape inside the charm, maintained by us and don't expose implementation details to Juju users 4) when the user "juju add-unit"s (or remove-unit's) we can scale the services that we know should be scaled, maintaining affinity and anti-affinity rules that are properties of the software we maintain. 5) avoid some complex interdependencies when relation-changed hooks fire ... I could probably come up with some more, but that should be enough for you to chew over :) > Sorry if I'm over-simplifying. > Nah it's fine :)
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
