Skip to content
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

Remove yamlgen. Refactor deployment and yaml generation to use Helm templating #350

Merged
merged 1 commit into from
Jun 12, 2023

Conversation

jpmcb
Copy link
Contributor

@jpmcb jpmcb commented Dec 1, 2022

Issue number:

Closes #126

Description of changes:

Refactors deployment and yaml templating to use Helm. Still a work in progress. Using this draft PR as a staging area for early feedback

Testing done:

Able to:

  • make images
  • helm install brupop-crd deploy/charts/bottlerocket-shadow
  • helm install brupop deploy/charts/bottlerocket-update-operator

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

@jpmcb
Copy link
Contributor Author

jpmcb commented Dec 15, 2022

Force pushed to update certificate resources that changed with #340 - Ran through successful updates using:

$ helm install brupop-crd --create-namespace deploy/charts/bottlerocket-shadow
$ helm install brupop deploy/charts/bottlerocket-update-operator

@jpmcb jpmcb force-pushed the helm-refactor branch 3 times, most recently from 6425170 to 64622a9 Compare December 20, 2022 16:30
@jpmcb
Copy link
Contributor Author

jpmcb commented Dec 20, 2022

Force pushed:

  • fixed build errors
  • resolved merge conflict (with Cargo.lock update)
  • Updated READMEs with documentation on how to install brupop via helm
  • added make manifest target that can be used to generate manifest at root of repository
  • Removed .env file (in favor of helm values yaml file)
  • Added logic to create / delete brupop namespace in integration tests

Marking this as ready for review.

There are no big things left to do here and I'd love to start getting some feedback from the community. I'm sure there are little things left here since this is a bigger refactor, but we can continue to tackle those in the coming weeks!

We'll also want to think about doing a one off change to the new release workflow to ensure that works for releases. Aka, we can change that to trigger on each push to develop and ensure it's working properly. That workflow is designed to push a helm repo to a github page hosted in this repository. We'll also need to ensure we have the right access right associated with that so it can be created on release automatically.

@jpmcb jpmcb marked this pull request as ready for review December 20, 2022 16:36
@jpmcb jpmcb requested review from gthao313 and cbgbt December 20, 2022 16:38
@jpmcb jpmcb changed the title WIP: Refactor deployment and yaml generation to use Helm Refactor deployment and yaml generation to use Helm Dec 21, 2022
Copy link
Contributor

@stmcginnis stmcginnis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. There are a lot of changes here, but with the noted testing done I feel comfortable with the change.

Looks like there is a merge conflict to be resolved now. Since an update is needed anyway, a couple small things pointed out.

deploy/build.rs Outdated
const DEPLOY_DIR: &str = env!("CARGO_MANIFEST_DIR");

fn main() {
dotenv::dotenv().ok();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're still using dotenv as a development tool, should we leave the .env file around with some comments for what it can do?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmm that's a good point - I think this means we'll have to yes. Let me circle back and look at that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new workflow should become:

  1. Create a values.yaml file (maybe we can create a top level one for development purposes and git ignore it)
  2. Populate it with necessary values. For example:
namespace: "my-custom-ns"
  1. Pass the values yaml file to be used during install either via:
  • helm install -f values.yaml ... (to install to a cluster)
  • helm template -f values.yaml ... > file.yaml (to template into the yaml)

I think there's some better dev UX to tease out here, especially with how the integration tests work into this flow: currently, the integration tests will just read from bottlerocket-update-operator.yaml and apply that to the cluster but there's opportunity here to make this more seamless.

@cbgbt
Copy link
Contributor

cbgbt commented Jan 9, 2023

This is awesome, nice work @jpmcb! 🚀

Copy link
Contributor

@cbgbt cbgbt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, forgot to hit send on these.

@jpmcb
Copy link
Contributor Author

jpmcb commented Jan 12, 2023

Force pushed to correct for Cargo.lock merge conflict.

Going to do another round of iteration here based on comments and a few TODO lines left.

@jpmcb
Copy link
Contributor Author

jpmcb commented Jan 13, 2023

Force pushed to add the following:

  • Snapshot testing of our generated yaml CRDs. This way, if something changes under the hood in our rust CRD definitions, we can have a signal to accept/reject those changes. This mechanism can also be used as an indicator to update the CRD templates in the helm chart.
    • cargo test to run snapshot tests via insta. And cargo insta review to accept new snapshots.
    • make check-crd-golden-diff to compare the rust generated CRD yaml to the helm chart template.
  • Remove const declaration of namespace. With the helm chart, removes the requirement that users deploy into the bottlerocket-aws namespace we had hard coded. Now, we infer the current in cluster namespace from configs.
  • Update docs based on feedback

Integration tests still looking 👍🏼

❯ k get bottlerocketshadows -A
NAMESPACE                 NAME                                                STATE   VERSION   TARGET STATE   TARGET VERSION   CRASH COUNT
brupop-bottlerocket-aws   brs-ip-192-168-142-119.us-west-2.compute.internal   Idle    1.11.1    Idle                            0
brupop-bottlerocket-aws   brs-ip-192-168-144-207.us-west-2.compute.internal   Idle    1.11.1    Idle                            0
brupop-bottlerocket-aws   brs-ip-192-168-156-62.us-west-2.compute.internal    Idle    1.11.1    Idle                            0

@jpmcb
Copy link
Contributor Author

jpmcb commented Jan 18, 2023

Force pushed to template a few remaining references to brupop-bottlerocket-aws - getting close!!

@jpmcb jpmcb changed the title Refactor deployment and yaml generation to use Helm Remove yamlgen. Refactor deployment and yaml generation to use Helm templating Jan 18, 2023
Copy link
Contributor

@cbgbt cbgbt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Just a few minor changes that I'd like to see and a few nits that I could take or leave.

@jpmcb
Copy link
Contributor Author

jpmcb commented Feb 14, 2023

Force pushed to address merge conflicts - addressing comments next!

@jpmcb
Copy link
Contributor Author

jpmcb commented Feb 14, 2023

Force pushed to address above comments

@jpmcb
Copy link
Contributor Author

jpmcb commented Feb 17, 2023

Force push to address Sean's comments around infering the namespace throughout. Now, when the various client configs are created, we pass down the namespace into subsequent constructors that require namespaced resources. It didn't make sense to have to create a new client config with each query to namespaced resources. That would be a frequent, costly operation. Instead, we can now access the namespace data member built from new.

Copy link
Contributor

@cbgbt cbgbt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super clean! Nice work John! 🚀 🎉

Copy link
Contributor

@webern webern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About 1/3 coverage from me. A few questions of ignorance on my part. Looks good.

@@ -217,11 +217,14 @@ async fn run() -> Result<()> {
)
.await
.context(error::LoadKubeConfigSnafu)?;

// infer the default namespace from the loaded kubeconfig
let namespace = config.default_namespace.to_string();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the user can configure the namespace of their choice, how is it that you get that from the kubeconfig?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question: the config.default_namespace property is the namespace defined by the loaded client config. This is typically the namespace of where the execution is currently happening.

So, in the case of the controller, it reads the in-cluster config and infers that it is in the "bottlerocket-aws" (or whatever the namespace was set during deploy).

This case in the integration tests is abit different in that we aren't inferring a in-cluster client config, we load one explicitly from eksctl. But the principle is the same - it infers the default namespace to deploy some stuff to (and in this case, it is actually "default")

It's abit confusing because the name "default" is overloaded. Most of the time, from the controllers perspective, we are simply attempting to infer what namespace the current context is executing from.

@jpmcb
Copy link
Contributor Author

jpmcb commented Feb 24, 2023

Force pushed to rename the insta Rust test file in order to be abit more clear what's happening. The name of this file should now be insta_test__generated_crds.snap which is the <test-filename>__<test-name>.snap

FYI - this will also need a hefty rebase and abit of additonal legwork to get in once the cron PR merges

@nalshamaajc
Copy link

I hope this helm chart gets ready soon! 🙏 😄

@lsobowalejc
Copy link

Yes! this is definitely a needed feature. Can't wait!

@maxres-ch
Copy link

Hi there. Just wanted to check if there's any insight on when this might be merged?

@jpmcb jpmcb force-pushed the helm-refactor branch 2 times, most recently from 9b98b50 to 7399de4 Compare June 1, 2023 18:38
@jpmcb
Copy link
Contributor Author

jpmcb commented Jun 1, 2023

Force pushed with large rebase (which included integrating the work for the scheduler cron) and some docs updates. The biggest thing you'll notice is different is the templates now include the scheduler_cron_expression template value.

diff --git a/bottlerocket-update-operator.yaml b/bottlerocket-update-operator.yaml
index cf982ec..a96c65a 100644
--- a/bottlerocket-update-operator.yaml
+++ b/bottlerocket-update-operator.yaml
@@ -711,10 +711,8 @@ spec:
                   fieldPath: spec.nodeName
             - name: MAX_CONCURRENT_UPDATE
               value: "1"
-            - name: UPDATE_WINDOW_START
-              value: "0:0:0"
-            - name: UPDATE_WINDOW_STOP
-              value: "0:0:0"
+            - name: SCHEDULER_CRON_EXPRESSION
+              value: "* * * * * * *"
           image: public.ecr.aws/bottlerocket/bottlerocket-update-operator:v1.0.0
           name: brupop
       priorityClassName: brupop-controller-high-priority

Testing

  1. Deployed new nodegroup to a k8s cluster

  2. Installed shadow CRD successfully:

$ helm install brupop-crd deploy/charts/bottlerocket-shadow
...

$ kubectl get crds
NAME                                          CREATED AT
bottlerocketshadows.brupop.bottlerocket.aws   2023-06-01T18:24:49Z
...
  1. Installed the controller stack:
$ kubectl create namespace brupop-bottlerocket-aws
$ helm install brupop deploy/charts/bottlerocket-update-operator
...
  1. Nodes update as expected.

This should be ready to go in now

@gthao313
Copy link
Member

gthao313 commented Jun 1, 2023

Follow the instruction above, it works perfectly on my side! nice work!!!

Copy link
Contributor

@stmcginnis stmcginnis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good, and I think it would be great to get this in and available to get more usages/feedback.

Copy link
Contributor

@stmcginnis stmcginnis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Looks like the checks might just need a re-run to get by a transient error.

- helm install brupop-crd --create-namespace deploy/charts/bottlerocket-shadow
- helm install brupop deploy/charts/bottlerocket-shadow
- Able to deploy brupop to different namespaces
- Removes yamlgen subprogram
  - Snapshot testing of rust generated CRD yaml via cargo insta

Signed-off-by: John McBride <[email protected]>
@jpmcb
Copy link
Contributor Author

jpmcb commented Jun 7, 2023

Force pushed to rebase on develop which now has fixes for problems caused by #461

Copy link
Contributor

@stmcginnis stmcginnis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's gooooo!! 🥳

@jpmcb jpmcb merged commit 0c7a21e into bottlerocket-os:develop Jun 12, 2023
@jpmcb jpmcb deleted the helm-refactor branch June 12, 2023 20:33
@gthao313 gthao313 mentioned this pull request Jul 10, 2023
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0.2.0: Create Brupop Helm Chart
8 participants