Removing the single point of failure
James Beedy
jamesbeedy at gmail.com
Sat Nov 12 15:39:37 UTC 2016
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 :-)
More information about the Juju
mailing list