Sprint: InterPlanetary Test Lab

[flyingzumwalt]

Objectives

• Be able to script and control a large cluster of IPFS nodes
• Be able to plug hardware in and out seamlessly
• Be able to define workloads based (short and long) to run
• Be able to issue independent test suite jobs to the network
• Be able to configure a sub-network, with resource limitations (link bandwidth, link latency, machine platform, memory, storage, etc).
• Be able to define metrics to collect and report
• Get generated reports with test results, and metrics (graphs!!)
• Define some DSL or language to use for running the tests

Team for this Sprint

• @victorbjelkholm
• @jbenet
• @lgierth ?
• @whyrusleeping (PM ?)
• ????

Dependencies

• Figure out metrics to track

Relevant

ipfs/notes#211
ipfs/notes#202

[flyingzumwalt]

@SidHarder on the All Hands you offered to put in some work helping on sprints. Maybe you could help us prep for this one (starts next Monday), since it will be more loosely coordinated than our other sprints -- meaning that there will be a need for someone to keep grooming the waffle board, coordinating work, etc.

[SidHarder]

@flyingzumwalt I will start thinking about what needs to be done here. When I have questions is OK to ask you?

[flyingzumwalt]

@SidHarder yes you can ask me. I know @jbenet and @whyrusleeping have thoughts on what we should build during that sprint. @lgierth @Kubuxu and others might have opinions too.

[whyrusleeping]

Worth reading over: ipfs/notes#191

I had detailed a bit of my ideas for an 'interplanetary test lab'. I would appreciate feedback on that before this sprint starts.

[whyrusleeping]

Also, CC @FrankPetrilli, you will definitely be wanted and involved heavily in this sprint. I would love to get a status update from you and your thoughts on what we can accomplish here.

[SidHarder]

@flyingzumwalt Does the following use case for the Interplanetary Test Lab make sense?

1. A developer is working on an amazing new feature..
2. The developer has written tests which prove it performs as expected at a local level.
3. The developer can use the Interplanetary Test Lab to see how the changes will affect the entire IPFS network.
4. The developer would point the test lab to his version of IPFS and then run a set of standard tests which would run on 100's or even 1,000's of nodes.
5. Upon completion of the tests the developer would receive a report comparing the new code against the current network
6. The developer could see that his code is slowing things down by 10% as an example.
7. The developer is ready for his awesome new feature to be committed and made ready but as part of the code review the community sees the 10% reduction in speed and won't sign off.

[whyrusleeping]

@SidHarder Thats a good usecase, and is one of the most important ones in the context of this sprint.

[FrankPetrilli]

@whyrusleeping, Perfect, I think containers are a great fit for this role. Testing new changes against the current network needs some research re: launching a local commit as a k8s "deployment", though everything I've seen indicates it'll work out well.

[whyrusleeping]

@FrankPetrilli good to hear! Could you do a small writeup on the kubernetes work so far so we can get an idea of how it could integrate into the work for our next sprint?

[FrankPetrilli]

Absolutely. I'll get some example use cases documented.

[SidHarder]

I have created a repository to track this sprint here: https://github.com/ipfs/test-lab

[SidHarder]

Let's move all discussion for this sprint to ipfs-inactive/pm-test-lab#1. Thanks.

[ghost]

Thanks Sid!

Prep call logistics: ipfs-inactive/pm-test-lab#3

[SidHarder]

HackMD for 2/28/2017 meeting: https://hackmd.io/KwBgjGBsCcCG0FoCm8BMCAsAOD6BGAxgMxgKwbTTADsIAJtdakUA

[brainstorm]

Not sure if it is of interest for anyone here but I coincidentally just instantiated ipfs-cluster+ipfs-go+cgtd, our cancer genomics sharing app on Amazon ECS by using a simple docker-compose.yml, instead of Kubernetes.

Thanks @hsanjuan for dockerizing ipfs-cluster and @rcurrie for cgtd ;)