Removing the single point of failure

[Tom Barber]

I don't really think Mark is going to do one, my point is that for
platforms like this to survive if they depend on central services for
build/running etc, the services shouldn't just be maintained by a single
entity.

HA sure will solve some issues but I also think that distributing ownership
also mitigates risk.

On 12 Nov 2016 16:39, "James Beedy" <jamesbeedy at gmail.com> wrote:

> Here's something thats been troubling me for a while, Canonical are the
> single point of failure with juju. For example, this morning
> interfaces.juju.solutions appears to be offline, thats not the end of the
> world but of course I can't download layers from it.
>
> I entirely second this. Interfaces.juju.solutions needs to have some kind
> of uptime guarantee, and probably need each component deployed in
> HA/federated to ensure the uptime.
>
> Companies/people are building infrastructure around the charm store,
> interfaces.juju.solutions, and juju itself, what happens when 100 entities
> realize that their CI (or any critical infrastructure) has been down for an
> amount of time? For many, this could stunt development and increase budget
> expenditures.
>
>
> Similarly, if Mark for whatever reason decided he couldn't be bothered with
> Juju any more and went and did something else, the users would be without
> resource that is vital to people building stuff.
>
>
> I have to disagree with you here. Mark is an amazing driver for these
> technologies and technology communities, but they exist outside of, and
> disparate of Mark and Canonical. While the world (as well as these
> technologies) would undoubtedly not be same if not for Mark's
> contribution(s), I think the idea here is that the majority of the software
> in Canonical stack has enough wind under it to survive in the wild.
>
> Does mirroring capabilities exist for other people to mirror
> interfaces.juju.solutions and can you tell juju to use another portal? That
> way, much like maven central, those of us with bandwidth could mirror
> resources that are vital for smooth running of Juju operations.
>
> True, mirroring would be huge, but shouldn't be a solution ..... We should
> deploy the site across multiple az/regions if you ask me :-)
>
>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20161112/96e1e400/attachment.html>