ui: Leader icon for node listing view

[johncowen]

This builds upon the leader icons that where added here #6021 but just ifed out temporarily.

It addresses one part of #5073 by showing the leader in the node listing using a star icon and tooltip for further clarification.

To note:

The endpoint we are using doesn't support blocking queries we had 3 choices here:

1. Everytime a blocking query for nodes resolves, immediately request the leader information again
2. Make a 'fake' blocking query for the status/leader endpoint on the frontend, by hardcoding a 'cursor' for this endpoint, and essentially make it poll.
3. Only request the leader information when the user enters the node listing page.

After talking to other in the team a while ago we went with point 3 here. On the basis that the leader doesn't update too often (potentially why the endpoint doesn't support blocking queries).

Potentially there is still a little work to do here, in that we may need to add something to cope with the state of consul when waiting for leader election. I thought it best to get eyes on this as soon as possible, and we can add any extra for this case ontop of here (either more commits or a PR ontop of this)

[johncowen]

Potentially there is still a little work to do here, in that we may need to add something to cope with the state of consul when waiting for leader election. I thought it best to get eyes on this as soon as possible, and we can add any extra for this case ontop of here (either more commits or a PR ontop of this)

Consul just responds with an empty string ("") when there is no elected leader so we added a straightforward test to cover that just to assert that nothing goes wrong with the UI. Visually we don't show anything extra for the moment when no leader has been elected.

[gregone]

Suggested change

	dc: dc,
	dc,

[johncowen]

Hey @gregone ,

Thanks for looking at this! I was thinking of merging without doing this suggestion, reasons being:

Most of the Consul UI codebase is ES5-y (think ember 2.18 timescales here, 2-3 years back), we generally don't do this kind of assignment (I think the only ES6-y thing we use is the Object.assign-like {...{}, ...{}} which was only because we preferred that to having to use the ember provided assign)

Other examples specifically in Repositories are:

consul/ui-v2/app/services/repository/token.js

Lines 27 to 30 in d848637

	.self(this.getModelName(), {
	secret: secret,
	dc: dc,
	})

consul/ui-v2/app/services/repository/session.js

Lines 12 to 15 in d848637

	const query = {
	id: node,
	dc: dc,
	};

consul/ui-v2/app/services/repository/proxy.js

Lines 13 to 16 in d848637

	const query = {
	id: slug,
	dc: dc,
	};

consul/ui-v2/app/services/repository/kv.js

Lines 27 to 29 in d848637

	const query = {
	id: key,
	dc: dc,

..but there are a few more around and about.

I can completely see where you are coming from, right now it's one of those consistency/context things. Once we get past ember 3.1* we'll think about moving up a notch, and if we do we'll probably skim the entire codebase in one go so everything is consistent.

Anyway, let me know what you think, happy to add this before merging if you feel strongly about it.

Thanks!

[johncowen]

Hey @gregone

We are going to try and get this into our next release, so I'm going to merge this without the suggestion, hope that's ok, thanks for reviewing!