I'm importing buildah into an application and I don't see a good way to commit multiarch images with github.com/containers/buildah/commit.go/Commit. I see that define.BuildOpts has a platform that is slice of structs that is used for building multi-arch images. The only architecture selection that i see for Commit, is a SystemContext.ArchitectureChoice, which is a single string. Do I have to use bud for multi-arch builds or is there a streamlined way to use Commit?
On Thu, Sep 30, 2021 at 09:33:54PM -0000, aflom@redhat.com wrote:
I'm importing buildah into an application and I don't see a good way to commit multiarch images with github.com/containers/buildah/commit.go/Commit. I see that define.BuildOpts has a platform that is slice of structs that is used for building multi-arch images. The only architecture selection that i see for Commit, is a SystemContext.ArchitectureChoice, which is a single string.
Do I have to use bud for multi-arch builds or is there a streamlined way to use Commit?
The Commit() method only knows how to commit a single working container to produce a single image. I don't know of a way to change that that doesn't require making changes to the API that would in turn require consumers of the library to be patched when updating, and I'm resistant to making such changes. (They probably still happen, but I try.) If the calling application needs to build multiple images, it needs to manage and iterate through the set of platforms it wants to do that for, like the imagebuildah package does for its builds. HTH, Nalin
Thanks for that. I now see the logic used to build the multiarch images in imagebuildah and then the logic for building fat manifests right under that loop. Looks like a pretty big lift for my project, so I'll opt to use bud. When I import bud into my project, it crashes when it tries to execute the first command in the containerfile (entrypoint/add/cmd). Do you have any boilerplate for importing bud similar to 04-include-in-your-build-tool.md for commit? Thanks again, /Alex On Fri, Oct 1, 2021 at 9:56 AM Nalin Dahyabhai <nalin@redhat.com> wrote:
On Thu, Sep 30, 2021 at 09:33:54PM -0000, aflom@redhat.com wrote:
I'm importing buildah into an application and I don't see a good way to commit multiarch images with github.com/containers/buildah/commit.go/Commit. I see that define.BuildOpts has a platform that is slice of structs that is used for building multi-arch images. The only architecture selection that i see for Commit, is a SystemContext.ArchitectureChoice, which is a single string.
Do I have to use bud for multi-arch builds or is there a streamlined way to use Commit?
The Commit() method only knows how to commit a single working container to produce a single image. I don't know of a way to change that that doesn't require making changes to the API that would in turn require consumers of the library to be patched when updating, and I'm resistant to making such changes. (They probably still happen, but I try.)
If the calling application needs to build multiple images, it needs to manage and iterate through the set of platforms it wants to do that for, like the imagebuildah package does for its builds.
HTH,
Nalin
On Fri, Oct 01, 2021 at 01:20:09PM -0400, Alex Flom wrote:
Thanks for that. I now see the logic used to build the multiarch images in imagebuildah and then the logic for building fat manifests right under that loop. Looks like a pretty big lift for my project, so I'll opt to use bud.
When I import bud into my project, it crashes when it tries to execute the first command in the containerfile (entrypoint/add/cmd). Do you have any boilerplate for importing bud similar to 04-include-in-your-build-tool.md for commit?
I don't have boilerplate handy, but some details about the error you're encountering might be helpful in diagnosing it. One gotcha I'd suspect is that the CommonBuildOpts field is required in the build options. HTH, Nalin
I've been using an empty CommonBuildOpts in the BuildOptions. Looks like it is successfully running the FROM step in the containerfile and then fails on the second step. I've tried changing the second step to various actions with the same result. I've also verified that I am able to pull that image on the host. Here is the output at the failure: [linux/s390x] STEP 1/5: FROM quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e [linux/amd64] STEP 1/5: FROM quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e [linux/arm64] STEP 1/5: FROM quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e [linux/ppc64le] STEP 1/5: FROM quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e [linux/s390x] STEP 2/5: ENTRYPOINT ["/bin/opm"] [linux/arm64] STEP 2/5: ENTRYPOINT ["/bin/opm"] [linux/ppc64le] STEP 2/5: ENTRYPOINT ["/bin/opm"] [linux/amd64] STEP 2/5: ENTRYPOINT ["/bin/opm"] time="2021-10-01T18:16:56Z" level=error msg="4 errors occurred:\n\t* error building at STEP \"ENTRYPOINT /bin/opm\": On Fri, Oct 1, 2021 at 1:45 PM Nalin Dahyabhai <nalin@redhat.com> wrote:
Thanks for that. I now see the logic used to build the multiarch images in imagebuildah and then the logic for building fat manifests right under
loop. Looks like a pretty big lift for my project, so I'll opt to use bud.
When I import bud into my project, it crashes when it tries to execute
On Fri, Oct 01, 2021 at 01:20:09PM -0400, Alex Flom wrote: that the
first command in the containerfile (entrypoint/add/cmd). Do you have any boilerplate for importing bud similar to 04-include-in-your-build-tool.md for commit?
I don't have boilerplate handy, but some details about the error you're encountering might be helpful in diagnosing it.
One gotcha I'd suspect is that the CommonBuildOpts field is required in the build options.
HTH,
Nalin
-- Alex Flom Solution Architect Red Hat <https://www.redhat.com/> Virginia Beach, VA aflom@redhat.com <jflowers@redhat.com> M: 970.443.0191 <https://red.ht/sig>
On Fri, Oct 01, 2021 at 02:21:20PM -0400, Alex Flom wrote:
Looks like it is successfully running the FROM step in the containerfile and then fails on the second step. I've tried changing the second step to various actions with the same result. I've also verified that I am able to pull that image on the host.
Here is the output at the failure: [linux/s390x] STEP 1/5: FROM quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e [linux/amd64] STEP 1/5: FROM quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e [linux/arm64] STEP 1/5: FROM quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e [linux/ppc64le] STEP 1/5: FROM quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e [linux/s390x] STEP 2/5: ENTRYPOINT ["/bin/opm"] [linux/arm64] STEP 2/5: ENTRYPOINT ["/bin/opm"] [linux/ppc64le] STEP 2/5: ENTRYPOINT ["/bin/opm"] [linux/amd64] STEP 2/5: ENTRYPOINT ["/bin/opm"] time="2021-10-01T18:16:56Z" level=error msg="4 errors occurred:\n\t* error building at STEP \"ENTRYPOINT /bin/opm\":
Was there any detail about why each of them failed after that last ":"? BTW, which version of the library are you using? I'm attaching a sample that seems to work when I build using the current version (v1.23.1). HTH, Nalin
No, the right side of the colon was empty. I'm using your commit that added the AllPlatforms bool to the BuildOptions, but I was getting this same behavior with the latest tagged release. I was able to use Commit() successfully (to show that builds were working in the env at one point), but I am getting the same build errors that I was when I use the BuildOpts and Store from your attachment (using your dockerfile). /Alex On Fri, Oct 1, 2021 at 2:35 PM Nalin Dahyabhai <nalin@redhat.com> wrote:
On Fri, Oct 01, 2021 at 02:21:20PM -0400, Alex Flom wrote:
Looks like it is successfully running the FROM step in the containerfile and then fails on the second step. I've tried changing the second step to various actions with the same result. I've also verified that I am able to pull that image on the host.
Here is the output at the failure: [linux/s390x] STEP 1/5: FROM
quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e
[linux/amd64] STEP 1/5: FROM
quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e
[linux/arm64] STEP 1/5: FROM
quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e
[linux/ppc64le] STEP 1/5: FROM
quay.io/operator-framework/opm@sha256:038007c1c5d5f0efa50961cbcc097c6e63655a2ab4126547e3c4eb620ad0346e
[linux/s390x] STEP 2/5: ENTRYPOINT ["/bin/opm"] [linux/arm64] STEP 2/5: ENTRYPOINT ["/bin/opm"] [linux/ppc64le] STEP 2/5: ENTRYPOINT ["/bin/opm"] [linux/amd64] STEP 2/5: ENTRYPOINT ["/bin/opm"] time="2021-10-01T18:16:56Z" level=error msg="4 errors occurred:\n\t* error building at STEP \"ENTRYPOINT /bin/opm\":
Was there any detail about why each of them failed after that last ":"? BTW, which version of the library are you using? I'm attaching a sample that seems to work when I build using the current version (v1.23.1).
HTH,
Nalin
-- Alex Flom Solution Architect Red Hat <https://www.redhat.com/> Virginia Beach, VA aflom@redhat.com <jflowers@redhat.com> M: 970.443.0191 <https://red.ht/sig>
On Fri, Oct 01, 2021 at 03:34:18PM -0400, Alex Flom wrote:
No, the right side of the colon was empty.
I'm using your commit that added the AllPlatforms bool to the BuildOptions, but I was getting this same behavior with the latest tagged release.
I was able to use Commit() successfully (to show that builds were working in the env at one point), but I am getting the same build errors that I was when I use the BuildOpts and Store from your attachment (using your dockerfile).
This would be a good time to turn up the logging level, and perhaps share the entire Dockerfile. The sample I attached earlier still works here when I update to the tip of the main branch and set AllPlatforms to true, so the bug may be coming from, or be triggered by, something else. Without more information, I don't really know what to suggest. Cheers, Nalin
We don't need to stretch this out. The issue is obviously in my code. I can take it from here. The main() that you attached was pure gold and showed me how to defer the os.Exit called by the maybeReexecUsingUserNamespace which I was previously solving with a defer/recover(). I really appreciate your help on this. /Alex On Fri, Oct 1, 2021 at 4:10 PM Nalin Dahyabhai <nalin@redhat.com> wrote:
On Fri, Oct 01, 2021 at 03:34:18PM -0400, Alex Flom wrote:
No, the right side of the colon was empty.
I'm using your commit that added the AllPlatforms bool to the BuildOptions, but I was getting this same behavior with the latest tagged release.
I was able to use Commit() successfully (to show that builds were working in the env at one point), but I am getting the same build errors that I was when I use the BuildOpts and Store from your attachment (using your dockerfile).
This would be a good time to turn up the logging level, and perhaps share the entire Dockerfile. The sample I attached earlier still works here when I update to the tip of the main branch and set AllPlatforms to true, so the bug may be coming from, or be triggered by, something else. Without more information, I don't really know what to suggest.
Cheers,
Nalin
-- Alex Flom Solution Architect Red Hat <https://www.redhat.com/> Virginia Beach, VA aflom@redhat.com <jflowers@redhat.com> M: 970.443.0191 <https://red.ht/sig>
participants (3)
-
aflom＠redhat.com -
Alex Flom
-
Nalin Dahyabhai