Removing the single point of failure

[Marco Ceppi]

Hey everyone,

We're aware of the outage and working to bring the service back online.
This is unfortunate, but we're in the process of getting the
interfaces.juju.solutions site, folded into the charm store properly. This
service has done it's job in providing the initial indexing but as we see
today it's become integral to the operation of charm authorship and should
be as robust as the charm store itself.

To address concerns about "what if". Juju, the interfaces site, the charm
layers, are all open source projects. While some items aren't directly
configurable if we ever did enter a period where Canonical wasn't directly
maintaining infrastructure for Juju and Charms the community could uphold
these projects and elect to run them directly. Juju is a key platform to
Canonical just as it is to you all. While outages like this may occur, we
are iterating quickly to make sure projects like the interfaces site are
folded into jujucharms.com and served with the same level SLA and HA as
you've come to expect.

Marco

On Sat, Nov 12, 2016 at 10:44 AM Tom Barber <tom at spicule.co.uk> wrote:

> 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
>
> --
> 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/0b25bdd5/attachment.html>