chore: publish

wispl · wispl · commit d04a5ccb112f · 2026-06-03T19:15:35.000-04:00
diff --git a/content/notes/20260309033816-3d_printing.md b/content/notes/20260309033816-3d_printing.md
@@ -1,15 +1,17 @@
 +++
 title = "3D Printing"
 date = 2026-03-09
-updated= 2026-04-15
+updated= 2026-06-02
 [taxonomies]
 tags = ["index"]
 +++
 
+3D printing is really good for fast prototyping. But it is also used quite often for the final product soooo it is a good idea to get the most out of it.
+
+
 ## Design {#design}
 
 -   [Sacrificial Layers and Bridges](@/notes/20260309124617-sacrificial_layers_and_bridges.md)
--
 
 
 ## Filaments {#filaments}
@@ -20,3 +22,8 @@ tags = ["index"]
 -   [Annealing](@/notes/20260309123150-annealing.md)
 -   [Threaded Inserts](@/notes/20260309033856-threaded_inserts.md)
 -   Chamfer or fillet base to avoid elephant's foot effect
+
+
+## Printer Calibration {#printer-calibration}
+
+See the following [link](https://teachingtechyt.github.io/calibration.html).
diff --git a/content/notes/20260309123150-annealing.md b/content/notes/20260309123150-annealing.md
@@ -1,7 +1,7 @@
 +++
 title = "Annealing"
 date = 2026-03-09
-updated= 2026-03-09
+updated= 2026-06-03
 +++
 
 ## PLA {#pla}
@@ -25,4 +25,4 @@ Not much information on annealing for PETG, issues with crystallization and also
 ## References {#references}
 
 -   <https://www.youtube.com/watch?v=CZX8eHC7fws>
--   <https://www.sciencedirect.com/science/article/pii/S0142941825000492#:~:text=Thermal%20annealing%20enhances%20the%20mechanical%20performance%20of%203D-printed,the%20strength%20and%20structural%20integrity%20of%20PLA%20parts>.
+-   [sciencedirect](https://www.sciencedirect.com/science/article/pii/S0142941825000492#:~:text=Thermal%20annealing%20enhances%20the%20mechanical%20performance%20of%203D-printed,the%20strength%20and%20structural%20integrity%20of%20PLA%20parts)
diff --git a/content/notes/20260314014923-systems_design.md b/content/notes/20260314014923-systems_design.md
@@ -1,18 +1,20 @@
 +++
 title = "Systems Design"
 date = 2026-03-14
-updated= 2026-05-23
+updated= 2026-06-02
 [taxonomies]
 tags = ["index"]
 +++
 
-## Kubernetes and Openshift {#kubernetes-and-openshift}
+## [Kubernetes](@/notes/20260602012604-kubernetes.md) {#kubernetes--20260602012604-kubernetes-dot-md}
+
+Note that Openshift is basically just RedHat flavored Kubernetes, or in other words, Kubernetes for corporates since RHEL certified means it checks off many checkboxes on a list.
 
 
 ### [Adapting Containers for Openshift](@/notes/20260319195926-adapting_containers_for_openshift.md) {#adapting-containers-for-openshift--20260319195926-adapting-containers-for-openshift-dot-md}
 
 
-### [GitOps](@/notes/20260523033331-gitops.md) {#gitops--20260523033331-gitops-dot-md}
+### [Shibboleth in K8](@/notes/20260319193940-shibboleth_in_k8.md) {#shibboleth-in-k8--20260319193940-shibboleth-in-k8-dot-md}
 
 
 ## Others {#others}
diff --git a/content/notes/20260401033133-rocketry.md b/content/notes/20260401033133-rocketry.md
@@ -1,11 +1,31 @@
 +++
 title = "Rocketry"
 date = 2026-04-01
-updated= 2026-04-01
+updated= 2026-06-03
 [taxonomies]
 tags = ["index"]
 +++
 
-## L1, L2, L3 {#l1-l2-l3}
+## Introduction {#introduction}
 
--   [L1 Certification](@/notes/20260401033211-l1_certification.md)
+The most common recommendation is to make a rocket which can fly for L1 and L2 certs. In my case I kind of made two separate rockets for the sake of having two rockets (my wallet...). These certifications are for **high-power rockets**, which are more dangerous than **low-power rockets** which makes sense. Everything dangerous that comes to mind when you hear high-power applies to these rockets which means these rockets should
+
+1.  good structural durability: use wood instead of thin tubes
+2.  be even more careful around when launching: these are literally missiles
+3.  understand the rocket fully: know its motor thrust, know for certain that the rocket can fly without causing damage, know that the ejection charge works
+
+A simulator like [OpenRocket](https://openrocket.info/) is very helpful for getting an understanding of whether your rocket works or note. See [Rocket Parts](@/notes/20260603015639-rocket_parts.md) for a rundown of common and important rocket components.
+See [Dual Deployment](@/notes/20260603024422-dual_deployment.md) for how a parachute deploys for a rocket.
+
+
+## [L1 Certification](@/notes/20260401033211-l1_certification.md) {#l1-certification--20260401033211-l1-certification-dot-md}
+
+Very straight forward. Motors are generally H or I class.
+
+
+## L2 Certification {#l2-certification}
+
+At this point you might consider [Dual Deployment](@/notes/20260603024422-dual_deployment.md), or you might save it for the L3 rocket.
+
+
+## L3 Certification {#l3-certification}
diff --git a/content/notes/20260523033331-gitops.md b/content/notes/20260523033331-gitops.md
@@ -1,7 +1,7 @@
 +++
 title = "GitOps"
 date = 2026-05-23
-updated= 2026-05-30
+updated= 2026-06-02
 +++
 
 ## Introduction {#introduction}
@@ -63,7 +63,7 @@ Along with any other required stuff. In the pipelines you might directly make co
 ## Making Commits {#making-commits}
 
 You will probably need an access token and then use ssh in the pipelines to clone the project and make commits.
-Example of a pipline implentation: [GitOps Pipelines Example](@/notes/20260529032917-gitops_pipelines_example.md).
+Example of a pipeline implementation: [GitOps Pipelines Example](@/notes/20260529032917-gitops_pipelines_example.md).
 
 
 ## Secrets {#secrets}
@@ -73,9 +73,11 @@ Since we are commiting manifests, which includes kubernetes Secrets and therefor
 1.  outside of cluster: using something like KSOPS and SOPs so they are encrypted on the repo but gets decrypted before it gets sent to the cluster
 2.  inside of cluser: the secret gets decoded or fetched after it arrives at the cluster
 
-ArgoCD recommends secret decoding inside of the cluster, so it doesn't have to handle secrets. In that case, there are a couple of solutions: External Secret Operator (ESO) or CSI allows you to store secrets elsewhere, like using Hashicorp Vault or its open source cousin OpenBao, and then have the cluster fetch it, or Bitnami SealedSecrets, which uses GPG keys to encrypt the secrets (which you commit) and then send to the cluster to have them decrypted.
+ArgoCD recommends secret decoding inside of the cluster, so it doesn't have to handle secrets[^fn:1]. In that case, there are a couple of solutions: External Secret Operator (ESO) or CSI allows you to store secrets elsewhere, like using Hashicorp Vault or its open source cousin OpenBao, and then have the cluster fetch it, or Bitnami SealedSecrets, which uses GPG keys to encrypt the secrets (which you commit) and then send to the cluster to have them decrypted.
 
 
-## Reference {#reference}
+## References {#references}
 
 <https://www.digitalocean.com/community/tutorials/how-to-deploy-to-kubernetes-using-argo-cd-and-gitops>
+
+[^fn:1]: See <https://argo-cd.readthedocs.io/en/stable/operator-manual/secret-management/>
diff --git a/content/notes/20260529032917-gitops_pipelines_example.md b/content/notes/20260529032917-gitops_pipelines_example.md
@@ -1,9 +1,11 @@
 +++
 title = "GitOps Pipelines Example"
 date = 2026-05-29
-updated= 2026-05-29
+updated= 2026-06-03
 +++
 
+## Pipeline Config {#pipeline-config}
+
 This is an example in GitLab, though I think it can be trivially ported elsewhere (me thinks)
 
 ```yaml
@@ -33,4 +35,66 @@ container:
     - buildah build -t "$CI_REGISTRY_IMAGE/container:${CI_COMMIT_SHA}" ./container
     - buildah push "$CI_REGISTRY_IMAGE/container:${CI_COMMIT_SHA}"
 
+make_commit:
+  image: alpine/git # Might be better to just an alpine container and add git manually
+  stage: deploy
+  script:
+    - git config --global user.name "Evil Bot"
+    - git config --global user.email "EvilBot@evilplace.com"
+    - git clone "https://your.repo.com"
+    # Edit your manifests using whatever: yq, sed, awk
+    # This one changes the image version, but you can do whatever your hear desires
+    - yq -i '.images[].newTag = strenv(CI_COMMIT_SHA)' kustomization.yml
+
+    # Commit and push!
+    - git add kustomization.yaml
+    - git commit -m "Deploy ${CI_COMMIT_SHA} to dev!!!"
+    - git push origin main
+```
+
+As an aside, when using `sed`, things get a bit trickly in regards to quoting, since you need quotes to expand the ENV variables, so you quote the whole thing and then use backslashes to escape the double quotes you want.
+
+
+## Kustomization.yaml {#kustomization-dot-yaml}
+
+Generally you would have Kustomization.yaml file in `base/` and then one in each of your overlays, for example
+
+```sh
+/base/Kustomization.yaml
+/overlays/dev/Kustomization.yaml
+/overlays/prod/Kustomization.yaml
 ```
+
+And in the file for `dev`, you might have something like this
+
+```yaml
+namePrefix: dev-
+resources:
+- ../../base
+- extra.yaml
+- dev-specific-stuff.yaml
+
+# Modify yaml files in base using patches, which are just JSON patch documents. You can pass in a file or just inline it
+patches:
+- target:
+   version: v1
+   group: route.openshift.io
+   kind: Route
+   name: shrunk
+  patch: |-
+    - op: replace
+      path: /spec/host
+      value: bleh.com
+
+# k8 has builtin configuration for images without using patches
+# Whenever you use frontend for an image, like the following
+#   image: frontend
+# k8 will replace frontend with the give name and tag
+images:
+- name: frontend
+  newName: your.registry.com
+  newTag: "latest"
+```
+
+
+## [GitLab Pipelines Basics](@/notes/20260602020259-gitlab_pipelines_basics.md) {#gitlab-pipelines-basics--20260602020259-gitlab-pipelines-basics-dot-md}
