-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Doc: Adding documentation for multi-arch operators #5178
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
Conversation
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
Is there anything missing to get this PR merged? |
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.
/lgtm
/hold |
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
New changes are detected. LGTM label has been removed. |
@joelanford anything further required from me to get this doc improvement merged? |
I don't think these docs apply only to golang-based operators. If the ansible/helm base images support multi-arch, we should move these docs into a more generic location. |
@asmacdo what's your proposal? |
@joelanford @asmacdo is there something additional you wish or can you please merge this PR? |
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
/hold cancel My primary concerns have been addressed. Thanks @fgiloux! Seems like @asmacdo may still have an open question on the best location for this doc. Most of this doc is generic, but the one piece that's specific to Go is the caveat about setting GOARCH in the Dockerfile. I also added another comment about that line that I think needs to be addressed before I'm ready to lgtm. |
@joelanford @asmacdo I have checked that both: |
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
See [docker documentation](https://docs.docker.com/buildx/working-with-buildx/#build-multi-platform-images) for additional options. | ||
**Caveats**: the Dockerfile generated by the SDK for the operator explicitely references GOARCH=amd64 for go build. This can be amended to GOARCH=$TARGETARCH. Docker will automatically set the environment variable to the value specified by --platform. With buildah --build-arg will need to be used for the purpose. |
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.
**Caveats**: the Dockerfile generated by the SDK for the operator explicitely references GOARCH=amd64 for go build. This can be amended to GOARCH=$TARGETARCH. Docker will automatically set the environment variable to the value specified by --platform. With buildah --build-arg will need to be used for the purpose. | |
**NOTE**: the Dockerfile generated by the SDK for the operator explicitly references `GOARCH=amd64` for go build. This can be amended to `GOARCH=$TARGETARCH`. Docker will automatically set the environment variable to the value specified by --platform. With `buildah --build-arg` will need to be used for the purpose. |
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.
IMHO this is more a caveat or warning than a note.
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
website/content/en/docs/building-operators/golang/advanced-topics.md
Outdated
Show resolved
Hide resolved
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.
See that not necessary users will do that to integrate with OLM. So, IMHO we need to clarify more it as well. And it seems related to kubernetes-sigs/kubebuilder#2206
I am not sure what you are referring to here. In regards to kubebuilder issue 2206 there is a way of building multi-arch images from common sources and it is what I am documenting here. Surely the scaffolded Makefile could allow for that. Therefore buildx and/or buildah targets would need to be added. |
@camilamacedo86 I hope the changes meet your expectations. Please let me know. |
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.
Hi @fgiloux,
I am ok with the changes it shows fine. IHMO is only missing to be added outside of the Golang language since it is not specific and only applied to Go projects.
Otherwise, /lgtm
@asmacdo @joelanford if you agree with @camilamacedo86 's proposal I will move it to a separate section, an option would be: Building Operators > Multi-arch (at the same level as Ansible, Go, Helm). |
Inside of Building Operators we have only the languages. Note that @asmacdo also suggested the same already : |
That would then be a top level section. IMHO it is little content for it. Another option would be to have: "Testing Operators", "OLM Integration" and this new section together under a more generic section. I am fine either way.
I know that. I am just asking for an agreement on the new location. |
WDYT? Add a new section here such as Advanced Topics and add inside the doc Multiple architectures? |
@camilamacedo86 as per your proposal I have created a new section "Advanced Topics" and added the Multiple architectures content there. I let a couple of introductory lines with a link to the new section in the go specific page. |
@fgiloux just a nit and then I can merge this one: The order to put overview/install/building operators on top was highly discussed in the past. |
Signed-off-by: Frederic Giloux <fgiloux@redhat.com>
@camilamacedo86 I have moved the menu item "Advanced Topics" below "OLM Integration" |
Description of the change:
This change aims to enhance the documentation by providing guidance on how to build multi-arch operators under advanced topics.
Motivation for the change:
More and more operator authors are looking at getting their operators to support multiple architectures. This intends to provide some help for it.