Enhance the "grid/api/hub" response to include the list of nodes wired into the Hub as well

[krmahadevan]

Meta -

OS: Not Applicable

Selenium Version: 3.0.1

Browser: Not applicable

Browser Version:

Expected Behavior -

The response to grid/api/hub should contain the list of proxy ids that are currently wired into the Grid.

Actual Behavior -

This information is currently not present.

Steps to reproduce -

Currently the enhanced response to grid/api/hub exposes the total slots and currently running slots. It would be good to have it also expose the list of proxy ids (http://ip:port) that are wired into the hub along with this breakup

i.e., at a detailed level the response should provide the total slots and currently running slots per proxy id

[krmahadevan]

I will work on raising a PR for this.

[mach6]

@krmahadevan There has been talk in the past of adding/creating a RESTful api for the hub.

I see this request closer aligning with that effort. Perhaps I can persuade you to contribute your ask in this form?

Here is some examples of REST implementations that others have submitted in the past #191 #265

On that note, I have rebased #265 and made it work with Se 3.0.1. I have also made some minor tweaks w.r.t dependencies. Beyond that, I have not had that opportunity to complete the work.

Perhaps you'd like to pick it up? The branch/work is here -- https://github.com/mach6/selenium/tree/mach6_revive_265 .. I just updated/rebased it with the lastest upstream version of 'master'.

Also FYI - I started (did not complete) to document the existing hub apis here - https://gist.github.com/mach6/54ed6c8c0580a536468533fb8f4f1a56 -- In my opinion once created, a true REST api should look to replace some of these non-REST (or REST-ish) apis.

[krmahadevan]

@mach6 Thanks for your feedback on this. Had you not brought this up I would have gone ahead and raised yet another PR around this! I will take a look at your branch mach6_revive_265 to see what's left to be contributed.

In terms of the existing Hub APIs, I have already built a user facing library that would let a user consume the APIs. I have only exposed those APIs which I felt is really going to help the users, so I have conveniently chosen to ignore the registration APIs and the heartbeat APIs. The library (called talk2grid) is available on Maven central as well.

[krmahadevan]

@mach6 - I have wrapped up the implementation and raised a new PR #3460

[krmahadevan]

@mach6 - Let me know if #3460 is good to be merged or if it requires any additional changes.

[peepa]

@mach6 is this still valid? I can see the #3460 got closed without being merged 😞
I think the REST apis on grid would be really useful and am willing to help to get it done in case there is still interest.

[krmahadevan]

@peepa - Yes this is still an open ask. I had to close off on the PR because I wasn't moving forward with the PR. I can revive the PR, but only if there's a good chance that it would get vetted out and merged.

@shs96c - Please let me know your thoughts on this.

[mach6]

The topic of better REST api's for the grid keeps coming up. There will be changes. I'm basing them off of the PR mentioned.

[shs96c]

What should the URL space be for this information? I suggest the following:

GET /sessions -- list all open sessions (this already exists in the standalone server)
GET /grid/nodes --- list all grid nodes currently associated with this hub
POST /grid/nodes --- register a new node (alias of /grid/register)

I suspect we might want something to watch the new session queue (maybe not?) and I'm not sure whether or not we want something to get the Hub's config too.

Thoughts?

[krmahadevan]

@shs96c - Simon thanks for taking the time to respond back. The PR that I worked on enhancing (it was already created by someone a long time back), has the end-points as detailed in this comment #3460 (comment)

Please let me know if those are aligning with your expectations.

@mach6 - Is this something that you are planning on wrapping up, or do you need me to continue from where its left. I am hoping that we can wrap this up to closure at the earliest, because it really is a very valuable feature for the grid.

[peepa]

IMHO it would make sense to make all the routes related to grid API as /grid/api/<resource> (I would suggest using Accept headers for versioning instead of uri part - seems like lesser evil to me)
Why I believe this makes sense is because there are other routes, like grid/console which is not api-like and mixing them together looks like a mess to me.

[WesYoung91]

@krmahadevan @mach6

Has this officially died or is there an API still coming?

[krmahadevan]

@WesYoung91 - Well this is not going to be part of Selenium 3 for sure. You can perhaps expect something around these lines with Selenium 4 grid. That being said and done, the Grid's architecture by itself is going through a revamp. @shs96c has created a document around it and posted it on google drive. See here

Simon also took time to share some insights around it on the Selenium developers forum.

Please take a look at it here

Also I see the below set of issues/feature requests that talk about distributed tracing in Selenium 4.

#6680
#6681
#6679
#6663

[krmahadevan]

@diemol - Do you think you can help add this also as part of the Selenium 4 project ?