search

osrf / cloudsim-widgets

Other
0 stars 1 forks source link

Improve cs-serverstatus #12

Open osrf-migration opened 8 years ago

osrf-migration commented 8 years ago

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Currently cs-serverstatus only displays the links of predefined servers:

serverstatus.png

Some desired improvements:

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Removing server status from default branch for now, pull request #130

osrf-migration commented 7 years ago

Original comment by Andrés Fortier (Bitbucket: andres_fortier).

@chapulina could you expand a bit on the first bullet? It is not clear to me who the user is (i.e. end user or admin) and how he/she should provide the server(s) (by code, configuration or input field?). Also, the idea would be to have an array of pairs (server name, url), right? Sorry if these are obvious questions, still ramping-up on the system :).

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Oh no problem, the issue description is not very informative as is it.

The previous implementation of cs-serverstatus just displayed a hardcoded list of links to servers (auth and portal). The admin would click on those links and a new tab would be opened, if the server is running, you'd see something like this, otherwise, the browser would say it can't get to the server.

Another use case for this component is for the SRC. It would be great to get rid of the instructions under "Important: You must wait until both machines are provisioned" described here.

It would be much more convenient to have some indicator, something like a green / red icon, to display whether the server is online without requiring the user to open a new tab and keep refreshing until the server comes up.

I don't think accepting an array would be necessary anymore, if we need to keep track of multiple servers, we can just instantiate the same component several times.

I imagine the component being used like this for example:

<cs-serverstatus 
  url="[[machine_ip]]" 
  online={{serveronline}}
>
</cs-serverstatus>

<paper-button
   disabled$=[[!serveronline]]
>
  Launch
</paper-button>
osrf-migration commented 7 years ago

Original comment by Andrés Fortier (Bitbucket: andres_fortier).

Got it, thanks!

osrf-migration commented 7 years ago

Original comment by Germán Más (Bitbucket: Germán Más, GitHub: german-e-mas).

@chapulina , I noticed that in the PR where the Server Status was removed (here), if I understand correctly, the profile element needed the current user and the Server Status was only being displayed to Admins.

Do we want to make that distinction or should the Server Status be available for all? Are the participant teams considered as Admins?

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Hi @german-e-mas , I don't feel strongly either way, I think it's fine to show the status of the cloudsim servers (auth, portal and keys) on every user's profile page.

It would be nice if this component could be reused on the SRC kiosk to display the status of the simulator and field computer machines.

osrf-migration commented 7 years ago

Original comment by Germán Más (Bitbucket: Germán Más, GitHub: german-e-mas).

Where can I get the status of the Keys Server? The profile element only knows of Auth and Portal servers, so I can't bind to it. Should I use a hardcoded URL or pass a "keysurl" value on the Profile?

osrf-migration commented 7 years ago

Original comment by Germán Más (Bitbucket: Germán Más, GitHub: german-e-mas).

As @chapulina suggested, the element can be reused. It requires an URL and shows it's status. Should including it into the SRC Kiosk be part of CLOUD-73, or as a separated task?

The status of the machines should be checked inside the rounds and using the machine_ip? This status should be place below the Machine, or the Practice boxes?

What do you think @preyna, @iche033, @andres_fortier ?

3141748960-cstutorial.png

osrf-migration commented 7 years ago

Original comment by Patricio Reyna Almandos (Bitbucket: Patricio Reyna Almandos, GitHub: patricioreyna).

Hey @german-e-mas , good questions! Let me try adding my 2cts.

Regarding creating a separate task when including the serversstatus into SRC constellation screen, yes, feel free to create a separate task. That will help us better track the work.

Regarding where to place it in the SRC screen, I would replace this block with serverstatus component.

#!html

                  <span class="property">Public IP</span>
                  <div class="space"></div>
                  <a target="_blank" href="http://[[rounddata.simulator.data.machine_ip]]:[[simPort]]">
                    <span class="value noellipsis">[[rounddata.simulator.data.machine_ip]]</span>
                  </a>

Regarding machine_ip , yes, and you should use machine Port as well. Look at the block of code above for an example.

Btw, it would seem you have an outdated codebase. In the lastest SRC UI , just to the right of the Public IP you can see a copy to clipboard icon. (do a hg pull && hg up in your default branch to get the latest changes)

HTH!

osrf-migration commented 7 years ago

Original comment by Germán Más (Bitbucket: Germán Más, GitHub: german-e-mas).

Thank you @patricioreyna ! I added a new issue: CLOUD-94, as it would be better to divide the PRs. It is currently blocked by this task, as there is no server status element yet, but I'm about to do the PR.

The screenshot of the Kiosk is the one in the wiki. Should we keep track of the changes and update these screenshots?

osrf-migration commented 7 years ago

Original comment by Patricio Reyna Almandos (Bitbucket: Patricio Reyna Almandos, GitHub: patricioreyna).

Thanks Ger ! Dont worry about the screenshot for now.