NG: extension: webhooks

[dmp42]

While the extension mechanism is still to be defined, maybe we could have webhooks as an extension, to further extend registry functionality?

That webhooks extension would listen on all core signals, and call whatever registered webhook for the corresponding signal?

[wking]

Please :). IPC that's more widely supported than libchan currently is
would make writing extensions easier. I was trying to decide how to
handle things like a search engine (#687) if it was driven via
webhooks. The tricky bit would be that you wouldn't want to block
core registry activity just because the search engine was down.
Rather than queuing undelivered messages, I'd rather keep an event
counter, and archive past events in storage. Then the
webhook-subscriber recovery lifecycle would look like this:

1. Registry generates event 123 and sends it to the subscriber
2. Registry generates event 124 and sends it to the subscriber
3. Subscriber dies
4. Registry generates event 125, and tries to send it to the
   subscriber, but fails because the subscriber is dead. The registry
   continues on unphased.
5. Suscriber recovers
6. Registry generates event 126 and sends it to the subscriber
7. Subscriber realizes that the last event it received was 124, so it
   asks the registry to resend event 125.
8. Registry retrieves event 125 from storage and sends it to the
   subscriber.

If the delay between steps five and six is too long, you could always
have a “please send me the most-recent event” endpoint on the
registry.

[zedtux]

Is there any workaround until the final feature is implemented ?

[dmp42]

@zedtux registry v1 (the currently released 0.9 version) supports extensions: https://github.com/docker/docker-registry/tree/master/docker_registry/extensions#docker-registry-extensions

From there it should be easy to implement a webhook extension yourself.

[zedtux]

Thank you @dmp42

[zedtux]

I have checked the document action and it seems that the receiver method doesn't receive information like the namespace, image name and tag name. Am I right ?

[dmp42]

I believe it does: https://github.com/docker/docker-registry/blob/0dd4fc818da236c3e5df8c6c87fd4f3da19492d7/docker_registry/index.py#L76

Am I missing something?

[zedtux]

Thank you. I have only checked the link you gave me where there isn't any parameters. Your second link looks much better 😃

[ncdc]

OpenShift keeps track of Docker image metadata and can perform actions such as updating a deployment when it notices there's an updated image in a repository. We're currently doing this with the v1 registry using an extension we wrote that does an http post to OpenShift whenever there's a new tag.

I'll second @wking's thoughts re the ability for a downstream client to request events from history. If we're unable to receive "new image" / "new tag" events in real time (e.g. our server is down, there's a network hiccup, or whatever), we'll need an efficient mechanism to reconcile OpenShift's view of all the Docker repositories it's watching with the actual state of those repositories. I suppose a single request to reconcile would be ideal (e.g. give me all the changes to all the repositories starting with event 123). Not sure how feasible that is.

/cc @smarterclayton

[stevvooe]

This issue has been superseded by distribution/distribution#42. Please take further conversation there.