We're also planning to combine the Docker event stream plugin system I prototyped previously into Powerstrip: https://github.com/progrium/docker-plugins
And ultimately, eventually, we'll have native extension support in Docker that allows much more extensibility, but all this is a good first step IMO.
I think it would be interesting, for example, to explore development of an extension that "guided" those tools regarding where (virtually speaking) they should re/deploy machines and containers, based on metrics collected by a 3rd party service with which that extension communicated.
I apologize if my question is a bit naïve; at present, I've been spending a lot of time with the porcelain and haven't gotten into the internals enough to understand how all the Docker pieces truly fit together.
Powerstrip can be used to prototype extending anything which speaks the Docker API. So in theory it could be used in front of swarm, as well as behind it.
I'm also interested in finding a way to prototype extensions to the Docker CLI experience... this is the next logical step, and something we should talk about. :)
Just to be clear, as well, powerstrip is all about finding ways to prototype things. I believe that the way that it gets used can go a long way to figuring out what the best extensions points in Docker itself are.
IMO, the powerstrip project will be a success precisely if we can throw it away in a few months because we've used the results from the powerstrip experiment to build the right extensions mechanism into Docker itself that we can use instead ;)
Cheers, Luke
because powerstrip presents a standard docker HTTP api - it can certainly be used to interact with any other tool that talks standard docker HTTP.
For example - I put together a small run-through in powerstrip-weave where fig can be used to allocate weave IP addresses:
https://github.com/binocarlos/powerstrip-weave/tree/master/e...
Fig speaks to the powerstrip HTTP api which in turn speaks to the weave adapter.
It would definitely be interesting to have some kind of cadvisor adapter (or equivalent) that was automatically feeding back metrics to some kind of scheduler.
The main point is to allow the vanilla docker client to interact with powerstrip and therefore by extension - all of the existing orchestration tools.
Capturing JSON messages on their way to the docker server is a far more civilised way to extend docker than trying to "wrap" the docker cli.
In my use case - using the cli - I was struggling to separate the docker arguments from the image name and container args. It's better for docker itself to do that and more generally - its better to use the vanilla docker client (because orchestration tools).
As soon as I was working with the JSON messages generated by the docker client - everything became much easier!
[1]: http://weaveblog.com/2015/01/29/powerstrip-weave-a-docker-ne...
I'm quite happy to see this happening however and see that the batteries included, but removable mantra really is actually happening.
That said one emergency mod_rewrite rule later and we fixed the issue - which was that the HN link went to the link without the trailing slash which was hitting the database! :'(
