Giter VIP home page Giter VIP logo

cloudsim-widgets's People

Contributors

caguero avatar chapulina avatar gerkey avatar german-e-mas avatar iche033 avatar patricioreyna avatar sloretz avatar tfoote avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

muskanmahajan37

cloudsim-widgets's Issues

[SASC] Improve user experience fetching resources by exposing tokens from command line tools

Original report (archived issue) by Tully Foote (Bitbucket: Tully Foote, GitHub: tfoote).

Using the tokens we can allow the user to pull resources directly from cloudsim. In particular they can get the vpn tokens, ssh keys, and appropriate addresses for the machines.

What would be great if for each role, team blue, team gold, and game master, there were a few generated command line invocations that could be copy and pasted to set things up.

The users will still need to have the sasc package installed so we can rely on that, but from that we could have.

/opt/sasc/setup_blue_networking.py --token XXXXXXXXX --round-id XYZXYZ --vpn-config 0 which can pull the appropriate resources, such as the vpn config and ssh key and setup the vpn.

The gold team would have an equivalent command.

And so would the game master (no need for the vpn here, but it would need the IP address of the arbiter machine.

The main thing is that the generated options need to have enough information for the script to pull all the needed resources by url using the authorization token. I've sketched above what I think is necessary, but if there are more arguments needed that's fine.

SASC: Rebooting payload machine doesn't work

Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).

The original report had attachments: syslog.zip

After a sudo reboot, and the machine never came back up. we were pinging both locally on our machine over vpn and from the arbiter machine, no response.

Note:
AWS machines normally come back online after a reboot, so this may be related to the VPN setup.

Mixed content

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

The sim servers are http, so we get mixed content errors when trying to GET /simulations. I believe this also causes the rest of the page to be loaded weirdly, the + button disappears and the other machine items have the wrong style:

mixedcontent.png

Problem with install instructions and permissions

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

  1. Running npm install -g gulp bower gave me permission denied errors, so I had to run with sudo

  2. After that, running npm install went through but had a lot of warnings about unmet dependencies:

    npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/browser-sync requires socket.io@'1.4.5' but will load
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/socket.io,
npm WARN unmet dependency which is version 1.4.6

npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/socket.io/node_modules/engine.io/node_modules/engine.io-parser requires has-binary@'0.1.6' but will load
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/socket.io/node_modules/has-binary,
npm WARN unmet dependency which is version 0.1.7
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/gulp/node_modules/gulp-util/node_modules/dateformat/node_modules/meow requires object-assign@'^4.0.1' but will load
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/gulp/node_modules/gulp-util/node_modules/object-assign,
npm WARN unmet dependency which is version 3.0.0
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/gulp/node_modules/vinyl-fs/node_modules/mkdirp requires minimist@'0.0.8' but will load
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/gulp/node_modules/minimist,
npm WARN unmet dependency which is version 1.2.0
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/gulp-minify-css/node_modules/gulp-util requires object-assign@'^3.0.0' but will load
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/gulp-minify-css/node_modules/object-assign,
npm WARN unmet dependency which is version 4.1.0
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/gulp-minify-html/node_modules/gulp-util requires through2@'^2.0.0' but will load
npm WARN unmet dependency /home/louisep/code/cloudsim-widgets/node_modules/gulp-minify-html/node_modules/through2,
npm WARN unmet dependency which is version 0.6.5
```

  1. bower install also required sudo to install, like this: sudo bower install --allow-root. Alternatively, I just changed the permissions of a config file as follows: sudo chown louisep:louisep -R ~/.config/configstore/ and it worked without sudo.

Check permissions for identities

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

If a machine is shared "read only" with a group, individual users within that group will see "write" options, even though they can't be used.

The problem is how we get currentreadonly in cs-machinelist

SASC: too many refreshes under the hood

Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).

The following info shows the result of the node log tail -f /var/log/nodejs/nodejs.log that result from user interaction on the sasc kiosk.

The log format could be better (there's a response time but no date, I will be fixing that shortly). In general, these calls are often happening one after the other.

user action: CREATE ROUND

#!js


GET /simulators 304 12.488 ms - -
POST /sshkeys 200 256.805 ms - 142
POST /sshkeys 200 320.034 ms - 139
GET /simulators 304 12.907 ms - -
POST /sshkeys 200 353.561 ms - 139
POST /permissions 200 39.372 ms - 206
GET /simulators 304 9.336 ms - -
POST /permissions 200 19.820 ms - 206
POST /permissions 200 18.758 ms - 206
GET /simulators 304 9.247 ms - -
GET /simulators 304 9.233 ms - -
GET /simulators 304 9.196 ms - -
GET /simulators 304 9.284 ms - -
GET /simulators 304 9.177 ms - -
GET /simulators 304 9.315 ms - -
GET /simulators 304 9.248 ms - -
GET /simulators 304 9.221 ms - -
GET /simulators 304 10.602 ms - -
GET /simulators 304 9.220 ms - -
GET /simulators 304 9.309 ms - -
GET /simulators 304 9.258 ms - -
GET /simulators 304 10.347 ms - -
GET /simulators 304 9.237 ms - -
GET /simulators 304 10.039 ms - -
GET /simulators 304 9.239 ms - -
GET /simulators 304 9.257 ms - -
GET /simulators 304 9.235 ms - -
GET /simulators 304 9.287 ms - -
GET /simulators 304 9.270 ms - -
GET /simulators 304 11.124 ms - -
GET /simulators 304 9.584 ms - -
GET /simulators 304 9.264 ms - -
GET /simulators 304 9.321 ms - -
GET /simulators 304 9.637 ms - -
GET /simulators 304 9.217 ms - -
GET /simulators 304 11.172 ms - -
GET /simulators 304 9.258 ms - -
GET /simulators 304 9.231 ms - -
GET /simulators 304 9.289 ms - -
GET /simulators 304 9.241 ms - -
GET /simulators 304 9.232 ms - -
GET /simulators 304 10.309 ms - -
GET /simulators 304 9.191 ms - -
GET /simulators 304 9.188 ms - -
GET /simulators 304 9.188 ms - -
GET /simulators 304 9.314 ms - -
GET /simulators 304 12.694 ms - -
GET /simulators 304 13.445 ms - -
GET /simulators 304 12.273 ms - -
GET /simulators 304 13.305 ms - -
GET /simulators 304 12.694 ms - -
GET /simulators 304 12.812 ms - -
GET /simulators 304 12.592 ms - -
GET /simulators 304 14.702 ms - -
GET /simulators 304 12.235 ms - -

user action: LAUNCH ARBITER

#!js


Launching simulator
- region:us-west-1
- SSH key: sshkey-051
- hardware: c4.xlarge
- security: cloudsim-sim
- image: ami-fe99c49e
- tags: { Name: '[email protected]' }
- script size:2922

GET /simulators 200 9.912 ms - 263977
GET /simulators 304 11.639 ms - -
GET /simulators 304 9.232 ms - -
GET /simulators 304 9.223 ms - -
GET /simulators 304 9.324 ms - -
simulator-524 launch!
POST /simulators 200 1984.546 ms - 1294
GET /simulators 200 9.378 ms - 263996
POST /permissions 200 18.453 ms - 212
GET /simulators 200 10.771 ms - 264093
GET /simulators 304 9.283 ms - -
GET /simulators 304 9.261 ms - -
GET /simulators 304 9.327 ms - -
GET /simulators 304 12.920 ms - -
GET /simulators 304 13.494 ms - -
GET /simulators 304 12.214 ms - -
GET /simulators 304 13.546 ms - -
GET /simulators 304 12.647 ms - -
simulator-524 ip: 54.219.161.136
GET /simulators 200 21.153 ms - 264107
GET /simulators 304 9.461 ms - -
GET /simulators 304 9.360 ms - -
GET /simulators 304 9.362 ms - -
GET /simulators 304 9.320 ms - -
i-082a967da8761cf10 simulator-524 status update LAUNCHING => RUNNING
GET /simulators 200 9.322 ms - 264105
GET /simulators 304 9.281 ms - -
GET /simulators 304 12.866 ms - -
GET /simulators 304 12.844 ms - -
GET /simulators 304 12.266 ms - -

user action LAUNCH ALL BLUE PAYLOADS (1 machine):

#!js

Launching simulator
- region:us-west-1
- SSH key: sshkey-050
- hardware: m4.xlarge
- security: cloudsim-sim
- image: ami-fe99c49e
- tags: { Name: '[email protected]' }
- script size:3139

GET /simulators 200 15.681 ms - 265583
GET /simulators 304 14.949 ms - -
GET /simulators 304 14.345 ms - -
GET /simulators 304 14.593 ms - -
GET /simulators 304 12.648 ms - -
simulator-525 launch!
POST /simulators 200 1601.495 ms - 1377
GET /simulators 200 9.608 ms - 265602
POST /permissions 200 20.639 ms - 212
GET /simulators 200 9.538 ms - 265699
GET /simulators 304 9.431 ms - -
GET /simulators 304 10.168 ms - -
GET /simulators 304 14.714 ms - -
GET /simulators 304 12.828 ms - -
GET /simulators 304 12.323 ms - -
GET /simulators 304 14.306 ms - -
GET /simulators 304 13.000 ms - -
GET /simulators 304 13.024 ms - -
simulator-525 ip: 54.215.249.247
GET /simulators 200 9.548 ms - 265713
GET /simulators 304 9.353 ms - -
GET /simulators 304 10.784 ms - -
GET /simulators 304 9.265 ms - -
GET /simulators 304 9.301 ms - -
/tmp/cloudsim.pem written
cd /tmp && chmod 600 cloudsim.pem  && zip keys.zip cloudsim.pem
"/tmp/keys.zip" downloaded
GET /sshkeys/sshkey-051 200 12.389 ms - 1461
i-0343d9269bf8d878e simulator-525 status update LAUNCHING => RUNNING
GET /simulators 200 13.293 ms - 265711
GET /simulators 304 14.757 ms - -
GET /simulators 304 13.586 ms - -
GET /simulators 304 13.128 ms - -
GET /simulators 304 13.986 ms - -

user action: FINISH ROUND

#!js

    
simulator-525 terminate
DELETE /simulators/simulator-525 200 348.881 ms - 1618
DELETE /sshkeys/sshkey-051 200 358.669 ms - 16
DELETE /sshkeys/sshkey-050 200 304.737 ms - 16
simulator-526 terminate
DELETE /simulators/simulator-526 200 414.985 ms - 1615
simulator-524 terminate
DELETE /simulators/simulator-524 200 428.941 ms - 1535
DELETE /sshkeys/sshkey-052 200 245.215 ms - 16
GET /simulators 200 15.907 ms - 267353
GET /simulators 304 14.044 ms - -
GET /simulators 304 13.680 ms - -
GET /simulators 304 13.499 ms - -
GET /simulators 304 13.370 ms - -
GET /simulators 304 12.929 ms - -
GET /simulators 304 15.622 ms - -
GET /simulators 304 12.749 ms - -
GET /simulators 304 23.604 ms - -
GET /simulators 304 9.495 ms - -
GET /simulators 304 9.300 ms - -
GET /simulators 304 9.438 ms - -
GET /simulators 304 9.541 ms - -
GET /simulators 304 10.968 ms - -
GET /simulators 304 9.440 ms - -
GET /simulators 304 12.807 ms - -
GET /simulators 304 12.997 ms - -
GET /simulators 304 13.403 ms - -
GET /simulators 304 14.202 ms - -
GET /simulators 304 13.063 ms - -
GET /simulators 304 13.229 ms - -
GET /simulators 304 12.776 ms - -
GET /simulators 304 12.475 ms - -
GET /simulators 304 13.072 ms - -
GET /simulators 304 27.744 ms - -
GET /simulators 304 11.049 ms - -
GET /simulators 304 10.694 ms - -
GET /simulators 304 10.774 ms - -
GET /simulators 304 11.166 ms - -
GET /simulators 304 10.739 ms - -

If you eliminate a few refreshes (launching->running, find the ip), there are still a lot of unnecessary calls. Also, these calls used to be very slow (when the database was on a t2.micro).

Because we are using REST, PUT calls contain the whole state for each update, and the database incurs many writes.

The problem may be due to:

  • too many updates (each update triggers a refresh of the whole collection)
  • a websocket error (multiple updates per connected client)

Solutions may include:

  • delaying a refresh for a time, to collapse many refreshes into "one at most 0.x seconds")
  • reducing the round data updates
  • look for a problem in the "data binding callbacks"

machinekillbutton lies about killing machines

Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).

The code assumes success.

#!python

 onKilled: function(e) {
        this.fire('notification',
            {msg: "Machine has been killed.", type: "msg"})
      },

e.detail.success can be false, with a message in: e.detail.msg

Also, the button appears when it shouldn't (after a revoke)

SASC: Add VPN keyword to ocu keys download menu/button

Original report (archived issue) by Tully Foote (Bitbucket: Tully Foote, GitHub: tfoote).

I had a user report that the keys didn't have openvpn.conf but they were looking at the ssh keys only. And not downloading the OCU Keys.

"OCU VPN Keys" would be great for the label.

It might be clearer to label the Keys with SSH Key too here:

cloudsim-widgets/app/elements/cs-downloadkeysbutton/cs-downloadkeysbutton.html

Line 24 in 5ef994a

Keys

I couldn't find the location for the OCU download UI element.

SASC Kiosk 503 errors updating widget backend

Original report (archived issue) by Tully Foote (Bitbucket: Tully Foote, GitHub: tfoote).

I was launching blue payloads and got 503s trying to update the widget backend.

error_updating sascround-181 503.png

Opening it in another tab the state is different.

inconsistent state.png

However after launching the Gold payloads the full state appears to have recovered. The widgets backend seemed to have a momentary hiccup.

Sort out the role of each branch

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

The way our branches are organized is a bit messy. Currently we have:

production -> deployed to https://cloudsim.io

This is the version which gets to the final users.

default -> deployed to https://dev.cloudsim.io

This is being used in two different ways:

  1. It has experimental features which are not ready to be rolled into production, such as SRC and ARIAC.

  2. It has features which we want to try before rolling into production, like bug fixes.

The reason for the two uses is mostly historical. Before production existed, default was a place for everything which has been peer reviewed.

But the fact that default has things which are not being tested to be rolled into production means we can't just merge default into production when we know things are working. So we have to cherry-pick changes which will go into production.

Note that this is a problem only for the widgets server. Portal, auth and keys all have default and production branches in sync, so default is only being used for #2 above and can be merged directly into production.

I'd like to propose we clean default and remove anything which is currently not being considered to go into full production (mainly SRC and ARIAC). After this, our work-flow would be like it is for the other servers:

  1. Develop a feature in a branch off default

  2. Make PR against default

  3. Wait for peer review

  4. Once merged and deployed, check that it works on the live server

  5. Make a pull request merging default into production

  6. It shouldn't be necessary for peer review again, the PR would be mostly to keep track of changes

This leaves the question about what to do with features which need to be tested in a live server, but aren't ready to go into production yet. I don't think we have a use case for this coming any time soon, so we can tackle it when it comes up.

Client routing

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

There are a few problems with the routing performed at routing.html:

  • Routes currently can't have / inside them, we need to rethink this line:

    page.base(app.baseUrl.replace(//$/, ''))

  • Routes don't stick on refresh. For example, if you're at https://localhost:5000/src-kiosk and refresh the browser, you are sent to the dashboard. The same happens if you copy that url into another browser.

  • When we go to a new route without going through the menu, the wrong menu item is highlighted.

Add countdown timer for how long the machines will stay up

Original report (archived issue) by Tully Foote (Bitbucket: Tully Foote, GitHub: tfoote).

We have people leaving machines online. I think they're done. But if we had an automatic, resettable countdown timer that if it runs out the machines will automatically clean up we could avoid abandoned machines. If there's a simple way to reup the amount of time left it shouldn't be too onerous.

Hardcoded amis

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

Currently the amis which can be launched are hardcoded in cs-machinelauncher.

This is a problem because portals launched using different AWS keys might not have access to the amis. Since the portal is the one which talks to AWS, it probably makes sense for the portal to keep the list of amis, perhaps even different ones for each user. The amis could be provided to .env, so we don't need to hardcode them.

SASC: Add documentation tab

Original report (archived issue) by Tully Foote (Bitbucket: Tully Foote, GitHub: tfoote).

I realized we have: https://github.com/osrf/uctf/blob/master/doc/run_cloud/readme.md

But it would be really nice to have this in the SASC portal natively. Could we add a new tab that would render a markdown file to the menu? Or a pop-up or something?

This is kind of a nebulus idea but it seems to make sense to bring the documentation closer to the content. But I'd really like to keep it in something easily editable like markdown instead of trying to embed it into the html content. Also reviews of markdown changes could be quicker and easier since they can't do anything but screw up the documentation.

Maybe just the bottom of the page for each page could have the help content relevant for that page?

Add number of payload machines as round parameter

Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).

Allow specification of the number of payload machines to be created per team at the time of round creation. Enforce a sane maximum number (e.g., drop down with 1-3, defaulting to 1).

Also have a "launch all" button per team instead of a "launch" button per machine.

Increment static IPs (192.168.2.10, .11, .12, etc.).

Make sure that each payload machine is given a different client_id (which will appear in the cloudsim-options.json file on the machine).

Add UI element while new machines are pending

Original report (archived issue) by Tully Foote (Bitbucket: Tully Foote, GitHub: tfoote).

When we launch new machines it takes about 2 minutes before they are ready. It would be great to represent this in the UI.

A low level bar would be a 2 minute timer which appears to be the approximate time necessary for it to clone.

A better solution would be to wait for a service to come up. It sounds like the cloudsim webserver could be pinged via javascript for a resource to indicate that the service is available.

@chapulina mentioned she'd looked at this before and might have a prototype started.

Improve cs-serverstatus

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:

  • Instead of expecting specific servers, let the user pass an array of custom servers
  • Add a status indicator so we know whether the servers are responsive. Maybe using an iron-ajax component to do this.
  • Add a cs-serverstatus for each currently running machine.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.