Re: juju API not listening on all interfaces
Hi John,
I went through the upgrade guide and ran into some issues. I'm not sure
what I should do to resolved this. The error listed below
root@maas01:~# apt-get install juju-core
root@maas01:~# juju upgrade-juju --version 1.25.6 --debug
2016-11-08 10:24:05 INFO juju.cmd supercommand.go:37 running juju
[1.25.6-trusty-amd64 gc]
2016-11-08 10:24:05 DEBUG juju.api api.go:154 trying cached API connection
settings - endpoints [10.38.250.2:17070 10.38.251.49:17070]
2016-11-08 10:24:05 INFO juju.api api.go:266 connecting to API addresses: [
10.38.250.2:17070 10.38.251.49:17070]
2016-11-08 10:24:05 INFO juju.api apiclient.go:262 dialing "wss://
10.38.250.2:17070/environment/80751f52-30bf-4980-8b77-555c16684316/api"
2016-11-08 10:24:05 INFO juju.api apiclient.go:194 connection established
to "wss://
10.173.242.2:17070/environment/80751f52-30bf-4980-8b77-555c16684316/api"
2016-11-08 10:24:05 DEBUG juju.api api.go:476 API hostnames unchanged - not
resolving
2016-11-08 10:24:05 DEBUG juju.api api.go:506 cacheChangedAPIInfo:
serverUUID=""
2016-11-08 10:24:05 ERROR juju.cmd supercommand.go:429 invalid binary
version "1.25.6--amd64"
On Tue, Nov 8, 2016 at 12:15 AM, John Meinel wrote:
> A couple of points
> 1) I dug up the code and 1.22.8 has the same code for listening on
> ":17070", so I can't see why it wouldn't be listening on both addresses.
> 2) Is there any reason you're still on 1.22.* ? Its been out of support
> for a while, and we do strongly encourage you to upgrade to the 1.25 series.
>
> John
> =:->
>
> On Mon, Nov 7, 2016 at 3:10 PM, Wayne Carty wrote:
>
>> Hi John,
>>
>> I'm using version 1.22.8. I did check the order of the interfaces and
>> they all start before juju runs. Even after restarting the API service with
>> the interfaces up it's still doesn't listen on 10.38.250.0/24.
>>
>> Thanks,
>> Wayne
>>
>>
>>
>> On Mon, Nov 7, 2016 at 6:34 AM, John Meinel
>> wrote:
>>
>>> What version of Juju are you running? Is it possible the devices didn't
>>> come up before Juju was up and running? Right now we are doing:
>>>endpoint := net.JoinHostPort("", strconv.Itoa(info.APIPort))
>>> listener, err := net.Listen("tcp", endpoint)
>>>
>>> Which means we listen to ":17070". That should listen on all IP
>>> addresses for a machine.
>>>
>>> John
>>> =:->
>>>
>>> On Sat, Nov 5, 2016 at 8:40 PM, Wayne Carty wrote:
>>>
Hi,
I had our bootstrap node crash a few days ago and now the juju api is
not listening on all interfaces.
Out boot strap nodes server two networks.
10.38.250.0/24 and 10.38.251.0/24.
As of right now juju api is only listening on 10.38.250.251.0/24.
Nodes that are on 10.38.250.0/24 are now in error state because they
can't reach the api. The boot strap node has 2 interfaces. I have google
and have not found a way to fixed the issue.Any help that you guys can
provide is appreciated.
--
Wayne Carty
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
an/listinfo/juju
>>>
>>
>>
>> --
>> Wayne Carty
>>
>
>
--
Wayne Carty
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Juju agent status remains "Allocating" and is not starting on MAAS 2.0 when --storage option is used
Hi,
I am trying to deploy a charm on MAAS 2.0 and making use of Juju Storage
feature, so when I deploy my charm as shown below:
juju deploy ibm-spectrum-scale --storage disks=maas, the machine gets
started and status on MAAS is "deployed" but the juju agent does not
start. The agent message is "agent initializing" and nothing happens after
that.
The same charm gets deployed if I dont give the --storage parameter during
deploy time or use --storage disks=loop. This issue is seen only when i
deploy the charm with --storage disks=maas. I have tried deploying the
charm on AWS environment with --storage disks=ebs, there it works fine and
no issues are seen.
In the juju logs I see the below messages:
to agent config as ["192.168.100.101:17070" "192.168.122.101:17070"]
2016-11-08 17:47:59 ERROR juju.worker.dependency engine.go:539
"metric-collect" manifold worker returned unexpected error: failed to read
charm from: /var/lib/juju/agents/unit-ibm-spectrum-scale-manager2-2/charm:
stat /var/lib/juju/agents/unit-ibm-spectrum-scale-manager2-2/charm: no
such file or directory
2016-11-08 17:47:59 INFO juju.worker.leadership tracker.go:184
ibm-spectrum-scale-manager2/2 will renew ibm-spectrum-scale-manager2
leadership at 2016-11-08 17:48:29.13919966 + UTC
2016-11-08 17:47:59 INFO juju.worker.meterstatus connected.go:112 skipped
"meter-status-changed" hook (missing)
2016-11-08 17:47:59 INFO worker.uniter.jujuc tools.go:20 ensure jujuc
symlinks in /var/lib/juju/tools/unit-ibm-spectrum-scale-manager2-2
2016-11-08 17:47:59 INFO worker.uniter.jujuc tools.go:40 was a symlink,
now looking at /var/lib/juju/tools/2.0.1-xenial-amd64
2016-11-08 17:47:59 INFO juju.worker.uniter uniter.go:159 unit
"ibm-spectrum-scale-manager2/2" started
2016-11-08 17:47:59 INFO juju.worker.uniter uniter.go:168 resuming charm
install
2016-11-08 17:47:59 INFO juju.worker.uniter.charm bundles.go:77
downloading local:xenial/ibm-spectrum-scale-manager2-3 from API server
2016-11-08 17:47:59 INFO juju.downloader download.go:111 downloading from
local:xenial/ibm-spectrum-scale-manager2-3
2016-11-08 17:47:59 INFO juju.downloader download.go:94 download complete
("local:xenial/ibm-spectrum-scale-manager2-3")
2016-11-08 17:47:59 INFO juju.downloader download.go:174 download verified
("local:xenial/ibm-spectrum-scale-manager2-3")
I compared the logs of the charm that I deployed on AWS and MAAS. In AWS
also when I deploy the charm, same messages are logged, the only
difference is that there its resuming the correct unit ie
ibm-spectrum-scale-manager2-2, but in case of MAAS, it resumes for unit
ibm-spectrum-scale-manager2-3 which does not exist.
Can anyone please help me in resolving this issue, I need to test my
charm deployment on MAAS making use of juju storage, but unable to do so
due to the above noted behavior.
Thanks and Regards,
Shilpa Kaul
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju agent status remains "Allocating" and is not starting on MAAS 2.0 when --storage option is used
On Tue, Nov 8, 2016 at 8:29 PM Shilpa Kaul wrote:
> Hi,
>
> I am trying to deploy a charm on MAAS 2.0 and making use of Juju Storage
> feature, so when I deploy my charm as shown below:
> *juju deploy ibm-spectrum-scale --storage disks=maas*, the machine gets
> started and status on MAAS is "deployed" but the juju agent does not start.
> The agent message is "*agent initializing*" and nothing happens after
> that.
>
> The same charm gets deployed if I dont give the --storage parameter during
> deploy time or use *--storage disks=loop*. This issue is seen only when i
> deploy the charm with *--storage disks=maas*. I have tried deploying the
> charm on AWS environment with --storage disks=ebs, there it works fine and
> no issues are seen.
>
> In the juju logs I see the below messages:
> to agent config as ["192.168.100.101:17070" "192.168.122.101:17070"]
> 2016-11-08 17:47:59 ERROR juju.worker.dependency engine.go:539
> "metric-collect" manifold worker returned unexpected error: failed to read
> charm from: /var/lib/juju/agents/unit-ibm-spectrum-scale-manager2-2/charm:
> stat /var/lib/juju/agents/unit-ibm-spectrum-scale-manager2-2/charm: no such
> file or directory
> 2016-11-08 17:47:59 INFO juju.worker.leadership tracker.go:184
> ibm-spectrum-scale-manager2/2 will renew ibm-spectrum-scale-manager2
> leadership at 2016-11-08 17:48:29.13919966 + UTC
> 2016-11-08 17:47:59 INFO juju.worker.meterstatus connected.go:112 skipped
> "meter-status-changed" hook (missing)
> 2016-11-08 17:47:59 INFO worker.uniter.jujuc tools.go:20 ensure jujuc
> symlinks in /var/lib/juju/tools/unit-ibm-spectrum-scale-manager2-2
> 2016-11-08 17:47:59 INFO worker.uniter.jujuc tools.go:40 was a symlink,
> now looking at /var/lib/juju/tools/2.0.1-xenial-amd64
> 2016-11-08 17:47:59 INFO juju.worker.uniter uniter.go:159 unit
> "ibm-spectrum-scale-manager2/2" started
> 2016-11-08 17:47:59 INFO juju.worker.uniter uniter.go:168 resuming charm
> install
> 2016-11-08 17:47:59 INFO juju.worker.uniter.charm bundles.go:77
> downloading local:xenial/ibm-spectrum-scale-manager2-3 from API server
> 2016-11-08 17:47:59 INFO juju.downloader download.go:111 downloading from
> local:xenial/ibm-spectrum-scale-manager2-3
> 2016-11-08 17:47:59 INFO juju.downloader download.go:94 download complete
> ("local:xenial/ibm-spectrum-scale-manager2-3")
> 2016-11-08 17:47:59 INFO juju.downloader download.go:174 download verified
> ("local:xenial/ibm-spectrum-scale-manager2-3")
>
> I compared the logs of the charm that I deployed on AWS and MAAS. In AWS
> also when I deploy the charm, same messages are logged, the only difference
> is that there its resuming the correct unit ie
> *ibm-spectrum-scale-manager2-2,* but in case of MAAS, it resumes for unit*
> ibm-spectrum-scale-manager2-3* which does not exist.
>
> Can anyone please help me in resolving this issue, I need to test my
> charm deployment on MAAS making use of juju storage, but unable to do so
> due to the above noted behavior.
Hi Shilpa,
AFAICT, this is the same issue as you mentioned in the thread "Regarding
juju Storage - using MAAS as cloud provider". Can you please respond to
Blake's request for information in that thread? That should help us
identify the problem.
Thanks,
Andrew
> Thanks and Regards,
> Shilpa Kaul
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
