Re: juju juju-upgrade -m controller woes
I'm a bit curious what you mean by "manually provisioned machine". Are you saying that you used the VMWare APIs directly to launch an instance, and then "juju bootstrap IP" to start using that machine, and then "juju add-machine ssh:IP" to add the second machine? You could try doing "juju upgrade-juju --debug" to see what at least the client thinks it is trying to do. I wonder if it is a case where your VM doesn't actually have egress access, but your client does. And so Jujud on the VM is trying to do something like download the new agent, which your client saw and said was available, but the controller isn't actually able to download. John =:-> On Fri, Jan 26, 2018 at 8:48 PM, Daniel Bidwell wrote: > I have a juju controller, uncloud, in a container in a vmware vm. The > controller has a manually provisioned machine deployed happily. I > tried to manually provision a second machine. It is stuck in pending > with no progress after a day of waiting. I can ssh to ubuntu@host just > fine with the ssh keys installed. > > I am provisioning from a machine with juju 2.3.2 and the controller has > version 2.2.6 on it (now unsupported). I have attempted to do "juju > upgrade-juju -m uncloud" and it happily says that it is upgrading to > 2.3.2, but I never see any progress with that either (after hours or > days). > > What is the secret sauce for making these thing work? For some reason, > whenever I have trouble with my juju environment, I have to destory it > and set up the controllers from scrap. I guess I just don't have the > juju for juju :-( I do like being able to develop charms for my apps > and deploy them though. > -- > Daniel Bidwell > > > -- > Juju-dev mailing list > juju-...@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [charms] Request to promulgate charms
Alvaro, The three charms have been promulgated (the first already was) and the permissions set so that prometheus-charmers can release updates to stable without reaching out to the list. As far as I know, the promulgate sub-command will not be added to the charm command, and new promulgations will continue to need to go through the list. On Fri, Jan 26, 2018 at 10:51 AM, Alvaro Uria wrote: > Hi, > > There are 3 charms in the charmstore that would require to be promulgated: > > cs:~prometheus-charmers/grafana > cs:~prometheus-charmers/prometheus-openstack-exporter > cs:~prometheus-charmers/prometheus-ceph-exporter > > Please let me know if you would need any more detail or if it would be > required to email this request any time we push updates to the mentioned > charms. > > OTOH, I'm running the charm snap (2.2.3) and I think this bug still > applies (ERROR unrecognized command: charm promulgate) > https://github.com/juju/charm-tools/issues/310 > > Kind regards, > -Alvaro. > > -- > Alvaro Uría > Cloud Reliability Engineer - BootStack > Canonical, Ltd > > -- > 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
Re: juju juju-upgrade -m controller woes
I have a vmware vm on my public network that is my juju host. In it I have an lxc container that is also bridged to my public network. I bootstrapped it with: juju bootstrap manual/ipaddress modelname I also created vms with public IP addresses that I setup an ubuntu account and added as: juju add-machine ssh:ubuntu@ipaddress all machines have public ip address and full routing. The controller container was running juju version 2.2.6 (unsupported) while the main machine had been upgraded to 2.3.2. juju status produces: ModelController Cloud/Region Version SLA default uncloud manual2.2.6unsupported App Version Status Scale Charm Store Rev OS Notes au-webcluster-member active 1 au-webcluster-member local0 ubuntu aubase1active 1 aubase1 local0 ubuntu Unit Workload Agent Machine Public address Ports Message au-webcluster-member/0* activeidle 1webc4 Web cluster member for instance test completed aubase1/0* activeidle 1webc4 Machine StateDNS Inst id Series AZ Message 0down amzsend manual:amzsend xenial Manually provisioned machine 1started webc4manual:webc4xenial Manually provisioned machine 2pending webc5manual:webc5xenial Manually provisioned machine machine 2 failed to "add". The upgrade-juju command now says: ERROR some agents have not upgraded to the current model version 2.2.6: machine-2 but juju doesn't let me do anything with machine-2 until it is finished with it. I suspect that my only option is to build a new container/controller and redeploy my machines on it before removing the old container/controller. On Tue, 2018-01-30 at 14:40 +0400, John Meinel wrote: > I'm a bit curious what you mean by "manually provisioned machine". > Are you saying that you used the VMWare APIs directly to launch an > instance, and then "juju bootstrap IP" to start using that machine, > and then "juju add-machine ssh:IP" to add the second machine? > > You could try doing "juju upgrade-juju --debug" to see what at least > the client thinks it is trying to do. I wonder if it is a case where > your VM doesn't actually have egress access, but your client does. > And so Jujud on the VM is trying to do something like download the > new agent, which your client saw and said was available, but the > controller isn't actually able to download. > > John > =:-> > > > On Fri, Jan 26, 2018 at 8:48 PM, Daniel Bidwell > wrote: > > I have a juju controller, uncloud, in a container in a vmware vm. > > The > > controller has a manually provisioned machine deployed happily. I > > tried to manually provision a second machine. It is stuck in > > pending > > with no progress after a day of waiting. I can ssh to ubuntu@host > > just > > fine with the ssh keys installed. > > > > I am provisioning from a machine with juju 2.3.2 and the controller > > has > > version 2.2.6 on it (now unsupported). I have attempted to do > > "juju > > upgrade-juju -m uncloud" and it happily says that it is upgrading > > to > > 2.3.2, but I never see any progress with that either (after hours > > or > > days). > > > > What is the secret sauce for making these thing work? For some > > reason, > > whenever I have trouble with my juju environment, I have to destory > > it > > and set up the controllers from scrap. I guess I just don't have > > the > > juju for juju :-( I do like being able to develop charms for my > > apps > > and deploy them though. > > -- > > Daniel Bidwell > > > > > > -- > > Juju-dev mailing list > > juju-...@lists.ubuntu.com > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/juju-dev > > -- Daniel Bidwell -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: juju juju-upgrade -m controller woes
In 2.3 there is "juju upgrade-juju --ignore-agent-versions" but I think that is only respected if the target controller already is 2.3 (eg, this would help if you were trying to go from 2.3 to 2.4, but won't help going 2.2 to 2.3). There is a separate command line utility that you can build in the juju source tree called "juju-force-upgrade" which can work to bypass the agent version check. It might also be possible to "juju remove-machine --force 2" which would let you remove that machine. However, I'm not 100% sure that you can remove a machine that is currently pending provisioning. Its possible that "juju debug-log --replay [-m controller]" would be enlightening as to why machine 2 is failing to be provisioned (or looking at machine-0.log on the controller machine). Is there a reason you are manually provisioning instances and then registering them rather than using the cloud as a VMWare cloud? (juju add-cloud vmware). John =:-> On Wed, Jan 31, 2018 at 12:00 AM, Daniel Bidwell wrote: > I have a vmware vm on my public network that is my juju host. In it I > have an lxc container that is also bridged to my public network. I > bootstrapped it with: > > juju bootstrap manual/ipaddress modelname > > I also created vms with public IP addresses that I setup an ubuntu > account and added as: > > juju add-machine ssh:ubuntu@ipaddress > > all machines have public ip address and full routing. > > The controller container was running juju version 2.2.6 (unsupported) > while the main machine had been upgraded to 2.3.2. > > juju status produces: > > ModelController Cloud/Region Version SLA > default uncloud manual2.2.6unsupported > > App Version Status Scale Charm > Store Rev OS Notes > au-webcluster-member active 1 au-webcluster- > member local0 ubuntu > aubase1active 1 aubase1 > local0 ubuntu > > Unit Workload Agent Machine Public > address Ports Message > au-webcluster-member/0* activeidle 1webc4 Web > cluster member for instance test completed > aubase1/0* activeidle 1webc4 > > Machine StateDNS Inst id Series AZ Message > 0down amzsend manual:amzsend xenial Manually > provisioned machine > 1started webc4manual:webc4xenial Manually > provisioned machine > 2pending webc5manual:webc5xenial Manually > provisioned machine > > machine 2 failed to "add". The upgrade-juju command now says: > > ERROR some agents have not upgraded to the current model version 2.2.6: > machine-2 > > but juju doesn't let me do anything with machine-2 until it is finished > with it. > > I suspect that my only option is to build a new container/controller > and redeploy my machines on it before removing the old > container/controller. > > On Tue, 2018-01-30 at 14:40 +0400, John Meinel wrote: > > I'm a bit curious what you mean by "manually provisioned machine". > > Are you saying that you used the VMWare APIs directly to launch an > > instance, and then "juju bootstrap IP" to start using that machine, > > and then "juju add-machine ssh:IP" to add the second machine? > > > > You could try doing "juju upgrade-juju --debug" to see what at least > > the client thinks it is trying to do. I wonder if it is a case where > > your VM doesn't actually have egress access, but your client does. > > And so Jujud on the VM is trying to do something like download the > > new agent, which your client saw and said was available, but the > > controller isn't actually able to download. > > > > John > > =:-> > > > > > > On Fri, Jan 26, 2018 at 8:48 PM, Daniel Bidwell > > wrote: > > > I have a juju controller, uncloud, in a container in a vmware vm. > > > The > > > controller has a manually provisioned machine deployed happily. I > > > tried to manually provision a second machine. It is stuck in > > > pending > > > with no progress after a day of waiting. I can ssh to ubuntu@host > > > just > > > fine with the ssh keys installed. > > > > > > I am provisioning from a machine with juju 2.3.2 and the controller > > > has > > > version 2.2.6 on it (now unsupported). I have attempted to do > > > "juju > > > upgrade-juju -m uncloud" and it happily says that it is upgrading > > > to > > > 2.3.2, but I never see any progress with that either (after hours > > > or > > > days). > > > > > > What is the secret sauce for making these thing work? For some > > > reason, > > > whenever I have trouble with my juju environment, I have to destory > > > it > > > and set up the controllers from scrap. I guess I just don't have > > > the > > > juju for juju :-( I do like being able to develop charms for my > > > apps > > > and deploy them though. > > > -- > > > Daniel Bidwell > > > > > > > > > -- > > > Juju-dev mailing list > > > juju-...@lists.ubuntu.com > > >
