NG: extension model

[dmp42]

We need an "extension model" that will let people author useful optional features to the registry.

Registry v1 supported extensions as separate python packages that would consume signals.

Right now, the following ideas have been suggested:

• use https://github.com/docker/libchan
• use https://github.com/docker/libswarm
• use plain old-school http and long polling
• use mitchell plugins: https://github.com/mitchellh/packer/tree/master/packer/plugin
• hard compile the extensions in
• expect go to support dynamic loading

Now, figuring out the proper "communication channel" is only half of the story, and we should also design the API itself.

Your input welcome!

[proppy]

hard compile the extensions in

I'd be in favor of starting simple with this. You can always switch to something else when you start hitting scale problem (more than 10 extensions).

[noxiouz]

I'd be in favor of starting simple with this. You can always switch to something else when you start hitting scale problem (more than 10 extensions).

For the first step it's reasonable. But it's really hard to maintain (as far as I know extensions were removed from docker-registry core repo beacause of that). Registry could provide an interface for registering your own plugin like http://golang.org/pkg/database/sql/#Register. In this case each plugin developer, who can't put extension implementation to the docker-registry core repo, has to distirbute special build with his/her plugin. For example, I can't distribute my Elliptics extension with core as it needs Elliptics binary package to be built. In python epoch, it was not imported if it wasn't used, so didn't bring problems.

Also I suppose there're a lot of people who don't like/want to learn go, but they're mad about Docker Registry =) and that guys possibly want to write extensions in other languages (for example, there's no golang binding for their technology), so clean RPC communication protocol would help them.

[dmp42]

@noxiouz I tend to think backend storage drivers (like elliptics) should NOT be "extensions".

There are some shared concerns between the two things, but also different requirements.

Specific discussion about the drivers may go there: #616

[progrium]

I spend a lot of time on these things. Here is one system that lets you do native Go plugins, JavaScript plugins, or other language backends:
https://github.com/progrium/go-plugins

Long term I'm trying to get https://github.com/progrium/duplex (eventually on top of libchan) to implement the protocol for go-plugins so that you can use the same system for remote extensions. And then I would also like to wrap this up for local plugins in the same way mitchell has architected, but in a more general way. Would love to try and collaborate on any of this!

[dmp42]

So, what are the merits of the various solutions here?

Anyone willing to do some comparison between libchan, progrium, mitchell solution / others?

[stevvooe]

Superseded by distribution/distribution#136.