139
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
138
|
|
|
Francesco Banconi |
2.2.0 |
8 years ago
|
|
|
137
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
136
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
135
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
134
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
133
|
|
|
Francesco Banconi |
2.1.1 |
8 years ago
|
|
|
132
|
|
|
Francesco Banconi |
2.1.0 |
8 years ago
|
|
|
131
|
|
|
Brad Crittenden |
|
8 years ago
|
|
|
130
|
|
|
Brad Crittenden |
|
8 years ago
|
|
|
129
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
128
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
127
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
126
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
125
|
|
|
Francesco Banconi |
|
8 years ago
|
|
|
124
|
|
|
Francesco Banconi |
2.0.1 |
9 years ago
|
|
|
123
|
|
|
Francesco Banconi |
|
9 years ago
|
|
|
122
|
|
Support retrieving bundles from charm store v4.
This branch implements the ability to deploy bundles from the new charm store, retrieving them with the v4 API.
Also introduce the new preferred bundle id spelling, i.e. reflecting jujucharms.com paths, like "mediawiki-single" or "u/who/bundle-name".
The old "bundle:basket/name" identifiers are still supported but deprecated. Deploying a bundle by specifying a directory containing the YAML file is instead not supported anymore.
Ok, after this brief summary let me take two lines to really apologize for the huge diff. While I was there, I refactored some historical inconsistencies (e.g. models.Charm really being just a charm or bundle reference), and I also improved the bundle model API so that the work is done in the model and not in manage as before. There are a lot of tests too, and some documentation. Nonetheless, let me say sorry again, this is really too much stuff.
With this branch Juju Quickstart is quite ready for the v4 world. The "deploy bundle" API call to the GUI server still uses the legacy format, but the ugliness of being backward compatible with namespaced bundles is very restrained and implemented in private logic in the bundles model module.
Tests: `make check`.
QA: run `devenv/bin/juju-quickstart` to deploy new style and old style bundles, with both version 3 and 4 formats. Note that version 3 can only be provided with arbitrary URLs or local files.
Thanks a lot!
R=rharding, matthew.scott CC= https://codereview.appspot.com/207040043
|
Francesco Banconi |
2.0.0 |
9 years ago
|
|
|
121
|
|
Add support for new Juju WebSocket API endpoints.
Recent Juju versions introduced a new API endpoint path. In essence, instead of the usual "wss://<address>:17070", the new "wss://<address>:17070/environment/<env-uuid>/api" is used to connect to the API. This allows for connecting to a specific environment in a multi-environment state server scenario.
In this branch the new API endpoint is used if a recent Juju version is in use, and if it is possible to retrieve the environment UUID from the jenv file.
Also, when connecting to the GUI server (for creating the auth token or for deploying bundles), use the new GUI server API endpoints when possible, i.e. when the charm is recent enough to support redirecting requests to the new Juju endpoints. Note that this feature is assumed to land in the next juju-gui charm release (see settings.py). If that's not the case, we'll need to increase the charm revisions in settings.MINIMUM_REVISIONS_FOR_NEW_API_ENDPOINT before releasing the new Quickstart.
Tests: `make check`
QA: - bootstrap quickstart as usual: `devenv/bin/juju-quickstart`; - check that, if you are using juju devel (1.22beta), quickstart properly connect to the new API endpoint; - run quickstart again to deploy a bundle, e.g.: `devenv/bin/juju-quickstart bundle:mediawiki/single`; - ensure that the deployment request succeeds; - if possible, do the above with and older version of Juju, to ensure backward compatibility.
Done, thank you!
R=martin.hilton, jeff.pihach CC= https://codereview.appspot.com/199490043
|
Francesco Banconi |
|
9 years ago
|
|
|
120
|
|
|
Francesco Banconi |
|
9 years ago
|
|
|