Hi Pete,
I recently modified the GUI to use the new `configYAML` field. To do so I
took the JSON that we normally sent in the `config` argument and passed it
as the `configYAML` argument. You can see the PR[0] for the change made and
a little code comment as to why.
If you'd like an easy way to
We’re pleased to announce the latest feature release of the Juju GUI.
With the GA of Juju 2 release coming very soon we’re ready to unveil the
new enhanced model management in the Juju GUI. The new GUI allows you to
take advantage of Juju 2’s multi-user multi-model functionality as
seamlessly as
The next version of the Juju GUI has been released!
This release includes a number of fixes which bring it back in line with
the recent changes in the Juju 2 betas which re-enables the ability to
switch models from the GUI which was temporarily removed in the previous
release.
Other improvements
Thanks for reporting this issue,
Sorry about this, we were able to reproduce it and will work towards a
solution soon. I've created an issue in our GitHub repository if you'd like
to track our progress there: https://github.com/juju/juju-gui/issues/1559
Thanks again
-Jeff
On Thu, Apr 14, 2016
Version checking for features can be dangerous because a commands output or
availability may change in the future and now your charm also needs a
max-version, or version-range etc. A more robust solution could be
something along the lines of a feature-supported query which would return
whether
This sounds like a good idea. The bug which I ran into (which I'm
assuming is the source behind this query) would be very difficult to
debug by users who didn't realize that there was a new juju release and
they have not yet updated the client.
-Jeff
Kapil Thangavelu wrote:
sounds like a great
