Asks/Requirements/Suggestions for Q4 OKRs from the JS Core Dev Team

[daviddias]

Hi Infrastructure Team! I know you already landed your OKRs on the 2018 Q4 IPFS OKR Spreadsheet (great work on landing them 👏🏽👏🏽👏🏽👏🏽) and so my apologies for coming late to this party but here are a couple of KRs that JS Core Dev Team would appreciate to be considered for the success of js-ipfs and js-libp2p.

The summary is that we want to expose js-ipfs to the elements and we want to do that by having js-ipfs daemons as part of IPFS Infrastructure. A lot of this is captured in this issue ipfs/js-ipfs#804 but in summary, a candidate OKR would be:

O: js-ipfs is exposed to the elements of the IPFS Network
KR: There at least 3 Gateway nodes that are js-ipfs Daemons
KR: There at least 5 Bootstrapper nodes that are js-ipfs Daemons
KR: It is simple and quick for the JS Core Dev Team to monitor and capture the logs from the js-ipfs Daemons deployed to the IPFS Infrastructure

[eefahy]

After reviewing ipfs/js-ipfs#804 it seems like there are some gremlins in the daemon that make the deployment of this service harder than just spinning up the infra? Does it instead make sense to create a specific js-gateway mini WG including a dev (or two) and a infra eng (or two) charged with designing, debugging, and implementing this gateway? If that's the case I think a more suitable OKR would be:

O: Create a js-ipfs gateway as a service
KR: A js-ipfs gateway is available in at least n regions
KR: Logs and metrics are available for the js-gateway at a webpage

Thoughts?

[daviddias]

Open to discuss the right path and understand better on all the IPFS Infrastructure is set up. Here are two more data points:

• The js-ipfs daemon already packs a usable gateway (do npm install ipfs -g and give it a spin!)
• @victorbjelkholm deployed a js-ipfs Gateway on https://js.ipfs.io/ipfs/anyHash, but at the moment there is no info, logs and crash reports going to the JS Core Dev Team.

[victorb]

@eefahy I think a WG for this would be overkill. It should not be that complicated.

As David mentioned, there was work done on this (See https://github.com/protocol/infra/pull/155) which we stopped once we realized we couldn't run the daemon for longer than 1 minute before having to restart it.

With ipfs/js-ipfs#1406 in place, the daemon should handle errors better, and it's just a matter of deploying the docker images in the regions needed and scraping the metrics/logs. Basically, with 1406 fixed, it should be just spinning up the infra.

[eefahy]

I suggested a WG not due to complexity but for streamlined communication between the js-ipfs team and the infra team. By WG I mean nothing more than identified team members that meet occasionally on design, progress, and direction.

The WG idea also encourages the js-ipfs team to be actively involved in spinning up the gateway and would hopefully result in them feeling empowered to make changes to the infra as needed in the future. I would also love to leverage some of the excellent work @mburns has recently done on the go-ipfs gateway deploy to keep the two in some semblance of consistency. Additionally, @gmasgras has been working on logging and and metrics from docker containers that we should leverage. If in the end, the js-ipfs team would rather the infra team just take the gateway deployment and monitoring on itself, then I would still like to bring in more infra members to weigh in on how to best approach this new service we are responsible for monitoring and maintaining.

We currently have an infra OKR on getting the go-ipfs gateway logs observable with metrics alerting that could be expanded for this gateway. But I'm happy to have an additional OKR for just this js-ipfs gateway work as I described above.

[eefahy]

Closing as we have a js-ipfs gateway as part of our Q4 OKRs