-
Notifications
You must be signed in to change notification settings - Fork 52
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
new: dynamic builders #244
Conversation
Note: CI will fail badly of course, because images cannot be found. Moreover, i still need to update multiple docs files. I just wanted to share this asap to get some comments ;) |
Example test (i pushed an image to my own dockerhub):
|
Possible way to fix tests:
|
As expected, integration tests are failing with:
|
Instead of naming the builder images using the aforementioned regex, we could build a solution that uses http docker registry API to fetch image labels for each image without actually pulling the image; this is done eg by this project: https://github.com/felicianotech/sonar/blob/7d98bae716997a3016c74ec5b1518601e5ca59ae/sonar/docker/label.go#L11 Let's assume this is in place, we could have multiple labels:
In the end, this method allows for cleaner builder images dockerfiles; moreover has the big plus that LABELS and installed GCCs are declared in the very same context (ie: the dockerfile), therefore it is harder to have it wrong (while is much easier to get image name wrong instead). At the same time, i am afraid that the http api could change (eg: being bumped to v3) and therefore we would need more work to keep our code up to date. WDYT? EDIT: i think i could give a try to this impl, perhaps in a single commit, and then we can decide which one we prefer ;) |
On a second thought, the problem with the http registry API version is performance: imagine we need to scrape up to 100 builder images for each repo; this means we are doing 100 http requests for each repo listed; assuming a 10ms ping, we are losing 1s for the build for each repo listed. |
The new images command output example:
|
d7463eb
to
6cc4437
Compare
TODO:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE: provided images should expose full gcc semver fields (ie: even 0 ones), like the above example.
Internally, they should soft link gcc to the full semversioned name, like: ln -s /usr/bin/gcc-5 /usr/bin/gcc-5.0.0.
IMHO it should naot be a big issue. Let me know wyt! We can try to find another solution if you think it is too time consuming doing that (but again, i don't really think so).
Agreed, adopting this convention of linking to a semver gcc is not a big deal. Thanks for this feature! In terms of maintenance, we don't have to maintain the static map of gcc versions anymore correct?
Exactly! |
…d indexing given a docker repo. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Ported makefile too. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
….0.Dockerfile. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
…epo to integration tests. This should allow us to test them. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
…by user, if any. In this way, we are able to support `--gccversion` properly. Moreover, `images` cmd is now `--gccversion` aware. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
bad00ce
to
67cca5d
Compare
After latest commits, i fixed Example:
And using
|
IMHO the PR is ready; removed the wip; adding the hold label like for a week or so, to wait to gather some more feedback :) |
Thank you for the incredible amount of work that's gone into this. 🙏 How do you feel about changing the name of the new driverkit command-line arg from /lgtm |
Uh it is a neat idea! Thank you! |
For a future CLI api break...i feel like The same could apply to Like:
And so on, even Cobra does not support this right now but a PR might get merged soonish: spf13/cobra#1778 |
Done @dwindsor :) |
Signed-off-by: Federico Di Pierro <nierro92@gmail.com> Co-authored-by: David Windsor <dwindsor@secureworks.com>
c7d76f2
to
4e0f11c
Compare
Run |
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Improved documentation! 📄 |
/unhold |
@dwindsor can you reapprove since i pushed some more docs? :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Goodbye static list of builders =)
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dwindsor, FedeDP The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
/area build
/area cmd
/area pkg
What this PR does / why we need it:
This PR implements the proposed improvements to builder images: #241 .
Basically, we do now allow to pass a list of docker repos in descending priority order.
falcosecurity/driverkit
is always emplaced back, so that is has lowest available priority.List of images is then dynamically and transparently loaded at runtime, given that images in the passed repositories follow this scheme for their name:
driverkit-builder-(?P<target>[a-z0-9]+)-(?P<arch>x86_64|aarch64)(?P<gccVers>(_gcc[0-9]+.[0-9]+.[0-9]+)+)$
, basically, it means something like this:myrepo/driverkit-builder-ubuntu-x86_64_gcc5.8.0_gcc7.0.0
.NOTE: provided images should expose full gcc semver fields (ie: even 0 ones), like the above example.
Internally, they should soft link gcc to the full semversioned name, like:
ln -s /usr/bin/gcc-5 /usr/bin/gcc-5.0.0
.IMHO it should not be a big issue. Let me know wyt! We can try to find another solution if you think it is too time consuming doing that (but again, i don't really think so).
This PR should also improve the situation for @Lowaiz and its #238 patch.
"any" target builder images, are fallback images to be used when a specific-target one is missing. The algorithm goes as follow:
--gccversion
) again, as a full semver string$target_$gccversion
$target_$gccversion
, then, if it could not be found, looking atany_$gccversion
--builderimage
, you must provide the requested GCC (or force a--gccversion
); this was already enforcedWhich issue(s) this PR fixes:
Fixes #241
Special notes for your reviewer:
Does this PR introduce a user-facing change?: