Re: What sort of encoding does the websocket API expect for config-yaml?

[Jeff Pihach]

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 inspect the RPC calls you can also do so by
checking out the JS API in the GUI and/or inspecting the WS in the GUI and
performing the various actions to see the live interactions with Juju.

[0] https://github.com/juju/juju-gui/pull/2527/files

Hope this helps!
- Jeff

On Tue, Feb 28, 2017 at 4:42 PM, Pete Vander Giessen <
pete.vandergies...@canonical.com> wrote:

> Hi All,
>
> I'm currently working on getting python-libjuju to successfully deploy the
> landscape-dense-maas bundle. It fails, as outlined in
> https://bugs.launchpad.net/juju/+bug/1651260.
>
> (python-libjuju is a Python client that talks to Juju's websocket API; I'm
> currently using it inside the matrix testing framework.)
>
> The comments in that bug suggest that the root of the problem is that I'm
> trying to deploy a charm (haproxy) that has an empty string as a default
> value, but python-libjuju is using the legacy "config" param when it calls
> ApplicationDeploy in the api, rather than the new "config-yaml" param. This
> sounds simple to fix -- all I have to do is change an arg from "config" to
> "config-yaml", and everything should work!
>
> One hitch: the "config" param expects a json object, which is what we get
> back when we make our initial call to the planner, but config-yaml expects
> a string with yaml in it (this is per the logic in deployApplication in
> juju/apiserver/application/application.go).
>
> That also sounds simple. As we do elsewhere in python-libjuju when we want
> to pass a yaml blob to the API, I use Python's handy yaml library, do
> yaml.dump(config), where "config" is the json config object I got from the
> planner, and everything should work!
>
> This is where I'm stuck. If I pass in such a string, the websocket API
> simple hangs, and stops talking to me. I don't even see any error messages
> in the logs on my controller :-/
>
> Does anyone have any insight as to what I might be doing incorrectly? In
> Python3, yaml.dump will produce a utf-8 string by default. All of that will
> get serialized to json before being submitted over the websocket, though,
> so I don't *think* that it's an encoding issue. (Passing the bundle in as a
> yaml blob to the planner in the first place works.) The config object I get
> back from the planner isn't wrapped in an "options" key, but adding that
> key before dumping the config to a yaml string doesn't fix the problem -- I
> still see the hang.
>
> Apologies for the length of the post. And thanks in advance for anything
> you can do to get me unstuck!
>
> ~ PeteVG
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju GUI 2.2.0 released!

[Jeff Pihach]

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 you worked with a single model in the past. You can now
create new models, select which region in your cloud to deploy to, add new
credentials, and choose which credentials to use when deploying new models.

For a complete rundown of the new features in the the 2.2.0 release of the
Juju GUI check out this video below:

https://www.youtube.com/watch?v=_FGLf5Q1q8U

Changes:

- New and enhanced model management in this release. This new experience
allows you to create new models, select which region to deploy to, add new
credentials, and choose which credentials to use when deploying to new
models.
- Add Bundle Service support. This feature allows the GUI to use the
external Bundle Service to import bundles when the bundle lib in Juju is
not available, such as when in a sandbox or unconnected mode.
- Add version.json asset which contains the version number and git sha used
to build the GUI. To access this file visit the following path replacing
the necessary values:
  /gui/[CONTROLLER UUID]/[MODEL UUID]/static/gui/build/app/version.json
- (Fix) Logging in via USSO when you have no models.
- (Fix) Update relation list when removing uncommitted subordinate relation.
- (Fix) No clouds result when listing clouds.
- (Fix) Switch between unconnected state to connected state.

To upgrade your existing models to use this version of the GUI:

Juju 2:

Run `juju upgrade-gui`
Run `juju gui --show-credentials`

Juju 1:

Run `juju upgrade-charm juju-gui`

We welcome any feedback you may have on the GUI.  You can chat with us in
#juju on irc.freenode.net or you can file issues at:
https://github.com/juju/juju-gui/issues
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju GUI 2.1.12 released

[Jeff Pihach]

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 include:
  - Bundles now use "applications" top level key instead of "services".
  - Use a different WebSocket connection for the model and controller.
  - Create New Model button moved into the user profile.
  - Deploying bundles with lxc placements automatically convert to lxd.
  - Multi-series subordinates now have their series locked to the series of
the first related parent application.
  - (Fix) Local charms now deploy without issuing error about charm
location.
  - (Fix) When relating to subordinates, invalid targets are now faded.

To upgrade your existing models to use this version of the GUI:

Juju 2 beta:
  - Download the *.bz2 from
https://github.com/juju/juju-gui/releases/tag/2.1.12
  - Run `juju upgrade-gui /path/to/bz2`
  - Run `juju gui --show-credentials`

Juju 1:
  - juju upgrade-charm juju-gui

We welcome any feedback you may have on the GUI, you can chat with us in
#juju on irc.freenode.net or you can file issues here:
https://github.com/juju/juju-gui/issues
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: SyntaxError: expected expression, got '<' while dragging and dropping local charm on Juju GUI

[Jeff Pihach]

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 at 6:24 PM, phani shankar 
wrote:

> Hi,
>
> I am trying to use the drag and drop feature to pull local charm
> onto Juju GUI. However, I don't see any upload option even though I dragged
> and dropped  the local charm. In web browser debugger console, I see
> following error.
>
>
> SyntaxError: expected expression, got '<' inflate.js:1:0
>
> I have tried this in chrome, IE and Firefox and I am observing the same
> behavior.
>
> I am using trusty/juju-gui-54 charm.
>
> [Services]
> NAME   STATUS  EXPOSED CHARM
> juju-gui   unknown truecs:trusty/juju-gui-54
> mysql  unknown false   cs:trusty/mysql-38
>
>
> Please let me know your thoughts.
>
>
>
> Regards,
> PHANI SHANKAR
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Use case for: min-version

[Jeff Pihach]

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 that command is indeed supported in the active environment with the
necessary syntax.

In JS this is a common workflow when dealing with cross browser
compatibility issues and this issue is similar. The use could be something
like...

IS_LEADER_SUPPORTED=`juju supported-command is_leader`
if [ $IS_LEADER_SUPPORTED == true ]; then
  # Do stuff
else
 juju-log Requires is_leader Juju command
fi

-Jeff

On Mon, Aug 10, 2015 at 2:32 PM, Matt Bruzek matthew.bru...@canonical.com
wrote:


 We wrote a charm that needed election logic, so we used the new Juju
 feature is_leader.  A user was interested in using a bundle that
 contained this charm and it failed on them.  It was hard to track down the
 cause of the problem.  It appears they were using an earlier version of
 Juju that is available from universe and only the PPA had the more current
 version.

 Read more about the problem here:
 https://bugs.launchpad.net/charms/+source/etcd/+bug/1483380

 I heard the min-version feature discussed at previous Cloud sprints but
 to my knowledge we do not have it implemented yet.  The idea was a charm
 could specify in metadata.yaml what min-version of Juju they support.

 There are a lot of new features that juju-core are cranking out (and that
 is *awesome*)!  We have already run into this problem with a real user, and
 will have the problem in the future.

 Can we reopen the discussion of min-version?  Or some other method of
 preventing this kind of problem in the future?

- Matt Bruzek matthew.bru...@canonical.com

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: What happened to pinned bootstrap

[Jeff Pihach]

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 case being made for --upload-tools by default.



 On Sun, Mar 30, 2014 at 12:23 AM, John Meinel j...@arbash-meinel.com
 mailto:j...@arbash-meinel.com wrote:

 I thought at one point we were explicitly requiring that we
 bootstrap exact versions of tools (so juju CLI 1.17.2 would only
 bootstrap a 1.17.2 set of tools). We at least did 1.17 will only
 bootstrap 1.17, but looking at the code we still always deploy the
 latest 1.17 (which broke all the 1.17 series of CLI because 1.17.7
 has an incompatible required flag).

 There is an argument that we can't get away with such a thing in a
 stable series anyway, so it isn't going to be a problem. Mostly,
 though, I had thought that we did exact matching, but I can see
 from the code that is clearly not true.

 Would it be very hard to do so? I think William had a very
 interesting idea that CLI bootstrap would always only bootstrap
 the exact version of tools, but could set the AgentVersion to the
 latest stable minor version, so it essentially bootstraps and then
 immediately upgrades. (With the big benefit that the upgrade
 process to migrate from old versions to new versions gets run.)

 This could be a distraction from the other stuff we're working on,
 but it doesn't look that hard to implement, and would avoid some
 of these semi-accidental breaking of old tools.

 John
 =:-

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev