On Fri, Jan 27, 2017 at 5:38 AM, Adam Stokes <adam.sto...@canonical.com> wrote: > Circling back around to this. Do we have an ETA or any updates on the > progress of interfaces.juju.solutions being folded into jujucharms.com?
Indeed some work we would like to kick off and have scheduled for this Ubuntu 17.04 cycle. Currently we are sprinting on Charm CI Developer Workflow and Review Queue. Once we compete those milestones some ideas we have for interfaces are: - Mirroring content - Show what charms layer is built in - Better usage shown to users - Better readme linking from repositories With work to move this into *.jujucharms.com Current webservice code is at https://github.com/juju-solutions/juju-interface, and if any folks are interested in contributing please feel free to reply here. -thanks, Antonio ie https://github.com/apache/bigtop/tree/master/bigtop-packages/src > > > On Sat, Nov 12, 2016, 11:20 AM Marco Ceppi <marco.ce...@canonical.com> > wrote: >> >> 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 <t...@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" <jamesbe...@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@lists.ubuntu.com >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Antonio Rosales Ecosystem Engineering Canonical -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
