-
-
Notifications
You must be signed in to change notification settings - Fork 15
Merge typed role and role group configs #425
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
Closed
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6 tasks
nightkr
added a commit
that referenced
this pull request
Jul 5, 2022
A slightly different take of #425, which uses the existing Atomic infra and some trait magic to determine "complex" types. It also tries to provide nice error messages for validation failures.
5 tasks
will be handeld with a different approach by @teozkr. Closing for now. |
bors bot
pushed a commit
that referenced
this pull request
Oct 17, 2022
## Description This is an alternate take on #425. Essentially, we define a new macro `Fragment`, which creates a "parallel fragment universe" where everything is optional. For example, given the following types: ```rust #[derive(Fragment)] struct Outer { foo: u32, inner: Inner, } #[derive(Fragment)] struct Inner { required: String, optional: Option<String>, } ``` we generate the following fragment variants: ```rust struct OuterFragment { foo: Option<u32>, inner: InnerFragment, // not an atomic type, so make every subfield optional instead } struct InnerFragment { required: Option<String>, // was non-optional, so make it optional optional: Option<String>, // was already optional, so preserve the type } ``` as well as validation functions that turn `OuterFragment` into `Result<Outer>` (and an equivalent for `Inner`), while giving us the full context when a validation error occurs. This allows us to safely deserialize and merge the fragment variants, and only afterwards validate that all required options are present in the final merged configuration. This is a pretty big and breaking change, since it moves all `Serialize` and `Deserialize` impls on the resources into the fragment variants. Co-authored-by: Teo Klestrup Röijezon <teo.roijezon@stackable.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR adds a macro
Optional
that must be used in the FooConfig(s) of our operators.The two created Configs are contained in the CommonConfiguration in an enum like:
The Optional part representing OptionalFooConfig will be exposed in the CRD. After deserilization and merging the operators work with the Merged part containing the original FooConfig. To retrieve the "original" merged FooConfig in the code, a
get
method must be called. This is breaking as well as the new Role parametrization:This means we now need to configure our Role in the FooClusterSpec like:
Additionally, the Role and RoleGroup have a custom deserializer that merges the Role and RoleGroups OptionalFooConfig including the defaults. That means after deserialization no other merging has to be done.
FYI: It works with ZooKeeper, im not fully happy with the created macro which still has some flaws (e.g. the derives of the OptionalFooConfig are currently hardcoded). There are still alot of clones in the code which i wasnt able yet to remove. Additionally, the merge is not working yet for complex structs. They are Optional in the OptionalFooConfig and due to the Merge trait need an impl for Atomic (which basically stops the merge and just takes whatever is behind the option).
@teozkr I really need you to have a look at the general idea/structure and especially the macro :)
Operator implementation: stackabletech/zookeeper-operator#508
fixes: #284
Review Checklist
Once the review is done, comment
bors r+
(orbors merge
) to merge. Further information