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

RFE: In the template syntax, I want to know what topology a given service is in #4127

Closed
irvingpop opened this issue Nov 27, 2017 · 4 comments
Labels
Documentation Flags an issue / PR for attention by the technical documentation team Focus:Supervisor Related to the Habitat Supervisor (core/hab-sup) component Type: Feature Issues that describe a new desired feature
Milestone

Comments

@irvingpop
Copy link

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:

{{~ #if bind.database}}
  {{~ #eachAlive bind.database.members as |member|}}
    {{~ #if member.leader}}
PGHOST="{{member.sys.ip}}"
    {{~ /if}}
  {{~ /eachAlive}}
{{~ /if}}

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:

{{~#if bind.database}}
  {{~#if bind.database.topology?}}
     {{~#findLeader bind.database.members as |member|}}
       PGHOST="{{member.sys.ip}}"
     {{~/findLeader}}
  {{else}}
     # loop through via #eachAlive
  {{~/if}}
{{~/if}}

or an even more terse way would be something like:

  {{~#if bind.database.topology?}}
     PGHOST={{bind.database.leader.sys.ip}}
  {{else}}
  {{~/if}}

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

@eeyun eeyun added this to the Help Wanted milestone Nov 28, 2017
@tashimi
Copy link
Contributor

tashimi commented Nov 28, 2017

@eeyun looks like this may help, perhaps add context from @robbkidd's suggestion in triage #4113

@christophermaier
Copy link
Contributor

@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.

@irvingpop
Copy link
Author

awesome!! and looks like that merged, so I'll close this out. Thanks @christophermaier !!!

christophermaier added a commit that referenced this issue Mar 29, 2018
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]>
@christophermaier
Copy link
Contributor

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 😄

christophermaier added a commit that referenced this issue Apr 9, 2018
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]>
christophermaier added a commit that referenced this issue Apr 12, 2018
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]>
@christophermaier christophermaier added Focus:Supervisor Related to the Habitat Supervisor (core/hab-sup) component Type: Feature Issues that describe a new desired feature and removed A-supervisor labels Jul 24, 2020
@christophermaier christophermaier added Documentation Flags an issue / PR for attention by the technical documentation team and removed A-documentation labels Aug 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation Flags an issue / PR for attention by the technical documentation team Focus:Supervisor Related to the Habitat Supervisor (core/hab-sup) component Type: Feature Issues that describe a new desired feature
Projects
None yet
Development

No branches or pull requests

4 participants