2.1.2 juju status can't parse response from 2.2-alpha1 agent

[Francis Ginther]

I have a model with agents running 2.2-alpha1 on top of a landscape autopilot openstack cloud. A 'juju status' with 2.1.2 results in an error, but works with 2.2-beta1. The error without --debug is:

ERROR codec.ReadHeader error: error receiving message: unexpected end of JSON input

This failure only occurs with one of the three models on this controller. All models are running 2.2-alpha1. The model that fails contains some machines which failed to deploy due to an issue with the underlying openstack cloud and are stuck in an error state. The 2.2-beta1 version of juju status displays a lot of additional error info for these instances. The full log of juju status from 2.2-beta1 is attached.

Expected behavior:
I would expect any 2.x series "juju status" to display status regardless of the agent-version of the model.

Here's what I see:

[While using juju 2.1.2]
$ juju model-config|grep agent-version
agent-version model 2.2-alpha1
$ juju status --debug
13:39:41 INFO juju.cmd supercommand.go:63 running juju [2.1.2 gc go1.6.2]
13:39:41 DEBUG juju.cmd supercommand.go:64 args: []string{"juju", "status", "--debug"}
13:39:41 INFO juju.juju api.go:72 connecting to API addresses: [10.96.127.8:17070 10.100.0.11:17070]
13:39:41 DEBUG juju.api apiclient.go:590 dialing "wss://10.96.127.8:17070/model/e49ff137-11ef-4d0f-8acc-a4a5de66fe86/api"
13:39:41 DEBUG juju.api apiclient.go:590 dialing "wss://10.100.0.11:17070/model/e49ff137-11ef-4d0f-8acc-a4a5de66fe86/api"
13:39:41 DEBUG juju.api apiclient.go:606 will retry after error dialing websocket: websocket.Dial wss://10.100.0.11:17070/model/e49ff137-11ef-4d0f-8acc-a4a5de66fe86/api: dial tcp 10.100.0.11:17070: getsockopt: connection refused
13:39:43 DEBUG juju.api apiclient.go:593 successfully dialed "wss://10.96.127.8:17070/model/e49ff137-11ef-4d0f-8acc-a4a5de66fe86/api"
13:39:43 INFO juju.api apiclient.go:521 connection established to "wss://10.96.127.8:17070/model/e49ff137-11ef-4d0f-8acc-a4a5de66fe86/api"
13:39:43 DEBUG juju.juju api.go:263 API hostnames unchanged - not resolving
13:39:43 DEBUG juju.api monitor.go:35 RPC connection died
13:39:43 ERROR cmd supercommand.go:458 codec.ReadHeader error: error receiving message: unexpected end of JSON input
13:39:43 DEBUG cmd supercommand.go:459 (error details: [{github.com/juju/juju/api/apiclient.go:670: } {github.com/juju/retry/retry.go:187: } {github.com/juju/juju/rpc/client.go:149: } {github.com/juju/juju/rpc/server.go:354: codec.ReadHeader error} {github.com/juju/juju/rpc/jsoncodec/codec.go:131: error receiving message} {unexpected end of JSON input}])

[While using juju 2.2-beta1]
$ juju version
2.2-beta1-xenial-amd64
$ juju model-config|grep agent-version
agent-version model 2.2-alpha1
$ juju status
Model Controller Cloud/Region Version
long-running lrc-region1 lrc/region1 2.2-alpha1

App Version Status Scale Charm Store Rev OS Notes
landscape-client-trusty waiting 0 landscape-client jujucharms 28 ubuntu
landscape-client-xenial waiting 0 landscape-client jujucharms 28 ubuntu
trusty-client waiting 0/1 landscape-devenv local 0 ubuntu
trusty-server waiting 0/2 landscape-devenv local 1 ubuntu
ubuntu 16.04 waiting 5/6 ubuntu jujucharms 10 ubuntu
xenial-server-release waiting 0/1 landscape-devenv local 1 ubuntu
...
[See attachment for full juju status output]

[Francis Ginther (fginther)]

Also, when I removed the failed machines from the model, 'juju status' worked again with 2.1.2. The error content appears to be the source of the problem.

[Anastasia (anastasia-macmood)]

I am pretty sure that our new clients are backward compatible.

However, our old clients are not necessarily forward compatible. In other words, we do not guarantee that 2.1.2 client can talk to 2.2-a1 controller as you've observed :)

If on the other hand, you had 2.2-a1 client not being able to get status from 2.1.2 controller, then we'd consider it a bug.

Marking this bug as Invalid.

[John A Meinel (jameinel)]

We should be sure that the JSON is well formed even if the content contains
fields that 2.1 doesn't expect. Traditionally status has been something
that we rarely break between releases (up until the very last 1.X could
status across a very large range).

Now, if it really is just that unexpected output was getting munged into
the stream, maybe we can live with not supporting it, but it would be good
to understand why 2.2 status worked but 2.1 status failed. (I didn't think
we actually changed what was *in* status, we just chose to show it some the
message in 2.2).

On Thu, Mar 30, 2017 at 3:20 AM, Anastasia <email address hidden>
wrote:

> I am pretty sure that our new clients are backward compatible.
>
> However, our old clients are not necessarily forward compatible. In
> other words, we do not guarantee that 2.1.2 client can talk to 2.2-a1
> controller as you've observed :)
>
> If on the other hand, you had 2.2-a1 client not being able to get status
> from 2.1.2 controller, then we'd consider it a bug.
>
> Marking this bug as Invalid.
>
> ** Changed in: juju
> Status: New => Invalid
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1677351
>
> Title:
> 2.1.2 juju status can't parse response from 2.2-alpha1 agent
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1677351/+subscriptions
>

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.