On 17 February 2016 at 01:20, Katherine Cox-Buday <katherine.cox-bu...@canonical.com> wrote:
> My understanding is that it's a goal to make the management of units more > consistent, and making the units more homogeneous would support this, but > I'm wondering from a workload perspective if this is also true? One example > I could think of to support the discussion is a unit being elected leader > and thus taking a different path through it's workflow than the other units. > When it comes to resources, maybe this means it pulls a different sub-set of > the declared resources, or maybe doesn't pull resources at all (e.g. it's > coordinating the rest of the units or something). While I have charms where units have distinct roles (one master, multiple standbys, and the juju leader making decisions), they can be treated as homogeneous since they need to be able to fail over from one role to another. The only use case I can think of where different resources might be pulled down on different units is deploying a new service with data restored from a backup. The master would be the only unit to pull down this resource (the backup) on deployment, and the standbys would replicate it from the master. And now I think of it, can I stream resources? I don't want to provision a machine with 8TB of storage just so I can restore a 4TB dump. Maybe this is just a terrible example, since I probably couldn't be bothered uploading the 4TB dump in the first place, and would instead setup tunnels and pipes to stream it into a 'juju run' command. An abuse of Juju resources better suited to Juju blob storage? -- Stuart Bishop <stuart.bis...@canonical.com> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
