Re: adding nics to a vm in vmware built by juju deploy
Our VMWare Vcenter is running version 6.5. There are 2 sets of tools, one in flash which is supposed to be going away and one in html5. The html5 version doesn't support all of the features it needs to yet. The html5 views the juju created vms as locked, but the flash version allows us to edit them as needed. We work with the tools that are available and throw out ideas for features that would improve it. Love the juju tools! Great work everyone! On Tue, 2018-06-19 at 08:49 -0400, Rick Harding wrote: > I'm not familiar if there's any way to unlock/force through VMWare > but Juju doesn't currently support the idea of adding nics to running > instances at this moment. It's something we're definitely looking for > the future as clouds do support things like hot plugging nics. It > might be worth a test to see if you can adjust the nics on the VMWare > side. In some cases you can work around Juju like adding storage to > the root disk by upgrading the instance through the cloud tooling. > > On Fri, Jun 8, 2018 at 7:58 AM Daniel Bidwell > wrote: > > I have a vmware server that I am using as the target for deploying > > vms > > with juju. I have a set of vms that need multiple nics on > > different > > vlans/vmware networks. I want the vm to be on the primary network, > > but > > also have nics for 4 other secondary networks. > > > > Once the vm is deployed, vmware considers it locked and will not > > let me > > add additional nics. Is there a way to unlock it? Or is there a > > way > > to deploy the vm with the nics installed from the start? > > > > I didn't see anything in the online docs about adding additional > > networks to the constraints clause of the deploy. If this feature > > is > > not available at this time, could it be considered for the future? > > -- > > Daniel Bidwell > > > > > > -- Daniel Bidwell -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
How do you clean a juju disk or make it larger?
My juju controllers appear to be defaulting to a 10GB root disk. I am running out of disk space on the controller. I have 6.7GB in /var/lib/juju/db. Is there a way to reduce the disk usage on this? If not, can I make the root disk larger? What are my options? I have already cleared out kernel updates. -- Daniel Bidwell -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
adding nics to a vm in vmware built by juju deploy
I have a vmware server that I am using as the target for deploying vms with juju. I have a set of vms that need multiple nics on different vlans/vmware networks. I want the vm to be on the primary network, but also have nics for 4 other secondary networks. Once the vm is deployed, vmware considers it locked and will not let me add additional nics. Is there a way to unlock it? Or is there a way to deploy the vm with the nics installed from the start? I didn't see anything in the online docs about adding additional networks to the constraints clause of the deploy. If this feature is not available at this time, could it be considered for the future? -- Daniel Bidwell -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
More juju upgrade-juju failings
I am running on juju 2.3.3-xenial-amd64 and my controllers are running
in VMware Vsphere with version 2.3.2. I thought that it would be a
good thing for me to upgrade the controllers.
I have a controller, "juju switch" generates:
bannercontroller:admin/default
and juju status generates:
ModelControllerCloud/Region Version SLA
default bannercontroller myvscloud/New Datacenter 2.3.2unsupported
App Version Status Scale Charm Store Rev OS Notes
Unit Workload Agent Machine Public address Ports Message
Machine State DNS Inst id Series AZ Message
doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:
17:16:19 INFO juju.cmd supercommand.go:56 running juju [2.3.3 gc go1.9.2]
17:16:19 DEBUG juju.cmd supercommand.go:57 args:
[]string{"/snap/juju/3452/bin/juju", "upgrade-juju", "--agent-version",
"2.3.3", "--debug"}
17:16:19 INFO juju.juju api.go:67 connecting to API addresses:
[10.1.61.239:17070]
17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO juju.api apiclient.go:597 connection established to
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO juju.juju api.go:67 connecting to API addresses:
[10.1.61.239:17070]
17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO juju.api apiclient.go:597 connection established to
"wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
17:16:19 INFO juju.juju api.go:67 connecting to API addresses:
[10.1.61.239:17070]
17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed
"wss://10.1.61.239:17070/api"
17:16:19 INFO juju.api apiclient.go:597 connection established to
"wss://10.1.61.239:17070/api"
17:16:19 DEBUG juju.cmd.juju.commands upgradejuju.go:466 searching for agent
binaries with major: 2
17:16:22 INFO cmd upgradejuju.go:363 available agent binaries:
2.3.3-artful-amd64
2.3.3-artful-arm64
2.3.3-artful-ppc64el
2.3.3-artful-s390x
2.3.3-bionic-amd64
2.3.3-bionic-arm64
2.3.3-bionic-ppc64el
2.3.3-bionic-s390x
2.3.3-centos7-amd64
2.3.3-trusty-amd64
2.3.3-trusty-arm64
2.3.3-trusty-ppc64el
2.3.3-trusty-s390x
2.3.3-win10-amd64
2.3.3-win2012-amd64
2.3.3-win2012hv-amd64
2.3.3-win2012hvr2-amd64
2.3.3-win2012r2-amd64
2.3.3-win2016-amd64
2.3.3-win2016nano-amd64
2.3.3-win7-amd64
2.3.3-win8-amd64
2.3.3-win81-amd64
2.3.3-xenial-amd64
2.3.3-xenial-arm64
2.3.3-xenial-ppc64el
2.3.3-xenial-s390x
best version:
2.3.3
17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
17:16:22 DEBUG juju.api monitor.go:35 RPC connection died
ERROR a hosted model cannot have a higher version than the server model: 2.3.3
> 2.3.2
17:16:22 DEBUG cmd supercommand.go:459 error stack:
a hosted model cannot have a higher version than the server model: 2.3.3 > 2.3.2
github.com/juju/juju/rpc/client.go:149:
github.com/juju/juju/api/apiclient.go:924:
I am a little baffled at what the problem might be. This controller has no vm
associated with it.
--
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
redhat, centos, oracle linux images for vmware deployment
Where do I find the images that are used by juju to deploy to a vsphere controller? My ubuntu systems come up great, but unfortunately I need to deploy some red hat/centos/oracle linux vms also, but juju deploy doesn't seem to be able to find them. Is this an area that needs someone to get involved with? -- 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
Re: juju deploys with a vsphere controller using hardware vm version 10
Yes, that would be great! I am sure that 14 will become available soon with a patch to vmware. We are vmware version 6.5 which only presents us with version 13. There are supposed to be some significant performance improvements between 10 and 13. On Wed, 2018-02-07 at 12:24 +1000, Ian Booth wrote: > Hi Daniel > > The Juju vSphere provider currently only supports hardware version > 10, but 14 is > now the most recent according to the VMWare website. If we were > simply to track > and support the most recent hardware version, would that work for > you? > > On 05/02/18 12:38, Daniel Bidwell wrote: > > > > Is there anyway to make the vsphere controller to deploy vms with > > hardware vm version 13 instead of version 10? > > -- 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
juju deploys with a vsphere controller using hardware vm version 10
Is there anyway to make the vsphere controller to deploy vms with hardware vm version 13 instead of version 10? -- 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
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 <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
juju juju-upgrade -m controller woes
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
killing old dead controllers
I have a machine with 2 dead controllers that I can't figure out how to delete. A "juju controllers" produces the following: root@juju:~# juju controllers Use --refresh flag with this command to see the latest information. Controller ModelUser Access Cloud/Region Models Machines HA Version lxd-test-admin superuser lxd/localhost 2 1 none 2.0.2 test-lxd* default admin superuser localhost/localhost 2 1 none 2.1.3 lxc list produces: root@juju:~# lxc list +--+---+--+--+--+---+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +--+---+--+--+--+---+ Any attemtp to remove, delete, kill, or destroy results in the command hanging and never coming back. I have been trying to develop some local charms using lxd. I know that this kind of testing and developemnt is hard on vms/containers, but throwing away the vm and reinstalling ubuntu is probably not the desired behaviour. -- 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
How to kill my model?
I am running juju version 2.0.2 with maas 2.1 and am trying to destory my environment so I can start over again with it. juju status looks like: $ juju status ModelController Cloud/Region Version default maasmaster-controller maasmaster2.0.1 App Version Status Scale Charm Store Rev OS Notes Unit Workload Agent Machine Public address Ports Message Machine StateDNS Inst id Series AZ 0started 10.20.9.129 4y3h7q xenial acauits 1started 10.20.9.130 4y3h7r xenial acauits 2stopped 10.20.9.131 4y3h7s xenial acauits 3started 10.20.9.132 xsngbs xenial acauits There are no apps running. All of the machines are removed and ready for redeployment. juju destroy-model default just keeps spinning with: Waiting on model to be removed, 4 machine(s)... Waiting on model to be removed, 4 machine(s)... Waiting on model to be removed, 4 machine(s)... Waiting on model to be removed, 4 machine(s)... Waiting on model to be removed, 4 machine(s)... Waiting on model to be removed, 4 machine(s)... Waiting on model to be removed, 4 machine(s)... Waiting on model to be removed, 4 machine(s)... Waiting on model to be removed, 4 machine(s)... Waiting on model to be removed, 4 machine(s)... How do I kill this sucker so I can move on? -- 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
juju-1.25.6 on xenial not using lxd containers
I have juju-1.25.6 on xenial and am trying to configure it to use the local lxc containers. I have lxd configured to use a zfs volume for containers. My .juju/environment.yaml looks like: local: type: local lxc-clone: true root-dir: /envision/lxc network-bridge: lxdbr0 default-series: trusty lxd is configured correctly to use the zfs storage. When I do the juju bootstrap and deploys, they look like containers but do not show up in "lxc list". They are also stored in /var/lib/... They look like old style lxc containers instead of lxd containers. What do I need to do differently to get juju to use the lxc launch containers? -- 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
1.25.6-xenial-amd64 and lxc containers
What do I have to put in my .juju/environment.yaml to get juju-1.25.6- xenial-amd64 to use lxc containers? -- 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
maas 1.9.4 commissioning fails
I have maas 1.9.4 on trusty. My server has been enlisted, does wake on lan, and commissions. It pxe boots and runs the cloud-init stuff, updates the maas server with its CPUs, memory, and disks, etc, but changes its status to commissioning failed. Where do I find the logs as to why it has failed? I don't see anything helpful on the maas server in /var/log/maas. From watching the console as it runs through everything it looks ok, what I can see as it flies by. Then it powers itself down. -- 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
juju beta upgrade woes
using juju-2.0 beta 9 or 10 I bootstrapped a local/lxd instance and installed wordpress on it. The containers are running. Now juju has upgraded to 2.0 beta 11 and "juju status" returns: ERERROR connecting with bootstrap config: getting API info: model is not bootstrapped juju controllers returns: CONCONTROLLER MODELUSER CLOUD/REGION local.wp* default admin@local Is there a way for me to "get it back" or do I just need to blow it away and start again? Should I be dropping back to juju 1.25.x for this? -- 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
Re: lxd init on 16.04
I tried the "dpkg-reconfigure lxd" several times and it didn't make any difference. I discovered that I had an old lxc package that was installed and upgraded to lxc1. I removed lxc1 and lxc-net and tried to purge all of their old config files. I then did the "dpkg-reconfiugre lxd" again and "lxd init". Still no luck. I looked in /var/lib/lxd and removed all of the image files. There was still a directory in /var/lib/lxd/images of d69bf4853c7b88399d57bcbb4250798d93de0aa9a10f104fbb0902573e1dfef0.zfs which I had to unmount. The directory that it was supposed to have been mounted from was not visible. Still no luck with the "lxd init". I want to make lxd get it's storage from my zfs file system. What else might lxd be looking at that needs to be cleaned out? On Wed, 2016-05-11 at 11:41 +0400, John Meinel wrote: > If you have a container or images, you can't run LXD init, because it > would potentially change the storage backend, etc. If you already had > LXD up and running, what were you looking to do with LXD init ? It is > possible that you could delete all of your instances and images and > then run it. Or you could directly set the configuration you need > "lxc config set ???". You can set core.trust_password, > core.https_address. I don't think you can set the storage backend, > because then you'd have to migrate all of your data over, which is > the same thing as deleting it and running 'lxd init' and then > starting fresh. > > John > =:-> On Wed, 2016-05-11 at 14:22 -0700, Reed O'Brien wrote: > I think you have to run `sudo dpk-reconfigure lxd` first. > > See https://insights.ubuntu.com/2016/04/07/lxd-networking-lxdbr0-expl > ained/ > > See also some notes I wrote: > https://github.com/reedobrien/juju-notes/blob/master/writing-a-ci-tes > t.md#install-lxd > > Cheers, > Reed > > On Wed, May 11, 2016 at 1:35 PM, Daniel Bidwell <drbidw...@gmail.com> > wrote: > > I just upgraded a machine to 16.04 and tried to do an "lxd init" > > and > > received an err of "LXD init cannot be used at this time". What > > causes > > this? What do I have to clear out to make it work correctly? > > -- > > 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 > > > > > -- > Reed O'Brien > ✉ reed.obr...@canonical.com > ✆ 415-562-6797 > -- 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
lxd init on 16.04
I just upgraded a machine to 16.04 and tried to do an "lxd init" and received an err of "LXD init cannot be used at this time". What causes this? What do I have to clear out to make it work correctly? -- 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
Re: juju 2.0-alpha2 with lxd
I am running 15.10 wiley with lxd version 0.20. Ooops. It looks like golang wasn't installed. Getting it and trying again. Thanks. On Sun, 2016-02-14 at 23:55 +, Marco Ceppi wrote: > What version of Ubuntu are you using? If it's anything other than > Xenial or Wily the LXD provider won't work. LXD bindings require a > golang version that's too new for Trusty. > > On Sun, Feb 14, 2016 at 6:14 PM Daniel Bidwell <drbidw...@gmail.com> > wrote: > > I am trying to bootstrap lxd. > > > > I started with 'juju init' and then 'juju -v --debug bootstrap -m > > lxd' > > It allocated a container and deployed to it and ended with the > > following lines of debug output: > > > > 2016-02-14 23:04:46 INFO juju.cmd supercommand.go:59 running jujud > > [2.0 > > -alpha2 gc go1.2.1] > > 2016-02-14 23:04:46 DEBUG juju.agent agent.go:506 read agent > > config, > > format "1.18" > > 2016-02-14 23:04:46 INFO juju.network network.go:248 setting prefer > > -ipv6 to false > > 2016-02-14 23:04:46 ERROR cmd supercommand.go:448 no registered > > provider for "lxd" > > 2016-02-14 23:04:46 ERROR cmd supercommand.go:448 failed to > > bootstrap > > model: subprocess encountered error code 1 > > > > What do I have to do to "register the lxd provider"? Is this done > > before the boostrap command, during, or after? > > > > A 'juju status' command hangs for ever. Another 'juju bootstrap' > > command starts out happy, but then tells me that lxd is already > > deployed. I can 'ssh ubuntu@10.0.3.x' and get into the container > > just > > fine, but not 'juju ssh 0'. > > > > What am I missing? > > -- > > 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
juju 2.0-alpha2 with lxd
I am trying to bootstrap lxd. I started with 'juju init' and then 'juju -v --debug bootstrap -m lxd' It allocated a container and deployed to it and ended with the following lines of debug output: 2016-02-14 23:04:46 INFO juju.cmd supercommand.go:59 running jujud [2.0 -alpha2 gc go1.2.1] 2016-02-14 23:04:46 DEBUG juju.agent agent.go:506 read agent config, format "1.18" 2016-02-14 23:04:46 INFO juju.network network.go:248 setting prefer -ipv6 to false 2016-02-14 23:04:46 ERROR cmd supercommand.go:448 no registered provider for "lxd" 2016-02-14 23:04:46 ERROR cmd supercommand.go:448 failed to bootstrap model: subprocess encountered error code 1 What do I have to do to "register the lxd provider"? Is this done before the boostrap command, during, or after? A 'juju status' command hangs for ever. Another 'juju bootstrap' command starts out happy, but then tells me that lxd is already deployed. I can 'ssh ubuntu@10.0.3.x' and get into the container just fine, but not 'juju ssh 0'. What am I missing? -- 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
