Eliminate and/or simplify config

[progrium]

Just a placeholder. I've noticed that a lot of implementation, tests, and issues are related to configuration. If we can come up with a more convention oriented / simpler / optional configuration model, it would have a significant impact on overall simplicity ... reducing code/tests to handle possible states, and improving the user experience.

Config can be broken into several concerns (hopefully not missing any):

• Discovering adapter base endpoints/addresses
• Registering/enabling adapters against different request matchers
• Specifying order of chaining
• Format / specifying config

Here is my take on approaches to solutions in this direction for each (though they all interact):

Discovering alternatives

We can eliminate discovery configuration a number of ways. Particularly in development and same-host adapter scenarios.

Running an adaptor on every host, which is maybe more common than people realize, allows discovery can be done automatically with the Docker API. Although this is a great user experience, it can be too permissive, so configuration somewhere should allow whitelisting (based on a name, not location) when running in production. Inspecting the environment can also be used in scenarios where Docker links are explicitly used instead.

Remote adapters with no local agent will have to require configuration. Although you can use mechanisms to expose locally with generic local agents (links+ambassadors), there will always need to be a way to define adapter locations. However with so many options, I can see this configuration as optional (ie improving out of box / development experience).

Registering / matching

This has added the most complexity. As we've noticed, we also end up duplicating much of current matching/routing in adapters. One very simple alternative is to always send all requests to all enabled adapters. The adapter protocol can specify that the adapter must return 404 or 405 on requests it does not support/implement. Powerstrip not only ignores them in the chain, but can remember this and not send them requests for that path/method again.

This makes adapter implementation easy, you implement methods you want to hook into, and return 404 for all else, which is the default in most frameworks. In terms of operator control, this does put "configuration of what adapters get what requests" in control of adapters and not the operator. However, the common case is adapters know what they need to hook into, otherwise they have to teach the user/operator what to configure, which they may stumble on. This model eliminates user error for adapters, so might be a better place to start than explicit matching. It would also let us gather real use cases for limiting adapters to subsets of requests they expect to get.

Ordering

Very important! However, ordering per matched endpoint is just increasing possible states, and is potentially not that necessary. Instead, ordering globally is simpler and just as effective. We can also assume post-hooks go in reverse order of pre-hooks, so we only have to specify the pre-hook order. But we can even assume generally it doesn't matter, making this configuration optional. When order is important, it can be a simple comma separated list of named adapters. Any adapters registered not in the list can be assumed to go in any order after those listed.

Format

Although YAML is very user friendly, the container experience is not optimized for file based configuration. Runtime config (via exposing config API or using config service) and/or static environment configuration is preferred. If we can get configuration simplified and optional, environment becomes much better of an experience.