[progrium]

I'm involved as an independent collaborator again in Docker's internal extension efforts, and after I saw this I got ClusterHQ looped in to that working group. Then we talked about collaborating on a Go port of Powerstrip, so I'm working on that here: https://github.com/ClusterHQ/powerstrip/tree/golang

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.

[michaelsbradley]

Do you know if Powerstrip could be used to extend the entire family of Docker tools: machine, compose (fig), swarm?

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.

[lewq]

Hey Michael!

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

[binocarlos]

Hi,

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.