opendns / lemming Goto Github PK

Currently most of this is handled using optparse, we should support config management of various options using config files. *.ini files are one way to do it, using ConfigParser.

Having more than one test in a testvector file is currently unsupported.

Go coroutines are awesome and we can use them stress test mysql.

We should check to see if the UID=0 before starting the application. If not we should exit with -1 and display help message.

optparse is deprecated, replace it with argparse.

Provide a readme for mysql-collector and examples on how to get it working with Graphite.

Currently upon a misconfigured test bench with an option either missing or ill-defined, the testbench throws the following error:

➜  lomax git:(master) ✗ ./lomax --vector=openstack-generic-test-select.json --config=openstack-generic-config.json
panic: interface conversion: interface is nil, not int

goroutine 1 [running]:
runtime.panic(0x6011a0, 0xc21004f5c0)
        /usr/lib/go/src/pkg/runtime/panic.c:266 +0xb6
main.initPtrs()
        /home/simar/syseng/gocode/src/github.com/opendns/lemming/lomax/lomax.go:75 +0x2ad
main.main()
        /home/simar/syseng/gocode/src/github.com/opendns/lemming/lomax/lomax.go:298 +0x35

This isn't very informative and the user wouldn't really know what went wrong. We need to give better error messages.

We want to be able to query various MySQL parameters while running out tests. This task handles the ability to export these to the end user.

If we add support for configuration files we can easily run applications once checked out from github on different infrastructures and test environments. This file would hold things such as:

1, username
2. password
3. default database host
4. default database port
5. default database
6. alternate database hosts (or a list of read/write hosts)

Example / HowTo would be useful.

We can re-use a lot of common mysql code between different forks/flavors of mysql by refactoring this out to a separate library.

Add required packages, deps and other things one might need to build/test lomax

Current output doesn't look to great when printed out on the screen. Pretty print this out.

Useful libraries:

https://github.com/olekukonko/tablewriter
https://golang.org/pkg/text/tabwriter/#example_Writer_Init

• Human readable output (seconds per op, count)
• Level coded for any failures (use @ehbar 's logging library)

We need to proper timekeeping is done for our benchmarking tests. Need to look into a core go library or a third party library that does this for us.

It'd be nice to run tests without coming up with actual data to input. This input data can come from randomized sources from within lomax.go with the help of libraries that can generate suitable data for us to use.

The framework will parse the test script inputs and if it sees a --random flag being passed in, it'll use randomized data than otherwise.

Lomax is modeled to describe a real world scenario testing and benchmarking framework. It would be nice to add test cases that model real scenarios.

In this case, our tests will model the test_db employee database.

• Employee Layoff Scenario
• Employee Pay cut Scenario
• Company hires new employees
• Company expands and adds new departments and employees

Please feel free to suggest any other scenarios you may think appropriate, happy to accept a PR!

We need to support both possible combinations that are possible for a JOIN statement by adding both x,y and y,x to the list of possible switch cases the code branches that are possible. Currently only one out of the two is handled.

We can refactor some of the switch cases in the JOIN switch block.

Refactor the giant main() func to split it up according to functionality.

It'd be nice to generate test plans to run them using lomax. We can write these test cases in a standard markdown format (json?) and then let lomax parse them and run the tests accordingly.

Dump data as JSON (or any other useful format) and the visualize this data (using graphana, etc)

• JSON
• CSV
• Visualize?