This repository has been archived by the owner on Apr 17, 2023. It is now read-only.
[WIP] Handle registry events in the background #1353
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Miquel Sabaté Solà <[email protected]>
Signed-off-by: Miquel Sabaté Solà <[email protected]>
mssola
added a commit
to mssola/Portus
that referenced
this pull request
Aug 1, 2017
This has been extracted both from https://github.com/openSUSE/docker-containers and SUSE#1353, since it will be useful for SUSE#1357 as well. Signed-off-by: Miquel Sabaté Solà <[email protected]>
|
It will be need a rebase after #1358. |
mssola
added a commit
to mssola/Portus
that referenced
this pull request
Dec 1, 2017
Unless you provided enough Puma workers, there was a problem with HTTP requests getting blocked. This is a similar issue as pointed out in SUSE#1353 with registry events. The solution has been to move security scanning in the background, in a different process. This is similar to SUSE#1353, but more polished (and if this proves to really work we might move SUSE#1353 to this background runner as well). Now the Tag model has two more columns: `vulnerabilities` and `scanned`. The former contains the cached result of the latest security check. The latter is an integer that can have three different values: 0 (scanning not performed), 1 (working on it) and 2 (scanning done). This has also been exposed on the API, so the client side can be updated. Signed-off-by: Miquel Sabaté Solà <[email protected]>
mssola
added a commit
to mssola/Portus
that referenced
this pull request
Dec 4, 2017
Unless you provided enough Puma workers, there was a problem with HTTP requests getting blocked. This is a similar issue as pointed out in SUSE#1353 with registry events. The solution has been to move security scanning in the background, in a different process. This is similar to SUSE#1353, but more polished (and if this proves to really work we might move SUSE#1353 to this background runner as well). Now the Tag model has two more columns: `vulnerabilities` and `scanned`. The former contains the cached result of the latest security check. The latter is an integer that can have three different values: 0 (scanning not performed), 1 (working on it) and 2 (scanning done). This has also been exposed on the API, so the client side can be updated. Signed-off-by: Miquel Sabaté Solà <[email protected]>
mssola
added a commit
to mssola/Portus
that referenced
this pull request
Dec 4, 2017
Unless you provided enough Puma workers, there was a problem with HTTP requests getting blocked. This is a similar issue as pointed out in SUSE#1353 with registry events. The solution has been to move security scanning in the background, in a different process. This is similar to SUSE#1353, but more polished (and if this proves to really work we might move SUSE#1353 to this background runner as well). Now the Tag model has two more columns: `vulnerabilities` and `scanned`. The former contains the cached result of the latest security check. The latter is an integer that can have three different values: 0 (scanning not performed), 1 (working on it) and 2 (scanning done). This has also been exposed on the API, so the client side can be updated. Signed-off-by: Miquel Sabaté Solà <[email protected]>
mssola
added a commit
to mssola/Portus
that referenced
this pull request
Dec 14, 2017
From now on, registry notifications (image got pushed, image deleted) will be handled entirely in the background. Portus itself will only create the event on the DB, and it will expect for it to be handled automatically by the background process. Fixes SUSE#940 See SUSE#1353 and SUSE#1526 Signed-off-by: Miquel Sabaté Solà <[email protected]>
|
Closing in favor of #1537 |
mssola
added a commit
to mssola/Portus
that referenced
this pull request
Dec 14, 2017
From now on, registry notifications (image got pushed, image deleted) will be handled entirely in the background. Portus itself will only create the event on the DB, and it will expect for it to be handled automatically by the background process. Fixes SUSE#940 See SUSE#1353 and SUSE#1526 Signed-off-by: Miquel Sabaté Solà <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As some issues have pointed out (#940 and #1235), Portus can freeze if it doesn't have enough Puma workers. The solution is to either increase the value of available Puma workers, or setup an HA setup with multiple Portus instances.
Sometimes this is not possible, so this WIP PR handles events differently:
This way, Portus should not freeze even if there are no workers. This is configurable and disabled by default, since it makes the deployment of Portus more complex, and it's riskier imho than what we currently have.