-
Notifications
You must be signed in to change notification settings - Fork 522
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
Allow for a separate API model per variant #588
Conversation
0432719
to
c9e5fa7
Compare
This push updates a few README files to clarify the new location of defaults.toml. |
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.
☃️
c9e5fa7
to
ce0a43a
Compare
This push addresses Ben's comments, the major points of which are:
|
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.
Nice work!
🏂
Pull #578 added support for build variants to support different features and use cases, starting with aws-k8s and aws-dev. These variants use different software, and therefore need different configuration. This change allows for having a different API model (and default values) per variant. The model was moved to workspaces/models. This crate actually contains the model for each variant in separate subdirectories. Cargo's `build.rs` is used to symlink in the proper source code before build. The "proper" source code is chosen using the VARIANT environment variable. The build system passes this through using the value of BUILDSYS_VARIANT, which is set in the top-level Makefile.toml and can be overridden on the command-line. For local cargo builds, the developer must set the VARIANT environment variable; we don't currently want to choose a default model. To start out, the aws-k8s and aws-dev models (and related default values) are copies, with aws-dev having the Kubernetes-related values removed. The next step is to figure out an appropriate method for sharing structure; until then, we'll need to duplicate most changes.
ce0a43a
to
93b87ca
Compare
This push just expands on the comment in Dockerfile to clarify when the cache is refreshed, which helps explain its purpose. |
Pull #578 added support for build variants to support different features and
use cases, starting with aws-k8s and aws-dev. These variants use different
software, and therefore need different configuration. This change allows for
having a different API model (and default values) per variant.
The model was moved to workspaces/models. This crate actually contains the
model for each variant in separate subdirectories. Cargo's
build.rs
is usedto symlink in the proper source code before build.
The "proper" source code is chosen using the VARIANT environment variable. The
build system passes this through using the value of BUILDSYS_VARIANT, which is
set in the top-level Makefile.toml and can be overridden on the command-line.
For local cargo builds, the developer must set the VARIANT environment
variable; we don't currently want to choose a default model.
To start out, the aws-k8s and aws-dev models (and related default values) are
copies, with aws-dev having the Kubernetes-related values removed. The next
step is to figure out an appropriate method for sharing structure; until then,
we'll need to duplicate most changes.
Implementation notes:
SettingsResponse
structure, and update the related methods in apiserver, because it no longer owns theSettings
structure and so can't define traits on it. No change in behavior.Testing done:
All unit tests in
workspaces/
pass (for both aws-k8s and aws-dev variants).First, I built with the default
BUILDSYS_VARIANT
, resulting in an aws-k8s build, and launched it as an AMI.systemctl status
showedrunning
, it joined my Kubernetes cluster, and I launched a pod OK.Then I changed
BUILDSYS_VARIANT=aws-dev
, built, and launched it as an AMI.systemctl status
showedrunning
. I saw that I had the aws-dev variant's tooling, like ps, and no kubelet. I was able todocker run busybox
and see it download the image. It won't actually run yet, because we need to change the models so that containerd configuration is written out; it's currently undersettings.kubernetes
even though it's not k8s-specific. That will be a separate PR.