-
Notifications
You must be signed in to change notification settings - Fork 316
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
RFE: In the template syntax, I want to know what topology a given service is in #4127
Comments
@irvingpop I've been in the templating code a fair bit lately, and have a lot of ideas for how we can improve things... some of those ideas are basically the last example you list here 😄 I've currently got #4823 in review, which lays the foundation for easily adding these kind of improvements in the future. |
awesome!! and looks like that merged, so I'll close this out. Thanks @christophermaier !!! |
Previously, determining the leader of a service group was complicated. If the service was running in a leader topology, the `{{bind.<BIND>.first}}` key would be the leader, but we didn't directly indicate if that was the case (you could have queried to see if `{{bind.<BIND>.first.leader}}` was `true`, but that leads to some needlessly verbose templates. Now, we introduce an explicit `leader` key, which will be non-null if the service group has a leader. Furthermore, the use of `first` is deprecated, since the meaning of it is not deterministic (it could be a non-alive member of the service group, for instance, which is not what anyone wants). The `first` key will remain in rendering contexts for the foreseeable future, but users are encouraged to use `{{bind.<BIND>.leader}}` if they want the leader, and `{{bind.<BIND>.members[0]}}` otherwise, pending future refactorings. Documentation is updated to reflect this, and a new `$deprecated` and `$since` key are used in our JSON Schema to indicate when an old field is deprecated, and when a new one is introduced. Our JSON Schema parser is configured to allow non-standard keywords like this through its processing, and this provides some additional hooks that a future automated documentation generator can use (see #4824) Fixes #4127 Signed-off-by: Christopher Maier <[email protected]>
Sorry @irvingpop... that PR just lays the foundation for this work, so I'm going to reopen this issue. That being said, the PR that does address this is going up in a minute 😄 |
Previously, determining the leader of a service group was complicated. If the service was running in a leader topology, the `{{bind.<BIND>.first}}` key would be the leader, but we didn't directly indicate if that was the case (you could have queried to see if `{{bind.<BIND>.first.leader}}` was `true`, but that leads to some needlessly verbose templates. Now, we introduce an explicit `leader` key, which will be non-null if the service group has a leader. Furthermore, the use of `first` is deprecated, since the meaning of it is not deterministic (it could be a non-alive member of the service group, for instance, which is not what anyone wants). The `first` key will remain in rendering contexts for the foreseeable future, but users are encouraged to use `{{bind.<BIND>.leader}}` if they want the leader, and `{{bind.<BIND>.members[0]}}` otherwise, pending future refactorings. Documentation is updated to reflect this, and a new `$deprecated` and `$since` key are used in our JSON Schema to indicate when an old field is deprecated, and when a new one is introduced. Our JSON Schema parser is configured to allow non-standard keywords like this through its processing, and this provides some additional hooks that a future automated documentation generator can use (see #4824) Fixes #4127 Signed-off-by: Christopher Maier <[email protected]>
Previously, determining the leader of a service group was complicated. If the service was running in a leader topology, the `{{bind.<BIND>.first}}` key would be the leader, but we didn't directly indicate if that was the case (you could have queried to see if `{{bind.<BIND>.first.leader}}` was `true`, but that leads to some needlessly verbose templates. Now, we introduce an explicit `leader` key, which will be non-null if the service group has a leader. Furthermore, the use of `first` is deprecated, since the meaning of it is not deterministic (it could be a non-alive member of the service group, for instance, which is not what anyone wants). The `first` key will remain in rendering contexts for the foreseeable future, but users are encouraged to use `{{bind.<BIND>.leader}}` if they want the leader, and `{{bind.<BIND>.members[0]}}` otherwise, pending future refactorings. Documentation is updated to reflect this, and a new `$deprecated` and `$since` key are used in our JSON Schema to indicate when an old field is deprecated, and when a new one is introduced. Our JSON Schema parser is configured to allow non-standard keywords like this through its processing, and this provides some additional hooks that a future automated documentation generator can use (see #4824) Fixes #4127 Signed-off-by: Christopher Maier <[email protected]>
Currently, you have at the time of template writing whether or not you're binding to a service that is in a topology (e.g.
leader
) or not. when writing your template, you either choose something like this for finding the leader:but if the service isn't in a topology,
member.leader
will always be false and instead users are instructed to rely on the@first
or@last
helpers. There's no way to detect if a given service is in a topology or not, so you have to know this in advance and that makes reuse difficult.Ideally, I would want to do something like this in my template:
or an even more terse way would be something like:
pie in the sky, but a "just do the right thing" pointer that would choose the leader the in a leader topology or any alive member at random in a non-leader topology would be the nicest from a user perspective
The text was updated successfully, but these errors were encountered: