147
|
|
|
Rick Harding |
10 years ago
|
|
|
133
|
|
|
Gary Poster |
10 years ago
|
|
|
126
|
|
|
Francesco Banconi |
10 years ago
|
|
|
122
|
|
|
Francesco Banconi |
10 years ago
|
|
|
121
|
|
Fix deployer integration.
Fix the deployer error when the bundle includes services with constraints.
Updated the deployer dependency. The new tarball is generated from lp:~frankban/juju-deployer/guienv-fixes I will take care of proposing that branch later, however, the diff can be found here: http://pastebin.ubuntu.com/6376113/
This branch includes the work Benji did for fixing this issue.
TODO: but these are not release blockers IMHO: - improve the way we handle the set up of testing/production environments (as Rick suggested); - improve the GUI server bundle validation, e.g. disallow the deployment of local charms, or better check that the YAML structure is what we expect; - investigate and fix the bundle deployment error handling: why errors in the deployer process are not propagated? Why concurrent.futures explodes with an error while trying to set up the exception to be propagated in the Future? This is important because right now an error in the deployer is not notified, so the deployment is forever considered in progress and all the other deployments will be just queued... Actually this is "almost" a release blocker.
Tests: make unittest
QA: I used this bundle: http://pastebin.ubuntu.com/6376098/ to live test the branch. Bootstrap a juju environment, run `make deploy` and then switch the gui source to lp:juju-gui. When everything is ready, try to deploy a bundle which includes num_units != 1, customized config and constraints. Check the bundle is deployed correctly and the resulting services have the defined number of units, options and constraints. Now try to deploy a bundle with invalid constraints: right after the drag and drop, the GUI should notify an invalid constraints error.
R=rharding, benji CC= https://codereview.appspot.com/22810043
|
Francesco Banconi |
10 years ago
|
|
|
114
|
|
Avoid installing from PPA if not required.
No longer add the juju-gui PPA by default: the external repository is added only if required, i.e. if the legacy server is used or if a branch is passed to juju-gui-source.
The only missing bit to make the charm work well from behind a firewall AFAICT is avoiding the release to be downloaded from Launchpad.
Also included the shelltoolbox file in the charm: unfortunately the python-shelltoolbox package is not available on precise. On the other hand, this allows for getting rid of the bootstrap_utils.py file, and the install hook now feels cleaner.
Refactoring + some magic removal on the backend framework. Now it should be less surprising, and also allows for more customizations, e.g. what I did in the install method.
Also added missing tests for the backend framework: those were required in order to increase our control over what's really happening in the backend "hooks".
Switched to the builtin Tornado server by default.
This diff is very big, I am sorry, but: - you can ignore the bootstrap_utils removal; - you can ignore the shelltoolbox.py file: it is just a copy of the one present in the raring python-shelltoolbox package; - a lot of code is tests, the rest of the code should be quite easy to follow.
QA: `make deploy` and watch the logs: - no PPA should be installed by default; - the deployment succeeds and the GUI works well; switch to builtin-server=false and watch the logs: - the PPA is installed (and then haproxy, apache...); - the config-change hook exits without errors and the GUI works well.
Tests: `make unittest` (I ran the functional tests myself).
Thank you!
R=gary.poster, rharding CC= https://codereview.appspot.com/14433049
|
Francesco Banconi |
10 years ago
|
|
|
113
|
|
|
Francesco Banconi |
10 years ago
|
|
|
110
|
|
|
Francesco Banconi |
10 years ago
|
|
|
91
|
|
|
Francesco Banconi |
10 years ago
|
|
|
88
|
|
|
Francesco Banconi |
10 years ago
|
|
|
78
|
|
New WebSocket connection implementation.
This branch includes a new WebSocket client implementation purely based on Tornado.
Dropped the ws4py dependency, previously introduced as a consequence of the built-in client not being able to connect to juju-core.
Investigation: I investigated this problem and found that the WebSocket server implementation in the standard go.net library (used by juju-core) requires the "Origin" header to be sent by the client when the WebSocket handshake is initiated. See https://code.google.com/p/go/source/browse/websocket/hybi.go?repo=net#514 lines 514-517. However, if I read the RFC correctly, this is not entirely the right behavior: see http://tools.ietf.org/html/rfc6455#page-18 subsection 8: "The request MUST include a header field with the name |Origin| [RFC6454] if the request is coming from a browser client. If the connection is from a non-browser client, the request MAY include this header field if the semantics of that client match the use-case described here for browser clients." This MP description is going to be long anyway, so please excuse me if I add some background not really related to the branch. I was curious about why the Python WebSocket client library that I traditionally used to live test the juju-core API changes (python-websocket-client) always work with the juju-core server. The answer ended up being: if no origin is provided, that library include as "Origin" in the request headers the address of the WebSocket server itself (see https://github.com/liris/websocket-client/blob/master/websocket.py#L441 lines 441-444). I am not sure this make any sense, but I decided to adopt this solution as fallback for the client in this branch, i.e.: if the browser request includes the origin header (it always should), that header is propagated; otherwise I send the juju-core API server address. To be clear, the more I think about it, the more I am convinced that this is NOT a bug in the Tornado client (which, anyway, allows for adding arbitrary headers almost easily, as shown in the code). That's it: I am really interested in your opinion.
Other changes: Improved logging. Moved the message queue from the client to the server. Improved the way disconnections are handled (both browser and Juju API disconnections). Improved the way possible API connection problems are handled.
Tests: Run `make unittest` from the branch root.
QA: It's not required and, at this time, not easy to set up. Do it only if you are particularly interested/curious. Instructions follow.
- Bootstrap juju-core, deploy and expose the juju-gui charm:
juju bootstrap -e go --upload-tools juju deploy -e go cs:precise/juju-gui juju expose -e go juju-gui
- Run `juju status -e go` and retrieve the bootstrap node and the juju-gui addresses. From now on, I will call the former JUJU-BOOTSTRAP-ADDRESS and the latter JUJU-GUI-ADDRESS.
- Wait until the juju-gui service is started.
- Get a copy of this branch:
bzr branch lp:~frankban/charms/precise/juju-gui/new-ws-client/
- Copy the gui-server files in the juju-gui node by running the following command from the branch root:
rsync -av server/ ubuntu@JUJU-GUI-ADDRESS:/home/ubuntu/server
- Ssh into the juju-gui machine:
juju ssh -e go 1
- In the juju-gui node, all the commands must be run as root:
sudo -i
- Stop apache and haproxy:
service apache2 stop service haproxy stop
- Set up the gui-server dependencies:
apt-get install python-pip pip install tornado
- Start the gui-server:
cd /home/ubuntu/server/ python runserver.py \ --guiroot="/var/lib/juju/agents/unit-juju-gui-0/charm/juju-gui/build-prod" \ --jujuapi="wss://JUJU-BOOTSTRAP-ADDRESS:17070"
- Navigate to JUJU-GUI-ADDRESS with your browser. You should be redirected to https://JUJU-GUI-ADDRESS. Accept the untrusted certificate and start playing with the GUI.
- See the terminal for gui-server access logs. To enable debug logging, quit the server (CTRL-c) and restart it adding `--logging=debug` to the list of the options above. At this point the output should include the contents of the received WebSocket messages.
- Done, thank you!
R=teknico, gary.poster CC= https://codereview.appspot.com/11675043
|
Francesco Banconi |
10 years ago
|
|
|
76
|
|
|
Francesco Banconi |
10 years ago
|
|
|
68
|
|
|
Francesco Banconi |
10 years ago
|
|
|
67
|
|
|
Nicola Larosa |
10 years ago
|
|
|
65
|
|
|
Francesco Banconi |
10 years ago
|
|
|