trying to separate internal an external concerns in pilosa.Server - it should
handle Cluster, Holder, etc. while pilosa/server handles things with external
deps - e.g. Logger, Stats, Handler, etc. Using functional options in
pilosa.Server now.
and it moves the file handling (open/close) out of the main Command and
into the interface implementation. The Logger implementations both have
a `Logger()` method which returns their internal logger (`*log.Logger`).
This is because the gossip setup (memberlist) needs a `*log.Logger` for
its configuration.
Renames `config` to `generate-config` and implements a new `config`
command that generates the configuration file based on the current
state instead of printing a static string.
A configurable limit has been added to restrict the number of
mutating calls in a `pql.Query`. This is to prevents requests from
timing out from large queries.
The default is set to 5000 writes per request and is configurable
through the configuration file and the command line flags.
It is nested under "cluster" in the config, and it controls cluster membership
as well as broadcasting, so I think type is more appropriate. Also, brevity.
Primary message interface is the MessageBroker which is an attribute of the Messenger.
MessageBroker implementations:
- Gossip (memberlist)
- Broadcast (uses HTTP, received by existing Handler)
- Static (no-ops)
Changes CacheSize from `int` to `uint32` for consistency with protobuf.
Removes unnecessary dependencies in glide:
- `github.com/aws/aws-sdk-go`
- `golang.org/x/net` (although this gets included by memberlist)
TODO:
- [ ] Add tests around the Messenger and MessageBroker objects.
- [ ] Refactor CreateSliceMessage to work with views.
- [ ] Support propogation of meta data on PATCH calls.
fixing some issues from last rebase
had to work around a bunch of viper nonsense with handling string slices
changed the validator.Check to use reflect.DeepEqual
fixed a bug where env vars need to be reset between tests
had to change the structure of pilosa.config to enable the passing of hosts as a
slice of strings (it was a slice of structs which each just contained the string
host.) so we lose some generality, but we weren't using it anyway.
1. fixed a couple bugs with config file reading.
2. made cmd.Serve a global variable so tests could inspect it.
3. added table style testing for pilosa server
4. added the ability to stop server programmatically which also causes the cobra
command running it to return.
Now that the default data dir is defined by the flag, we don't need to set it
explicitly if it isn't set. We also stop reading the config file explicitly in
server.go since viper will read it - we do need to define all the config options
though before the config file will work properly.
2 changes unrelated to cascading config:
1. using cobra.Command.RunE instead of just Run - similar behavior to log + exit,
but simpler. Also prints error message, then usage, then error again which is
nice.
2. getting serveCmd.Flags() once, and re-using it. More readable methinks.
For cascading config, I'm trying to set things up so that we can define the
flags once, and have them work from a config file, environment variable, or
command line. I also don't want references to viper scattered throughout our
code, so I want to set the config at startup, and not touch it from then on.
The idea here is to iterate through the set up command line flags, and then set
their values from viper which knows about the commmand line, the environment,
and the config file, and will pick the right one. The command line flags were
set pointing to the correct config values in the pilosa object, so the right
values will be set automatically.
