Migrate to schnauzer v2 for generated settings #3316
Conversation
cbgbt
force-pushed
the
schnauzer-generator-migrations
branch
from
5bfd8e7
to
d527cf1
Compare
|
^ I added a commit to this feature branch to enable GitHub workflows. |
cbgbt
force-pushed
the
schnauzer-generator-migrations
branch
2 times, most recently
from
02d5c8d
to
48d365b
Compare
cbgbt
force-pushed
the
schnauzer-generator-migrations
branch
from
48d365b
to
97b8ed4
Compare
| }, | ||
| ), | ||
| ( | ||
| "weird-extension@but_valid1.23(1, 2, 3)", |
There was a problem hiding this comment.
I don't feel strongly about this, but for CLI input I tend to avoid anything that might get mangled or misinterpreted if pasted into a prompt or script. Parens and whitespace jump out at me as slightly problematic.
Would something like weird-extension@but_valid1.23+1,2,3 ("add the 1, 2, and 3 helpers from this version of this extension") support the requirements?
There was a problem hiding this comment.
It should, though I'm conflicted. I've been thinking about this syntax since I submitted this PR.
The requires line is meant to basically replicate the functionality of frontmatter. One thing it doesn't do here is allow the optional = true field, which is probably fine; however, I don't want to be trapped in a corner of never being able to support it.
I've been thinking we may need something like extension@version(helpers=[helper1, helper2, ...]) so that we can add other named parameters if needed later. Of course, if the time comes, a regex would make for a terrible parser, but that's a bridge for another time.
In spite of all of this, we could probably still use different separators to avoid parens and whitespace, maybe something like:
extension@version+helpers:1,2,3+optional:true
What do you think?
There was a problem hiding this comment.
Hmm, on the other hand, it's extremely unlikely that the templates themselves will be CLI-friendly, they almost always contain whitespace and curly brace characters.
I'm erring on continuing to use the parens (I personally find it more readable) but adding the named arguments.
sources/api/schnauzer/src/lib.rs
Outdated
| //! to resolve references to settings extensions and the requested helpers. | ||
| //! | ||
| //! Most users will want to use `schnauzer::BottlerocketTemplateImporter`, which uses settings extensions to resolve | ||
| //! settings and helper data; however, custom `TemplateImporter` implementrations can be used as well. |
sources/api/schnauzer/src/lib.rs
Outdated
| //! schnauzer was originally written to render simpler templates which always had the full scope of Bottlerocket | ||
| //! settings and helper functions available to them, making it incompatible with the concept of Out-of-Tree Builds. | ||
| //! | ||
| //! The original schnauzer library deprecated, but continues to be made available under `schnauzer::v1` until it can |
cbgbt
force-pushed
the
schnauzer-generator-migrations
branch
from
97b8ed4
to
285d0a6
Compare
|
This change also uses a POSIX-shell-like lexer to tokenize setting-generators in sundog, rather than the previous approach of splitting on whitespace.
cbgbt
force-pushed
the
schnauzer-generator-migrations
branch
from
285d0a6
to
b667a91
Compare
|
cbgbt
merged this pull request
into
bottlerocket-os:ootb-settings-extensions
NOTE This is against the
ootb-settings-extensionfeature branch.Issue number:
#3133
Description of changes:
This change uses the new
schnauzer::v2template renderer to replace all template-based settings generators in Bottlerocket.Specifically, it:
schnauzer-v2settings generator binaryschnauzer-based settings generators to useschnauzer-v2Thoughts on Migrations
We overwrite the existing
setting-generatorforschnauzer-based generators, but leave thetemplatesintact in the API for existing customers. This should enable rollbacks to succeed. Since the new setting generator is semantically identical to the previous one, we don't need to re-render the settings.What's Still Missing
See #3133 for the list of tasks to complete this migration.
Testing done:
aws-k8sandaws-ecsvariantsTerms 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.