Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

callback system #110

Closed
alfredodeza opened this issue May 24, 2016 · 3 comments
Closed

callback system #110

alfredodeza opened this issue May 24, 2016 · 3 comments

Comments

@alfredodeza
Copy link
Contributor

From @alfredodeza on May 24, 2016 18:59

Whenever a repository is fully built and ready to be consumed, it would be nice to be able to define a URL to get a POST with metadata information about the repository:

  • distro
  • distro version(s)
  • ref (and sha1?)
  • architecture
  • timestamp(s)

This would help if a separate system is in charge of understanding what has been built. For testing purposes it is crucial to be able to know what distro versions at what sha1 are ready to be consumed.

Copied from original issue: ceph/mita#74

@alfredodeza
Copy link
Contributor Author

From @ktdreyer on May 24, 2016 19:29

Internally in Red Hat, IT and engineering is centering around using a message bus (AMPQ) to coordinate these sort of things with the build system. So Koji (Brew, internally) publishes messages to this bus, and other things (Jenkins or whatever) can subscribe to the bus to consume these messages and trigger other events.

Just an idea!

@alfredodeza
Copy link
Contributor Author

Also should support the following events:

  • requested repo to be created
  • repo started to be built
  • repo has been completed / is ready
  • repo failed to be built (include error/traceback payload?)

@alfredodeza
Copy link
Contributor Author

The notification/callback scheme needs to be very robust and fully asynchronous. I imagine a new queue with a celery worker dealing with notifications.

Such a scheme would allow for retrying broken requests for example (up to a configurable maximum), and would prevent the normal flow of code from waiting until a request is properly processed.

This was referenced Jun 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant