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.

Sign up for GitHub

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

Jump to bottom

Consul version of each nodes in UI nodes section #17097

Closed
Lord-Y opened this issue Apr 24, 2023 · 13 comments · Fixed by #17754
Closed

Consul version of each nodes in UI nodes section #17097

Lord-Y opened this issue Apr 24, 2023 · 13 comments · Fixed by #17754
Assignees
@vijayraghav-io
Labels
theme/ui Anything related to the UI

Comments

@Lord-Y
Copy link
Contributor

Lord-Y commented Apr 24, 2023

Hello guys,

It very useful to have the Consul version of each nodes in UI nodes section next to the IP address.
When doing a rolling upgrade or having federeted setup, I feel like we need that.

Thx.
@huikang huikang added the theme/ui Anything related to the UI label Apr 24, 2023
@vijayraghav-io
Copy link
Contributor

@huikang can you please assign this to me

@vijayraghav-io
Copy link
Contributor

vijayraghav-io commented Jun 13, 2023 •
edited
Loading

@huikang @jkirschner-hashicorp

Please find below snapshot of proposed solution for showing consul version running on each nodes.
Approach is to get consul version on each node using RPC. Dev is in progress.

PropSoln_ConVer

FYI @Lord-Y

@Lord-Y
Copy link
Contributor Author

Lord-Y commented Jun 13, 2023

@vijayraghav-io That's good 👍🏾

@vijayraghav-io vijayraghav-io mentioned this issue Jun 15, 2023
Merged
@cizh
Copy link

cizh commented Jun 16, 2023

Hello @Lord-Y, thank you for raising this up, and thank you @vijayraghav-io for the proposal. This is all valuable to us. I’m Cindy Zhang, one of the product designers at Consul. We’re excited to receive this request and are curious to learn more about the use case behind this request. Depending on the use case you want addressed, the design proposed by @vijayraghav-io may be the ideal way, but there may also be alternative ways that are more helpful. For example, perhaps it would be more helpful to have an aggregated view of the range of versions you’re currently running on your nodes and a way to digest that information. Again, it all depends on the use case(s).

In light of this, I would like to invite you to a meeting with us to discuss how Consul can best assist you use our product in relation to the agent versions. Please feel free to use this link to choose any time that is most convenient for you: https://calendly.com/cindy-zhang-6dy/30min

We understand if you don’t have time for a meeting, but we would nonetheless appreciate some context for the following questions:

  1. Can you tell me about what you were trying to accomplish that was hindered by the absence of the version info in the GUI today?
  2. In what other scenarios would having version information be useful to you? How would that info inform your decisions?
  3. How frequently do you encounter these use scenarios where knowing the nodes’ Consul version from the GUI is advantageous?

@vijayraghav-io
Copy link
Contributor

vijayraghav-io commented Jun 17, 2023 •
edited
Loading

Hi @cizh
Thanks for your reply!
The use case may be - For admins/users to have a quick snapshot view of consul versions running on all nodes (especially it really helps when there are large number of nodes in cluster). This may also help in decision making during upgrades. @Lord-Y can add more additional details for the use case.

Other use cases:
The idea to display consul version in node list page, is to have ability to filter nodes based on version. Also to have sorting ability "New to older" similar to "Healthy to UnHealthy" sort. This also provides a aggregated view.
Filtering and sorting can also be implemented in this PR

@cizh
Copy link

cizh commented Jun 17, 2023

My pleasure! @vijayraghav-io Help me further understand "decision making during upgrades". Which of the statement(s) below is/are accurate for you? Are there ones that are not captured?

If I have a large number of nodes in a cluster, seeing the consul versions they run on will help me to skim and say:

  1. "I have a few nodes running on outdated versions, and I should upgrade them soon."
  2. "I have enough nodes running on the latest versions; therefore, I don't need to worry about upgrading the older ones."
  3. "I need to perform an action but I know that's not supported by version 1.1x and older, so let me check my nodes' version first before implementation (so I can avoid troubleshooting later on)."

@vijayraghav-io
Copy link
Contributor

vijayraghav-io commented Jun 17, 2023 •
edited
Loading

Thank you! @cizh , All three statements are best fit, 1 & 3 are more accurate to me.

@vijayraghav-io
Copy link
Contributor

Hi @cizh

Here is proposed design and implementation of version search with filter. PR

Screenshot 2023-06-22 at 1 02 09 PM

This provides a aggregated view w.r.t versions.
The filter dropdown lists current and two previous minor versions (dynamically), this as per doc.
... (3 dots in menu ) -> lists all other/older versions if any.

@Lord-Y
Copy link
Contributor Author

Lord-Y commented Jun 22, 2023

That's even better.

@vijayraghav-io
Copy link
Contributor

👍

@cizh
Copy link

cizh commented Jun 26, 2023 •
edited
Loading

(copy-pasting my response from the PR here for syncing)
image

Hi @vijayraghav-io Please see above for a mockup with "filter" function: after discussion with @jkirschner-hashicorp, we decided displaying all of the user's current versions in the filter options would make the logic more clear to users. Although it'll be great UX if we can digest for our users in "latest" "outdated" and "out-of-support", at this time, the number is the least confusing because some versions may be compatible with much earlier versions but not the latest so we can't precisely say they are out of support.
Here is a mockup for "sort" function that we would recommend if you have the time and the want to build it.
Screenshot 2023-06-23 at 4 54 44 PM

@vijayraghav-io
Copy link
Contributor

vijayraghav-io commented Jun 27, 2023 •
edited
Loading

Hi @cizh , as an update - I am working on this , should be ready to review in a couple of days. Will update. Thanks! for the mock-up.

@vijayraghav-io
Copy link
Contributor

vijayraghav-io commented Jun 29, 2023 •
edited
Loading

Hi @cizh - PR is ready for review.
Consul version are displayed for all nodes, both sorts and filters for versions are implemented.

Screenshot 2023-06-29 at 10 23 12 PM Screenshot 2023-06-29 at 10 21 59 PM

Merged
jmurret added a commit that referenced this issue Jul 17, 2023
@hc-github-team-consul-core @vijayraghav-io
@jmurret @jkirschner-hashicorp
Backport of Displays Consul version of each nodes in UI nodes section…
6ed2c23 
… into release/1.16.x (#18113)

## Backport

This PR is auto-generated from #17754 to be assessed for backporting due
to the inclusion of the label backport/1.16.


:rotating_light:
>**Warning** automatic cherry-pick of commits failed. If the first
commit failed,
you will see a blank no-op commit below. If at least one commit
succeeded, you
will see the cherry-picked commits up to, _not including_, the commit
where
the merge conflict occurred.

The person who merged in the original PR is:
@WenInCode
This person should manually cherry-pick the original PR into a new
backport PR,
and close this one when the manual backport PR is merged in.

> merge conflict error: unable to process merge commit:
"1c757b8a2c1160ad53421b7b8bd7f74b205c4b89", automatic backport requires
rebase workflow



The below text is copied from the body of the original PR.

---

fixes #17097 Consul version of each nodes in UI nodes section

@jkirschner-hashicorp @huikang @team @maintainers

Updated consul version in the request to register consul.
Added this as Node MetaData.
Fetching this new metadata in UI

<img width="1512" alt="Screenshot 2023-06-15 at 4 21 33 PM"
src="https://github.com/hashicorp/consul/assets/3139634/94f7cf6b-701f-4230-b9f7-d8c4342d0737">

Also made this backward compatible and tested.

Backward compatible in this context means - If consul binary with above
PR changes is deployed to one of node, and if UI is run from this node,
then the version of not only current (upgraded) node is displayed in UI
, but also of older nodes given that they are consul servers only.
For older (non-server or client) nodes the version is not added in
NodeMeta Data and hence the version will not be displayed for them.
If a old node is consul server, the version will be displayed. As the
endpoint - "v1/internal/ui/nodes?dc=dc1" was already returning version
in service meta. This is made use of in current UI changes.

<img width="1480" alt="Screenshot 2023-06-16 at 6 58 32 PM"
src="https://github.com/hashicorp/consul/assets/3139634/257942f4-fbed-437d-a492-37849d2bec4c">




---

<details>
<summary> Overview of commits </summary>

- 931fdfc -
b3e2ec1 -
8d0e9a5 -
04e5d88 -
28286a2 -
43e50ad -
0cf1b70 -
27f34ce -
2ac76d6 -
3d618df -
1c757b8 -
23ce82b -
4dc1c9b -
85a12a9 -
25d30a3 -
7f1d619 -
5174cbf

</details>

---------

Co-authored-by: Vijay Srinivas <vijayraghav22@gmail.com>
Co-authored-by: John Murret <john.murret@hashicorp.com>
Co-authored-by: Jared Kirschner <85913323+jkirschner-hashicorp@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vijayraghav-io vijayraghav-io

Labels
theme/ui Anything related to the UI
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Displays Consul version of each nodes in UI nodes section vijayraghav-io/consul
4 participants
@huikang @vijayraghav-io @Lord-Y @cizh