diff --git a/SUPPORT.md b/SUPPORT.md index 690b7d8402..ad6ce504bd 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -10,7 +10,7 @@ For all questions documentation may not cover, we suggest utilizing [Github Disc All code issues should be a [Github Issue](https://github.com/defenseunicorns/zarf/issues/new/choose) that follows the issue template. Following the templates provides the Zarf community a foundation of understanding to be able to assist quickly. -After an issue is made, this issue can be brought into other chanels such as the [Kubernetes Slack #Zarf](https://zarf.dev/slack) channel or the [bi-weekly Zarf Community Meeting](https://docs.zarf.dev/contribute/contributor-guide/). +After an issue is made, this issue can be brought into other channels such as the [Kubernetes Slack #Zarf](https://zarf.dev/slack) channel or the [bi-weekly Zarf Community Meeting](https://docs.zarf.dev/contribute/contributor-guide/). Github Issue / \ diff --git a/adr/0007-use-rust-binary-for-both-injection-stages.md b/adr/0007-use-rust-binary-for-both-injection-stages.md index 776e02d47a..d402e2cd0b 100644 --- a/adr/0007-use-rust-binary-for-both-injection-stages.md +++ b/adr/0007-use-rust-binary-for-both-injection-stages.md @@ -10,7 +10,7 @@ Amends [3. Image injection into remote clusters without native support](0003-ima ## Context -In ADR 3, the decision was made to create a rust binary (`stage1`) that would re-assemble a `registry:2` image and a go registry binary (`stage2`) from a series of configmaps. While this solution works, it is overkill for the operations that `stage2` performs. The `stage2` binary is only responsible for 1. starting a docker registry in `rw` mode, 2. pushing the `registry:2` crane tarball into said registry, 3. starting the docker registry in `r` mode. This `registry:2` image is then immedietely consumed by the `zarf-registry` package, creating a true in-cluster docker registry. The injector pod is then destroyed. The overhead this operation creates: +In ADR 3, the decision was made to create a rust binary (`stage1`) that would re-assemble a `registry:2` image and a go registry binary (`stage2`) from a series of configmaps. While this solution works, it is overkill for the operations that `stage2` performs. The `stage2` binary is only responsible for 1. starting a docker registry in `rw` mode, 2. pushing the `registry:2` crane tarball into said registry, 3. starting the docker registry in `r` mode. This `registry:2` image is then immediately consumed by the `zarf-registry` package, creating a true in-cluster docker registry. The injector pod is then destroyed. The overhead this operation creates: - having to keep track of another binary (making the total number 3 for the zarf ecosystem) - nearly doubling the amount of configmaps loaded into the cluster (makes init slower) diff --git a/adr/0012-local-image-support-via-docker.md b/adr/0012-local-image-support-via-docker.md index b0070f7e48..32a0102d53 100644 --- a/adr/0012-local-image-support-via-docker.md +++ b/adr/0012-local-image-support-via-docker.md @@ -21,7 +21,7 @@ We did extensive investigation into various strategies of loading docker images ## Decision -We had hoped to leverage docker caching and avoid crane caching moreso, but realized that caching was still occurring via Syft for SBOM. Additionally, the extremely-large, local-only image is actually the edge case here and we created a recommended workaround in the FAQs as well as an inline alert when a large docker image is detected. This restores behavior to what it was before the docker daemon support was added, but with the added benefit of being able to load images from the docker daemon when they are available locally. +We had hoped to leverage docker caching and avoid crane caching more, but realized that caching was still occurring via Syft for SBOM. Additionally, the extremely-large, local-only image is actually the edge case here and we created a recommended workaround in the FAQs as well as an inline alert when a large docker image is detected. This restores behavior to what it was before the docker daemon support was added, but with the added benefit of being able to load images from the docker daemon when they are available locally. ## Consequences diff --git a/adr/0017-zarf-bundle.md b/adr/0017-zarf-bundle.md index 50c0e6a2b8..cb2764464d 100644 --- a/adr/0017-zarf-bundle.md +++ b/adr/0017-zarf-bundle.md @@ -80,7 +80,7 @@ Cons: The current proposition (subject to change before acceptance) is **Zarf Bundles**, which a following PR will focus on and create a POC of. -In essense the `zarf-bundle.yaml` would look something like so: +In essence the `zarf-bundle.yaml` would look something like so: ```yaml metadata: diff --git a/adr/0020-package-sources.md b/adr/0020-package-sources.md index 779929641e..df68d58455 100644 --- a/adr/0020-package-sources.md +++ b/adr/0020-package-sources.md @@ -70,7 +70,7 @@ The following sources have been implemented: - Published OCI package (`oci://`) - In-cluster (Deployed) package (`inspect` and `remove` only) -The `layout` library contains the `PackagePaths` struct which supercedes the prior `TempPaths` struct. This new struct contains access methods to different aspects of Zarf's internal package layout. This struct is passed to the `PackageSource` functions to allow for the loading of packages into the correct layout. In order for a package to be loaded into the correct layout, the package must follow the default Zarf package structure, or be converted to the expected structure during loading operations. +The `layout` library contains the `PackagePaths` struct which supersedes the prior `TempPaths` struct. This new struct contains access methods to different aspects of Zarf's internal package layout. This struct is passed to the `PackageSource` functions to allow for the loading of packages into the correct layout. In order for a package to be loaded into the correct layout, the package must follow the default Zarf package structure, or be converted to the expected structure during loading operations. ## Consequences diff --git a/adr/0024-starlight.md b/adr/0024-starlight.md index c4ff820248..9907b00fbb 100644 --- a/adr/0024-starlight.md +++ b/adr/0024-starlight.md @@ -70,7 +70,7 @@ To simplify the development process and improve the performance of the documenta ## Consequences -- During the transition, we will need to update the existing documentation content to work with the new site generator. Additionally, the site archictecture will be re-evaluated and optimized. This _will_ result in many links to current content breaking. +- During the transition, we will need to update the existing documentation content to work with the new site generator. Additionally, the site architecture will be re-evaluated and optimized. This _will_ result in many links to current content breaking. - Every documentation generator has its quirks and limitations, so we will need to adapt to the new workflow and learn how to best utilize the features of Starlight. - The migration will take time and effort, but the benefits of improved performance and flexibility will be worth it in the long run. - The team will need to learn how to use Astro and Starlight, which may require some training and experimentation. diff --git a/packages/zarf-registry/chart/templates/hpa.yaml b/packages/zarf-registry/chart/templates/hpa.yaml index 7045a709d3..cc4d00a85a 100644 --- a/packages/zarf-registry/chart/templates/hpa.yaml +++ b/packages/zarf-registry/chart/templates/hpa.yaml @@ -29,7 +29,7 @@ spec: averageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }} behavior: scaleDown: - # Use 60 second stabilization window becuase zarf will freeze scale down during deploys + # Use 60 second stabilization window because zarf will freeze scale down during deploys stabilizationWindowSeconds: 60 # Initially disable scale down - this gets set to Min later by Zarf (src/test/e2e/20_zarf_init_test.go) selectPolicy: Disabled diff --git a/src/cmd/tools/helm/root.go b/src/cmd/tools/helm/root.go index e496a93cec..50af36d7f1 100644 --- a/src/cmd/tools/helm/root.go +++ b/src/cmd/tools/helm/root.go @@ -235,7 +235,7 @@ func checkForExpiredRepos(repofile string) { } // parse repo file. - // Ignore the error because it is okay for a repo file to be unparseable at this + // Ignore the error because it is okay for a repo file to be unparsable at this // stage. Later checks will trap the error and respond accordingly. repoFile, err := repo.LoadFile(repofile) if err != nil { diff --git a/src/pkg/cluster/tunnel_test.go b/src/pkg/cluster/tunnel_test.go index 41c4aac407..debe363e54 100644 --- a/src/pkg/cluster/tunnel_test.go +++ b/src/pkg/cluster/tunnel_test.go @@ -40,7 +40,7 @@ func TestServiceInfoFromNodePortURL(t *testing.T) { expectedErr: "no matching node port services found", }, { - name: "found serivce", + name: "found service", nodePortURL: "http://localhost:30001", services: []corev1.Service{ { diff --git a/src/pkg/message/handler.go b/src/pkg/message/handler.go index 46fab9cbcf..825aa52fd4 100644 --- a/src/pkg/message/handler.go +++ b/src/pkg/message/handler.go @@ -17,7 +17,7 @@ func (z ZarfHandler) Enabled(_ context.Context, _ slog.Level) bool { return true } -// WithAttrs is not suppported +// WithAttrs is not supported func (z ZarfHandler) WithAttrs(_ []slog.Attr) slog.Handler { return z }