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:
Model Controller Cloud/Region Version SLA
default uncloud manual 2.2.6 unsupported
App Version Status Scale Charm Store Rev
OS Notes
au-webcluster-member active 1 au-webcluster-member local 0
ubuntu
aubase1 active 1 aubase1 local 0
ubuntu
Unit Workload Agent Machine Public address Ports
Message
au-webcluster-member/0* active idle 1 webc4 Web
cluster member for instance test completed
aubase1/0* active idle 1 webc4
Machine State DNS Inst id Series AZ Message
0 down amzsend manual:amzsend xenial Manually provisioned
machine
1 started webc4 manual:webc4 xenial Manually provisioned
machine
2 pending webc5 manual:webc5 xenial 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 <drbidw...@gmail.com>
> 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 <drbidw...@gmail.com>
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman
> > /listinfo/juju-dev
> >
--
Daniel Bidwell <drbidw...@gmail.com>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
