IPTL Sprint planning meeting: 2/28/2017 6:00 UTC

Attendees:
@sidharder
@lgierth
@jonnycrunch
@FrankPetrelli
@hsanjuan
@jbenet

1. security concerns with respect to allowing users to run tests.
2. Distribute as VM
3. Kuernetes-IPFS, put together by Victor has been extended by Frank
4. Can end up with a small mini kubernetes cluster.
5. Frank has created massively large files and Kubernetes chugged away before memory ran out.
6. Need to establish testing framework before I can push an IPFS app into production. Needs to be battel tested.

link to https://github.com/ipfs/kubernetes-ipfs/ which Frank has been working on. Snapshots from prometheus.

The minicube idea may be a better idea.

the way we hold the snapshots is not decentralized. Pushing them into a standardized format is doable.

Not sure if a minicube is the goal.

Kubernetes containers allow you fine grained configuration.

In Kubernetes hosts are called nodes. Containers are abstracted away from the host.

Need to determine which metrics should be collected. What are Juans thoughts on this?

The metrics can come from the directly from G-IPFS

The meeting starts again at the correct time:
1. Frank has setup a Kubernetes as mentioned earlier.
- host is called archives-k8s.i.ipfs.io
2. Need to get basic orchestration working.
3. Anyone can add tests with minimal work.
4. Can be for smaller networks
5. Would be happy if we can accomplish these small tasks.
6. Would be interesting to experiment with testing.
7. also be able to describe the way we build jobs. Could be tarball added.
8. What can we achieve in the 2 week time frame.
9. Kub master exists, setting up 2 machines in the cloud
10. Useful to have a VM and a guide, people can follow, may be complicated.
11. Hosting the VM somewhere
12. Experimenting? Would be nice
13. Testing setup. How to bundle? Directly by doing some testing.
14. run from the assumption that jobs will be static.
15. How are people feeling: is this acheivable
16. Jonny, Leverage current infrastructure, use IPLD, what metrics to collect. Maybe not a tarball. There is an issue with VM verses Docker container. Can get metrics about bandwidth etc. Creating the model that gets pinned, and replicated to other nodes. Pinbot?
17. IPFS will not work exactly because of a bug.
18. The executable can be bash scripts to bring the exe down.
19. Need to reduce the burden on the user.
20. Lars: may not need to worry to much about the formats of these ideas yet.
21. Juan: Gather metrics, worry about viewing later, may not need to develop DSL now.
22. Guide: setup machine, anther to run testing.
23. Jonny: how is security going to happen?
24. Instead of plugging random machines - Base assumption is that they are isolated. Can focus on security issues with random machines later.
17. Jonny servers will be available. Kub is the right way to do it. Let kub do the heavy lifting. JS-IPFS would require a selinium type of approach.

What are the issues:
1.Setting up the master, minikube, output would be a document with instructions.
2.By the end of the week have a document that details how to setup the orchestrator
3.Lars is planning to work on Jenkins/CI, will take a look at Kubernetes and play around.
4.Jaun to take a stab at the job bundle
5.Get's some docs this week and then we can start testing next week.
6.Hector to right up tests for clustering
7.Sid to right up issues and make assignment with help from others.

Lars: good idea to interface Jenkins?