Master not Indicated

[codazoda]

Since it doesn't support working with a slave, it would be cool if the main interface showed some indication of which servers are master. Today, I have all 6 of my cluster members setup in Genghis and only one of them actually works (the master). That works for me, but when the master changes (something that happens often in my cluster) I have to guess which one is the new master. If the interface would show me which is master, that would be super cool!

[bobthecow]

That's a good idea. I imagine it might be better to indicate which servers are slaves. Something like this should do the trick?

[codazoda]

I think that would work perfectly.

[shaneodonnell]

I'd suggest that if you're adding this, you should support both Master-Slave (described here) and Replica Sets, especially since Replica Sets are the recommended replication topology.

If you're using the real estate to display its cluster member "stateStr" (or "state") (which I think is a GREAT idea -- I, too, struggle with this regularly), why not display it's actual status for all of the members? I think you could make the case that it might justify its own column. Make it narrow and elide the string in the lozenge if necessary?

I think UX best practices would prescribe that if you have a list and want to indicate that one member is different, decorate that member, not everything else. And if you're going to add a status for everything, put it in a column that's aligned and sortable so you can scan it easily and sort it if you need to.

Great idea! Sorry if this is scope-creeping the original request, but I'd be happy to help if I can.

Shane O.

On Sun, Jan 12, 2014 at 4:41 PM, Justin Hileman notifications@github.comwrote:

That's a good idea. I imagine it might be better to indicate which servers are slaves. Something like this should do the trick?

[image: mongo-slave]https://f.cloud.github.com/assets/53660/1897201/4dfcedee-7bd2-11e3-9241-1f2a8eec1541.png

— Reply to this email directly or view it on GitHubhttps://github.com/bobthecow/genghis/issues/153#issuecomment-32134964 .

[bobthecow]

@shaneodonnell Genghis already supports replica sets. localhost/?replicaSet=rs1

[bobthecow]

Or do you mean indicating what replica set each row is in?

[bobthecow]

I think UX best practices would prescribe that if you have a list and want to indicate that one member is different, decorate that member, not everything else.

Yep yep. That's why I'd prefer to mark the slaves (a decidedly less common occurance for most people) rather than the masters. And I'm using the "warning" state analogous to the "error" lozenge you'd see if you couldn't connect to a server for some reason. Occupying the same place, indicating that something's not quite awesome about this particular server.

[bobthecow]

@shaneodonnell Sorry, I read through your comment again and it makes more sense now :)

Why don't you open another issue as a feature request? It's related to this one, but I think this is more of a "Genghis won't be able to use this server like you want it to" so I'm leaning toward keeping that as a flag, as above. You could convince me otherwise though :)

[shaneodonnell]

The reason I thought this made sense as part of the same request is that -- at least in my environment -- any replica set member that is NOT the current PRIMARY will throw errors in Genghis and not end up where the user expected Genghis to take them.

So it makes sense to me that PRIMARY (in a replica set) would be the most important one to label. Your approach makes sense to me, but instead of using the losenge, I just wouldn't make the "non-primaries" a hyperlink.

Maybe my system is atypical, but this is what I get when I click on a SECONDARY member of my replica set:

https://www.dropbox.com/s/gh2kpiq3q1yb10i/Screenshot%202014-01-13%2007.03.45.png

And the alert-block persists on all ensuing pages until manually cleared.

I'm happy to make this an additional feature request, but I think this behavior (i.e., inability to tell if you're going to get an error until you get one) should be considered in the scope of this feature.

Shane O.

On Sun, Jan 12, 2014 at 11:25 PM, Justin Hileman notifications@github.comwrote:

@shaneodonnell https://github.com/shaneodonnell Sorry, I read through your comment again and it makes more sense now :)

Why don't you open another issue as a feature request? It's related to this one, but I think this is more of a "Genghis won't be able to use this server like you want it to" so I'm leaning toward keeping that as a flag, as above. You could convince me otherwise though :)

— Reply to this email directly or view it on GitHubhttps://github.com/bobthecow/genghis/issues/153#issuecomment-32144860 .

[shaneodonnell]

And after some further thought, let me muddy the waters a little more...and perhaps stumble on the reason why we have our current behavior in the first place.

Since Genghis isn't doing any sort of in-page refresh, if we were to add "SLAVE" in a 'label-important' lozenge (or denote its role in any way, like removing links from SECONDARY replica set members), you're denoting only a snapshot of those roles at the time of page load. If MASTER were to go down and the rs elects a new MASTER, that would not be reflected on the Genghis page without a refresh.

So today we indicate nothing and leave the user open to surprise, yet we propose to do something which could still leave the user open to surprise. I'd argue the approach we're discussing now significantly reduces the chances of surprising the user, but I'm sure there are cases where that isn't true.

You could refresh the status on a timer, but now this feature is getting significantly bigger. And I don't suppose that simply monitoring the state of the client connection would provide enough information to address the problem fully.

I don't know if any of this makes sense or not. Need more coffee...

Shane O.

On Mon, Jan 13, 2014 at 7:08 AM, Shane O. shaneodonnell@gmail.com wrote:

The reason I thought this made sense as part of the same request is that -- at least in my environment -- any replica set member that is NOT the current PRIMARY will throw errors in Genghis and not end up where the user expected Genghis to take them.

So it makes sense to me that PRIMARY (in a replica set) would be the most important one to label. Your approach makes sense to me, but instead of using the losenge, I just wouldn't make the "non-primaries" a hyperlink.

Maybe my system is atypical, but this is what I get when I click on a SECONDARY member of my replica set:

https://www.dropbox.com/s/gh2kpiq3q1yb10i/Screenshot%202014-01-13%2007.03.45.png

And the alert-block persists on all ensuing pages until manually cleared.

I'm happy to make this an additional feature request, but I think this behavior (i.e., inability to tell if you're going to get an error until you get one) should be considered in the scope of this feature.

Shane O.

On Sun, Jan 12, 2014 at 11:25 PM, Justin Hileman <notifications@github.com

wrote:

@shaneodonnell https://github.com/shaneodonnell Sorry, I read through your comment again and it makes more sense now :)

Why don't you open another issue as a feature request? It's related to this one, but I think this is more of a "Genghis won't be able to use this server like you want it to" so I'm leaning toward keeping that as a flag, as above. You could convince me otherwise though :)

— Reply to this email directly or view it on GitHubhttps://github.com/bobthecow/genghis/issues/153#issuecomment-32144860 .

[codazoda]

I don't mind the idea of disabling the links for all the slaves, after all, they aren't going to work.

I also like the "slave" pill idea because it reflects the fact that there is an error for that particular server (in Genghis' eyes, at least).

I don't personally think that the master changing since the page loaded is a significant enough occurrence to stop you from marking the slaves. Instead, maybe give a more reasonable error at the top of the page such as "Tried to connect to slave" instead of "Unknown error".

That would handle both use cases: First, it would mark the slaves so that the master can be easily identified; Second, it would notify you of the exact problem if you selected a slave after things had changed.

[bobthecow]

@shaneodonnell The server list does refresh every time you navigate back to it.

I could get on board with disabling links to slaves and secondary members, like we already do with server connection errors. That plus a "warning" lozenge to let people know why it's disabled would probably do the trick.

It would mean that if your replica set voted and the primary changed while you were on the server list, and you clicked through to the old primary, it would have an error on the next page. So we should also make sure that's more useful than the "unknown error" message :)