dachad / tcpgoon Goto Github PK

https://github.com/golang-standards/project-layout

I think we can improve how we recover arguments:

• first, we can take advantage of the init function for this, as this example:
  https://stackoverflow.com/a/19762274
• But, as a final goal, I'd replace the flags library by something a bit more "serious":
  https://github.com/ogier/pflag

As, I think a milestone for this project, is to create debian/rpm packages and a docker image, and allow users to use this tool as any other you may have in your OS, and the default flags in golang are not posix compliant plus they dont support "short letters"...

Generating and sharing docker image (it must be part of the build also for future releases) to run the tool may help its usage. Integrating also with whalebrew could be interesting (https://github.com/bfirsh/whalebrew), and may facilitate integration with travis

Christian, I will pick this one (I cannot initiate just right now, but soon)

So the tool can be installed in the most used distros (deb/rpm)

We should be able to deal with executions that get partial success due several reasons (stressed server?) and present propers metrics and report.

In order to facilitate the consumption for services not statially tied to a single DNS (or maybe behind a load balancer we don't want to test), discovering and testing an individual instance from a service discovery would be great. Starting by eureka without auth will unlock its usage in Sch

@chadell , I'll take care if you don't mind

we shall find a better project name and binary name.
tcpMaxConn overlaps with a SNMP MIB object: {1 (iso). 3 (org). 6 (dod). 1 (internet). 2 (mgmt). 1 (mib-2). 6 (tcp). 4 (tcpMaxConn)}

And retries should be configurable:

• it may depend on how we are running the tool (in the mode of "open and keep X connections open", retrying makes sense. In the mode of "try to open up to X connections" it may not have sense)

... so we can provide some expectations in the README about max tcp connections we can test in a single instance

The current version of this program:

• tries to open as many connections as requested
• keeps the connections open unless the other end closes the connections (normally by timeout) or refuses the connections
• and, only when all connections are closed or errored, the program finishes

We should think about a better termination logic. Maybe:

• a flag stating the number of seconds we want to keep each single connection open before forcing a closure in our end
• or, maybe we can just start by: keep the program running until all connections are in the state "closed, errored or established", so there's no connections waiting to be dialed or dialing. When the program finishes, print a final report with some stats, including how long it took to reach this desired state.

In this stage, I'd bet for the second option

Because it's execution could became something like a SYN flood DoS, it would be great to show what's gonna do the program before just doing it.
Something like showing the parameters of the execution.
This behaviour could be avoided by using a -f / --force option when calling it

https://www.codacy.com/

Easy to integrate, and quite useful.. quick win

That is the most external layer with the actual tcpgoon core functionality: we will introduce several scenarios

Simple discovery implementation to define the interface we will extend.

Initial use case: individual gcp instances discovery

Image name as a parameter (from Docker Hub)
discover exposed port
Stress running container

In one hand, we have a tcpconnect function that supports a waitgroup to report how many connections have been processed, so they can be called inside goroutines and allow the caller to know when everything finished. Now we just decrease the waitgroup when a connection becomes closed. On the other hand, we have an external closure routine that monitors the status of connections and, with the current logic, once everything has progressed to established or errored, closes the program. I never liked this external monitor; this means delay and continuous polling...

The point is then... should we consolidate this in a single approach? Probably making the wg logic smarter, and consider a configurable "termination" policy, would be great.

This issue can be integrated with the new execution modes just as a consideration when implementing configurable termination policies.

Some sections of the README (help, examples...) require update everytime we do map new functionality to the cmd flags... maybe we can create a test that, given a README.src skeleton appends the output of running the latest version of tcpgoon automatically in the right sections (markers may be needed) to generate the final README.md

Collecting the time it required an specific connection to dial (so until it becomes effectively established) its a nice metric, we could collect per metric (and incorporate this to the struct representing each connection status?), output it when debug is enabled, but in the normal one, just provide some summaries in the final report (as ping does), with avg/mean/dev...

When running tcpgoon in a container, the user confirmation is not properly processed:

****************************** WARNING ******************************
* You are going to run a TCP stress check with these arguments:
*	- Host: www.google.com
*	- TCP Port: 80
*	- # of concurrent connections: 5
*********************************************************************
Do you want to continue? (y/N): Response not processed```

As codacy is not progressing with bringing complete golang support (so its not monitoring and reporting code coverage for us, but out travis job), it'd be nice to consider the addition of coveralls (or maybe another?), that could run in parallel and also brings github integration (free for opensource projects). See http://docs.coveralls.io/go

• Add testing to all methods

Provide "live stats" of the number of threads and the status of each connection (using channels? being refreshed every second [configurable]) rather than each thread informing its status (thats just for debug - too close to the implementation)

Migrate to latest golang version 1.14

We can add a version field, aligned with the build date / commit-id, quite easily. See:
https://stackoverflow.com/a/11355611

Or just extra behavior that can be configured just with extra flags?

• current mode with extra options in regards to connections closure-policy?
• open up to X concurrent connections (keeping the old ones), but in less than X seconds (and retrying failed ones)
• "open X connections per second" (keeping previous?) until one fails, so find the actual limit

We should start by creating a proposal of new "options/commands", comparing against just extending what we have, and see which ones looks cleaner/easier to understand..

End to end test

Improvement observed just working with the code. I take care ;)

It'd be nice to cover:

• continuous unit testing
• end to end tests against a tcp server (skeleton included), checking different conditions, and probably wrapping this with docker would be easier to maintain

Using travis would be nice!!