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