Re: LXD bootstrap inside KVM failed

[John Meinel]

If you set up a space in MAAS and you declare that the VM is in that space,
then when you deploy something into a container, MAAS and Juju will
coordinate to get a Container set up onto a bridge connected to the
interface in the VM that is connected to the same space, with an IP address
from the range you declared in MAAS for that space and subnet. This also
scales to support multiple interfaces in different spaces, and however many
containers you request.
The only reason you end up private, is because you probably haven't
actually asked to be anywhere else. (Note this works the same for a machine
that is actually a VM as for a physical machine.)

John
=:->


On Tue, Aug 8, 2017 at 2:06 PM, Muhammad Yousuf Khan 
wrote:

> Thank you very much for the understanding right Mark. yes you are connect
> i was doing that however on your advice i manage to install it on new VM
> now one step is clear. but the problem is i notice. LXD is creating its own
> subnet and hide the guest behind the NAT. now the problem is how can LAN
> computers see LXD containers behind NAT. can't we use it the way we use it
> in bridge style. where it get the IP from LAN DHCP? instead of hiding
> behind NAT?
>
> in the context of same case. the whole idea deploying services like mysql,
> kyenotes any others will be fail as all the services will be behind NAT how
> come openstack services will integrate each other.
>
> Any knowledge sharing and tip will be highly appreciated.
> Thank,
> MYK
>
>
>
> On Tue, Aug 8, 2017 at 1:07 PM, Mark Shuttleworth  wrote:
>
>> On 08/08/17 08:31, Ante Karamatić wrote:
>>
>> If you want to run LXD on the same host where bind is running, you just
>> have to configure bind to *not* listen on LXD network:
>>
>> https://www.cyberciti.biz/faq/unix-linux-bsd-bind-dns-listen
>> on-configuration/
>>
>> uto, 8. kol 2017. 09:04 Muhammad Yousuf Khan  je
>> napisao:
>>
>>> Thanks for the update Ante. but since MAAS also used Bind for its own
>>> DNS resolution. how come one can use juju or lxd in absence of bind.
>>> any tip will be highly appreciated.
>>>
>>> Thanks,
>>> MYK
>>>
>>
>> MYK, if I understand your problem, you are running a MAAS controller on
>> the VM (which means bind is running) and you want to bootstrap a LXD
>> localhost Juju controller on that same machine. The question is why you
>> need to bootstrap a local Juju on a MAAS controller?
>>
>> As Ante says, you can configure the MAAS bind to avoid grabbing the lxd
>> network interfaces, which ill allow LXD's dnsmasq to work alongside bind
>> (because bind is focused on the main network interfaces, and dnsmasq is
>> grabbing the lxd network interfaces). But that's fiddly, you would need to
>> look carefully over the bind config files and make sure you don't
>> inadvertently break MAAS. If you are not familiar with bind configuration,
>> I don't recommend this approach.
>>
>> The easy answer is just to create a separate VM that points resolv.conf
>> at the MAAS DNS server, and bootstrap Juju locally in that VM. You can even
>> IIRC use MAAS to create that new VM, using the 'pod' functionality in 2.2.
>>
>> Mark
>>
>
>
> --
> 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: LXD bootstrap inside KVM failed

[Muhammad Yousuf Khan]

Thanks Alot mark for sharing your though i appreciate help from everyone in
this forum. btw i am not the geek but i think i did it. for me below trick
is working. Being part of the community i believe in sharing. i did it like
this.

on a system other then MAAS (Member of MAAS ofcourse)

- ssh to the host.

- install pkg bridge-utils.

- sudo nano /etc/network/interfaces

(my default interface file )
auto lo
iface lo inet loopback
dns-nameservers 10.x.x.10
dns-search maas

auto enp0s25
iface enp0s25 inet static
   gateway 10.x.x.1
   address 10.x.x.166/24
   mtu 1500
auto enp3s0
iface enp3s0 inet manual
mtu 1500

(My interface file after making changes)
auto lo
iface lo inet loopback
dns-nameservers 10.x.x.10
dns-search maas

auto enp0s25
#iface enp0s25 inet static
#   gateway 10.x.x.1
#   address 10.x.x.166/24
#   mtu 1500
auto br0
iface br0 inet static
gateway 10.x.x.1
address 10.x.x.166/24
bridge-ifaces enp0s25
bridge-ports enp0s25
up ifconfig enp0s25 up
iface enp0s25 inet manual


auto enp3s0
iface enp3s0 inet manual
mtu 1500



( at this point bring up your bridge interface br0)
and also "sudo passwd ubuntu" because there are changes that you may loose
the ssh via MAAS due to change in ip so that you can access the machine via
console monitor.

( next )

- install pkg lxc
- sed -i 's/lxc.network.link = lxcbr0/lxc.network.link = br0/'
/etc/lxc/default.conf
( this command use to change the bridge interface name in lxc file)

- lxc profile edit default

thats all. i can now access juju GUI. i belive this process should be
followed on every machine that you wana bridge to LAN. not just for JUJU
bootstramp.

for more details please visit this link

https://insights.ubuntu.com/2015/11/10/converting-eth0-to-br0-and-getting-all-your-lxc-or-lxd-onto-your-lan/


now juju bootstrap
you will see it will bind the IP from your LAN. :) hope this help someone.

Thanks,
MYK








On Tue, Aug 8, 2017 at 4:03 PM, Mark Shuttleworth  wrote:

>
> Well, everything you want to do here is cleanly possible with MAAS, Juju
> and LXD, but you will need to dig into the tools and understand how the
> model in Juju describes machines and networking.
>
> Last, there is a particular set of gotchas around networking (which as you
> point out is the tricky part in general) with containers. This is a
> development focus in Juju currently and we hope to have a crisp "just
> works" story for MAAS and some public clouds by 2.3.0. Till then you will
> need to be something of an expert, but if you figure that out, it's amazing
> what is possible.
>
> Mark
>
>
> On 08/08/17 11:06, Muhammad Yousuf Khan wrote:
>
> Thank you very much for the understanding right Mark. yes you are connect
> i was doing that however on your advice i manage to install it on new VM
> now one step is clear. but the problem is i notice. LXD is creating its own
> subnet and hide the guest behind the NAT. now the problem is how can LAN
> computers see LXD containers behind NAT. can't we use it the way we use it
> in bridge style. where it get the IP from LAN DHCP? instead of hiding
> behind NAT?
>
> in the context of same case. the whole idea deploying services like mysql,
> kyenotes any others will be fail as all the services will be behind NAT how
> come openstack services will integrate each other.
>
> Any knowledge sharing and tip will be highly appreciated.
> Thank,
> MYK
>
>
>
> On Tue, Aug 8, 2017 at 1:07 PM, Mark Shuttleworth  wrote:
>
>> On 08/08/17 08:31, Ante Karamatić wrote:
>>
>> If you want to run LXD on the same host where bind is running, you just
>> have to configure bind to *not* listen on LXD network:
>>
>> https://www.cyberciti.biz/faq/unix-linux-bsd-bind-dns-listen
>> on-configuration/
>>
>> uto, 8. kol 2017. 09:04 Muhammad Yousuf Khan  je
>> napisao:
>>
>>> Thanks for the update Ante. but since MAAS also used Bind for its own
>>> DNS resolution. how come one can use juju or lxd in absence of bind.
>>> any tip will be highly appreciated.
>>>
>>> Thanks,
>>> MYK
>>>
>>
>> MYK, if I understand your problem, you are running a MAAS controller on
>> the VM (which means bind is running) and you want to bootstrap a LXD
>> localhost Juju controller on that same machine. The question is why you
>> need to bootstrap a local Juju on a MAAS controller?
>>
>> As Ante says, you can configure the MAAS bind to avoid grabbing the lxd
>> network interfaces, which ill allow LXD's dnsmasq to work alongside bind
>> (because bind is focused on the main network interfaces, and dnsmasq is
>> grabbing the lxd network interfaces). But that's fiddly, you would need to
>> look carefully over the bind config files and make sure you don't
>> inadvertently break MAAS. If you are not familiar with bind configuration,
>> I don't recommend this approach.
>>
>> The easy answer is just to create a separate VM that points resolv.conf
>> at the MAAS DNS server, and bootstrap Juju locally in that VM. You can even
>> IIRC use MAAS to create th

Re: LXD bootstrap inside KVM failed

[Mark Shuttleworth]

Well, everything you want to do here is cleanly possible with MAAS, Juju
and LXD, but you will need to dig into the tools and understand how the
model in Juju describes machines and networking.

Last, there is a particular set of gotchas around networking (which as
you point out is the tricky part in general) with containers. This is a
development focus in Juju currently and we hope to have a crisp "just
works" story for MAAS and some public clouds by 2.3.0. Till then you
will need to be something of an expert, but if you figure that out, it's
amazing what is possible.

Mark

On 08/08/17 11:06, Muhammad Yousuf Khan wrote:
> Thank you very much for the understanding right Mark. yes you are
> connect i was doing that however on your advice i manage to install it
> on new VM now one step is clear. but the problem is i notice. LXD is
> creating its own subnet and hide the guest behind the NAT. now the
> problem is how can LAN computers see LXD containers behind NAT. can't
> we use it the way we use it in bridge style. where it get the IP from
> LAN DHCP? instead of hiding behind NAT?
>
> in the context of same case. the whole idea deploying services like
> mysql, kyenotes any others will be fail as all the services will be
> behind NAT how come openstack services will integrate each other.
>
> Any knowledge sharing and tip will be highly appreciated.
> Thank,
> MYK
>
>
>
> On Tue, Aug 8, 2017 at 1:07 PM, Mark Shuttleworth  > wrote:
>
> On 08/08/17 08:31, Ante Karamatić wrote:
>> If you want to run LXD on the same host where bind is running,
>> you just have to configure bind to *not* listen on LXD network:
>>
>> 
>> https://www.cyberciti.biz/faq/unix-linux-bsd-bind-dns-listenon-configuration/
>> 
>> 
>>
>> uto, 8. kol 2017. 09:04 Muhammad Yousuf Khan > > je napisao:
>>
>> Thanks for the update Ante. but since MAAS also used Bind for
>> its own DNS resolution. how come one can use juju or lxd in
>> absence of bind. 
>> any tip will be highly appreciated.
>>
>> Thanks,
>> MYK
>>
>
> MYK, if I understand your problem, you are running a MAAS
> controller on the VM (which means bind is running) and you want to
> bootstrap a LXD localhost Juju controller on that same machine.
> The question is why you need to bootstrap a local Juju on a MAAS
> controller?
>
> As Ante says, you can configure the MAAS bind to avoid grabbing
> the lxd network interfaces, which ill allow LXD's dnsmasq to work
> alongside bind (because bind is focused on the main network
> interfaces, and dnsmasq is grabbing the lxd network interfaces).
> But that's fiddly, you would need to look carefully over the bind
> config files and make sure you don't inadvertently break MAAS. If
> you are not familiar with bind configuration, I don't recommend
> this approach.
>
> The easy answer is just to create a separate VM that points
> resolv.conf at the MAAS DNS server, and bootstrap Juju locally in
> that VM. You can even IIRC use MAAS to create that new VM, using
> the 'pod' functionality in 2.2.
>
> Mark
>
>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD bootstrap inside KVM failed

[Muhammad Yousuf Khan]

Thank you very much for the understanding right Mark. yes you are connect i
was doing that however on your advice i manage to install it on new VM now
one step is clear. but the problem is i notice. LXD is creating its own
subnet and hide the guest behind the NAT. now the problem is how can LAN
computers see LXD containers behind NAT. can't we use it the way we use it
in bridge style. where it get the IP from LAN DHCP? instead of hiding
behind NAT?

in the context of same case. the whole idea deploying services like mysql,
kyenotes any others will be fail as all the services will be behind NAT how
come openstack services will integrate each other.

Any knowledge sharing and tip will be highly appreciated.
Thank,
MYK



On Tue, Aug 8, 2017 at 1:07 PM, Mark Shuttleworth  wrote:

> On 08/08/17 08:31, Ante Karamatić wrote:
>
> If you want to run LXD on the same host where bind is running, you just
> have to configure bind to *not* listen on LXD network:
>
> https://www.cyberciti.biz/faq/unix-linux-bsd-bind-dns-
> listenon-configuration/
>
> uto, 8. kol 2017. 09:04 Muhammad Yousuf Khan  je
> napisao:
>
>> Thanks for the update Ante. but since MAAS also used Bind for its own DNS
>> resolution. how come one can use juju or lxd in absence of bind.
>> any tip will be highly appreciated.
>>
>> Thanks,
>> MYK
>>
>
> MYK, if I understand your problem, you are running a MAAS controller on
> the VM (which means bind is running) and you want to bootstrap a LXD
> localhost Juju controller on that same machine. The question is why you
> need to bootstrap a local Juju on a MAAS controller?
>
> As Ante says, you can configure the MAAS bind to avoid grabbing the lxd
> network interfaces, which ill allow LXD's dnsmasq to work alongside bind
> (because bind is focused on the main network interfaces, and dnsmasq is
> grabbing the lxd network interfaces). But that's fiddly, you would need to
> look carefully over the bind config files and make sure you don't
> inadvertently break MAAS. If you are not familiar with bind configuration,
> I don't recommend this approach.
>
> The easy answer is just to create a separate VM that points resolv.conf at
> the MAAS DNS server, and bootstrap Juju locally in that VM. You can even
> IIRC use MAAS to create that new VM, using the 'pod' functionality in 2.2.
>
> Mark
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD bootstrap inside KVM failed

[Mark Shuttleworth]

On 08/08/17 08:31, Ante Karamatić wrote:
> If you want to run LXD on the same host where bind is running, you
> just have to configure bind to *not* listen on LXD network:
>
> https://www.cyberciti.biz/faq/unix-linux-bsd-bind-dns-listenon-configuration/
>
> uto, 8. kol 2017. 09:04 Muhammad Yousuf Khan  > je napisao:
>
> Thanks for the update Ante. but since MAAS also used Bind for its
> own DNS resolution. how come one can use juju or lxd in absence of
> bind. 
> any tip will be highly appreciated.
>
> Thanks,
> MYK
>

MYK, if I understand your problem, you are running a MAAS controller on
the VM (which means bind is running) and you want to bootstrap a LXD
localhost Juju controller on that same machine. The question is why you
need to bootstrap a local Juju on a MAAS controller?

As Ante says, you can configure the MAAS bind to avoid grabbing the lxd
network interfaces, which ill allow LXD's dnsmasq to work alongside bind
(because bind is focused on the main network interfaces, and dnsmasq is
grabbing the lxd network interfaces). But that's fiddly, you would need
to look carefully over the bind config files and make sure you don't
inadvertently break MAAS. If you are not familiar with bind
configuration, I don't recommend this approach.

The easy answer is just to create a separate VM that points resolv.conf
at the MAAS DNS server, and bootstrap Juju locally in that VM. You can
even IIRC use MAAS to create that new VM, using the 'pod' functionality
in 2.2.

Mark
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD bootstrap inside KVM failed

[Ante Karamatić]

If you want to run LXD on the same host where bind is running, you just
have to configure bind to *not* listen on LXD network:

https://www.cyberciti.biz/faq/unix-linux-bsd-bind-dns-listenon-configuration/

uto, 8. kol 2017. 09:04 Muhammad Yousuf Khan  je napisao:

> Thanks for the update Ante. but since MAAS also used Bind for its own DNS
> resolution. how come one can use juju or lxd in absence of bind.
> any tip will be highly appreciated.
>
> Thanks,
> MYK
>
> On Tue, Aug 8, 2017 at 11:19 AM, Ante Karamatić <
> ante.karama...@canonical.com> wrote:
>
>> When one installs bind, and doesn't configure it, it listens on all
>> interfaces.
>>
>> Since LXD uses dnsmasq on LXD network (which uses the same port as bind),
>> starting dnsmasq fails and therefore LXD too.
>>
>> We should not disable people's bind, because they must have installed it
>> for a reason. Maybe bind, by default, should listen only on localhost.
>>
>> Or... LXD systemd service detects running service on port 53 on LXD's
>> network and provides meaningful message.
>>
>> We can't solve this like we did with apache and nginx (autodetect, change
>> port), because dns needs to be on port 53.
>>
>> Either way, juju can't do much here...
>>
>>
>> uto, 8. kol 2017. 03:52 Tim Penhey  je napisao:
>>
>>> Yep, that is pretty strange. Why was bind running?
>>>
>>> Tim
>>>
>>> On 03/08/17 07:45, fengxia wrote:
>>> > For anyone, the solution is rather strange:
>>> >
>>> > $ sudo service stop bind9
>>> >
>>> > $ sudo lxd start
>>> >
>>> > Reference: https://github.com/lxc/lxd/issues/2046
>>> >
>>> >
>>> > On 08/02/2017 03:33 PM, fengxia wrote:
>>> >> Hi Juju,
>>> >>
>>> >> I have a 16.04 KVM. Installed juju and LXD from apt.
>>> >>
>>> >> $ juju bootstrap localhost test
>>> >>
>>> >> ERROR creating LXD client: can't connect to the local LXD server: Get
>>> >> http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read:
>>> >> connection reset by peer
>>> >>
>>> >> Please install LXD by running:
>>> >> $ sudo apt-get install lxd
>>> >> and then configure it with:
>>> >> $ newgrp lxd
>>> >> $ lxd init
>>> >>
>>> >> Tried the suggested commands. Rebooted KVM. No avail.
>>> >>
>>> >> Is this because I'm running LXD inside KVM?
>>> >>
>>> >
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>> --
>> Ante Karamatić
>> ante.karama...@canonical.com
>> Canonical
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
> --
Ante Karamatić
ante.karama...@canonical.com
Canonical
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD bootstrap inside KVM failed

[Muhammad Yousuf Khan]

Thanks for the update Ante. but since MAAS also used Bind for its own DNS
resolution. how come one can use juju or lxd in absence of bind.
any tip will be highly appreciated.

Thanks,
MYK

On Tue, Aug 8, 2017 at 11:19 AM, Ante Karamatić <
ante.karama...@canonical.com> wrote:

> When one installs bind, and doesn't configure it, it listens on all
> interfaces.
>
> Since LXD uses dnsmasq on LXD network (which uses the same port as bind),
> starting dnsmasq fails and therefore LXD too.
>
> We should not disable people's bind, because they must have installed it
> for a reason. Maybe bind, by default, should listen only on localhost.
>
> Or... LXD systemd service detects running service on port 53 on LXD's
> network and provides meaningful message.
>
> We can't solve this like we did with apache and nginx (autodetect, change
> port), because dns needs to be on port 53.
>
> Either way, juju can't do much here...
>
>
> uto, 8. kol 2017. 03:52 Tim Penhey  je napisao:
>
>> Yep, that is pretty strange. Why was bind running?
>>
>> Tim
>>
>> On 03/08/17 07:45, fengxia wrote:
>> > For anyone, the solution is rather strange:
>> >
>> > $ sudo service stop bind9
>> >
>> > $ sudo lxd start
>> >
>> > Reference: https://github.com/lxc/lxd/issues/2046
>> >
>> >
>> > On 08/02/2017 03:33 PM, fengxia wrote:
>> >> Hi Juju,
>> >>
>> >> I have a 16.04 KVM. Installed juju and LXD from apt.
>> >>
>> >> $ juju bootstrap localhost test
>> >>
>> >> ERROR creating LXD client: can't connect to the local LXD server: Get
>> >> http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read:
>> >> connection reset by peer
>> >>
>> >> Please install LXD by running:
>> >> $ sudo apt-get install lxd
>> >> and then configure it with:
>> >> $ newgrp lxd
>> >> $ lxd init
>> >>
>> >> Tried the suggested commands. Rebooted KVM. No avail.
>> >>
>> >> Is this because I'm running LXD inside KVM?
>> >>
>> >
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju
>>
> --
> Ante Karamatić
> ante.karama...@canonical.com
> Canonical
>
> --
> 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: LXD bootstrap inside KVM failed

[Ante Karamatić]

When one installs bind, and doesn't configure it, it listens on all
interfaces.

Since LXD uses dnsmasq on LXD network (which uses the same port as bind),
starting dnsmasq fails and therefore LXD too.

We should not disable people's bind, because they must have installed it
for a reason. Maybe bind, by default, should listen only on localhost.

Or... LXD systemd service detects running service on port 53 on LXD's
network and provides meaningful message.

We can't solve this like we did with apache and nginx (autodetect, change
port), because dns needs to be on port 53.

Either way, juju can't do much here...

uto, 8. kol 2017. 03:52 Tim Penhey  je napisao:

> Yep, that is pretty strange. Why was bind running?
>
> Tim
>
> On 03/08/17 07:45, fengxia wrote:
> > For anyone, the solution is rather strange:
> >
> > $ sudo service stop bind9
> >
> > $ sudo lxd start
> >
> > Reference: https://github.com/lxc/lxd/issues/2046
> >
> >
> > On 08/02/2017 03:33 PM, fengxia wrote:
> >> Hi Juju,
> >>
> >> I have a 16.04 KVM. Installed juju and LXD from apt.
> >>
> >> $ juju bootstrap localhost test
> >>
> >> ERROR creating LXD client: can't connect to the local LXD server: Get
> >> http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read:
> >> connection reset by peer
> >>
> >> Please install LXD by running:
> >> $ sudo apt-get install lxd
> >> and then configure it with:
> >> $ newgrp lxd
> >> $ lxd init
> >>
> >> Tried the suggested commands. Rebooted KVM. No avail.
> >>
> >> Is this because I'm running LXD inside KVM?
> >>
> >
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Ante Karamatić
ante.karama...@canonical.com
Canonical
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD bootstrap inside KVM failed

[Muhammad Yousuf Khan]

Having same issue. And wasted my whole day on this. now after loosing the
battle. I am going to try this on physical server . Hope to see the
solution for this.
On Aug 8, 2017 6:52 AM, "Tim Penhey"  wrote:

> Yep, that is pretty strange. Why was bind running?
>
> Tim
>
> On 03/08/17 07:45, fengxia wrote:
> > For anyone, the solution is rather strange:
> >
> > $ sudo service stop bind9
> >
> > $ sudo lxd start
> >
> > Reference: https://github.com/lxc/lxd/issues/2046
> >
> >
> > On 08/02/2017 03:33 PM, fengxia wrote:
> >> Hi Juju,
> >>
> >> I have a 16.04 KVM. Installed juju and LXD from apt.
> >>
> >> $ juju bootstrap localhost test
> >>
> >> ERROR creating LXD client: can't connect to the local LXD server: Get
> >> http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read:
> >> connection reset by peer
> >>
> >> Please install LXD by running:
> >> $ sudo apt-get install lxd
> >> and then configure it with:
> >> $ newgrp lxd
> >> $ lxd init
> >>
> >> Tried the suggested commands. Rebooted KVM. No avail.
> >>
> >> Is this because I'm running LXD inside KVM?
> >>
> >
>
> --
> 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: LXD bootstrap inside KVM failed

[Tim Penhey]

Yep, that is pretty strange. Why was bind running?

Tim

On 03/08/17 07:45, fengxia wrote:
> For anyone, the solution is rather strange:
> 
> $ sudo service stop bind9
> 
> $ sudo lxd start
> 
> Reference: https://github.com/lxc/lxd/issues/2046
> 
> 
> On 08/02/2017 03:33 PM, fengxia wrote:
>> Hi Juju,
>>
>> I have a 16.04 KVM. Installed juju and LXD from apt.
>>
>> $ juju bootstrap localhost test
>>
>> ERROR creating LXD client: can't connect to the local LXD server: Get
>> http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read:
>> connection reset by peer
>>
>> Please install LXD by running:
>> $ sudo apt-get install lxd
>> and then configure it with:
>> $ newgrp lxd
>> $ lxd init
>>
>> Tried the suggested commands. Rebooted KVM. No avail.
>>
>> Is this because I'm running LXD inside KVM?
>>
> 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD bootstrap inside KVM failed

[fengxia]

For anyone, the solution is rather strange:

$ sudo service stop bind9

$ sudo lxd start

Reference: https://github.com/lxc/lxd/issues/2046


On 08/02/2017 03:33 PM, fengxia wrote:

Hi Juju,

I have a 16.04 KVM. Installed juju and LXD from apt.

$ juju bootstrap localhost test

ERROR creating LXD client: can't connect to the local LXD server: Get 
http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read: 
connection reset by peer


Please install LXD by running:
$ sudo apt-get install lxd
and then configure it with:
$ newgrp lxd
$ lxd init

Tried the suggested commands. Rebooted KVM. No avail.

Is this because I'm running LXD inside KVM?



--
Feng xia
Engineer
Lenovo USA

Phone: 5088011794
fx...@lenovo.com

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums


--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD bootstrap inside KVM failed

[fengxia]

When running the service:

$ sudo service lxd start

Failed with:

A dependency job for lxd.service failed. See 'journalctl -xe' for details.

More info from $ service lxd status:

-- Subject: Unit lxd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit lxd.service has failed.
--
-- The result is dependency.
Aug 02 15:40:00 mail.lctc-buildbot.labs.lenovo.com systemd[1]: 
lxd.service: Job lxd.service/start failed with result 'dependency'.
Aug 02 15:40:00 mail.lctc-buildbot.labs.lenovo.com systemd[1]: 
lxd-bridge.service: Unit entered failed state.
Aug 02 15:40:00 mail.lctc-buildbot.labs.lenovo.com systemd[1]: 
lxd-bridge.service: Failed with result 'exit-code'.
Aug 02 15:40:01 mail.lctc-buildbot.labs.lenovo.com CRON[4314]: 
pam_unix(cron:session): session opened for user www-data by (uid=0)
Aug 02 15:40:01 mail.lctc-buildbot.labs.lenovo.com CRON[4317]: 
(www-data) CMD ([ -x /usr/share/awstats/tools/update.sh ] && 
/usr/share/awstats/tools/update.sh)
Aug 02 15:40:01 mail.lctc-buildbot.labs.lenovo.com CRON[4314]: 
pam_unix(cron:session): session closed for user www-data
Aug 02 15:40:01 mail.lctc-buildbot.labs.lenovo.com CRON[4315]: 
pam_unix(cron:session): session opened for user root by (uid=0)
Aug 02 15:40:01 mail.lctc-buildbot.labs.lenovo.com CRON[4321]: (root) 
CMD (   test -x /etc/cron.daily/popularity-contest && 
/etc/cron.daily/popularity-contest --crond
Aug 02 15:40:01 mail.lctc-buildbot.labs.lenovo.com CRON[4316]: 
pam_unix(cron:session): session opened for user sogo by (uid=0)
Aug 02 15:40:01 mail.lctc-buildbot.labs.lenovo.com CRON[4322]: (sogo) 
CMD (/usr/sbin/sogo-tool expire-sessions 30 >/dev/null 2>&1; 
/usr/sbin/sogo-ealarms-notify >/dev
Aug 02 15:40:01 mail.lctc-buildbot.labs.lenovo.com CRON[4315]: 
pam_unix(cron:session): session closed for user root
Aug 02 15:40:02 mail.lctc-buildbot.labs.lenovo.com CRON[4316]: 
pam_unix(cron:session): session closed for user sogo




On 08/02/2017 03:33 PM, fengxia wrote:

Hi Juju,

I have a 16.04 KVM. Installed juju and LXD from apt.

$ juju bootstrap localhost test

ERROR creating LXD client: can't connect to the local LXD server: Get 
http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read: 
connection reset by peer


Please install LXD by running:
$ sudo apt-get install lxd
and then configure it with:
$ newgrp lxd
$ lxd init

Tried the suggested commands. Rebooted KVM. No avail.

Is this because I'm running LXD inside KVM?



--
Feng xia
Engineer
Lenovo USA

Phone: 5088011794
fx...@lenovo.com

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums


--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD bootstrap inside KVM failed

[fengxia]

Here is an update. Manually run this command,

$ sudo lxd --group lxd

Then $ lxc list works. So the LXD service was not started after reboot. 
Permission issue?


On 08/02/2017 03:33 PM, fengxia wrote:

Hi Juju,

I have a 16.04 KVM. Installed juju and LXD from apt.

$ juju bootstrap localhost test

ERROR creating LXD client: can't connect to the local LXD server: Get 
http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read: 
connection reset by peer


Please install LXD by running:
$ sudo apt-get install lxd
and then configure it with:
$ newgrp lxd
$ lxd init

Tried the suggested commands. Rebooted KVM. No avail.

Is this because I'm running LXD inside KVM?



--
Feng xia
Engineer
Lenovo USA

Phone: 5088011794
fx...@lenovo.com

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums


--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Casey Marshall]

On Mon, Feb 29, 2016 at 5:35 PM, Serge E. Hallyn  wrote:

> Hi Casey,
>
> I haven't reproduced that here in VMs.  If you can reproduce this at will
> (by
> rebooting the host) could you file a bug against the kernel (
> pad.lv/u/linux) ?
>

Saw it again after booting up my laptop this morning, opened a bug:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1551854


>
> thanks,
> -serge
>
> Quoting Casey Marshall (casey.marsh...@canonical.com):
> > On Mon, Feb 29, 2016 at 4:57 PM, Tom Barber 
> wrote:
> >
> > > Seemingly the image name and key are the same, LXD and Juju are the
> same,
> > > so you've either done something magic or I'm confused with its now
> seeming
> > > happiness of the kernel debug mountpoint! :)
> > >
> >
> > I ran into a similar issue today. xenial host, running latest juju out of
> > master for LXD API compatibility. I was unable to bootstrap and sshd was
> > not starting in the controller instance.
> >
> > Remounted kernel debug on the host, and bootstrap started working, sshd
> > starting up now in my trusty instances.
> >
> > Did not refresh my images. If it happens after rebooting the host, I'll
> try
> > to collect more info.
> >
> > -Casey
> >
> >
> > > --
> > >
> > > Director Meteorite.bi - Saiku Analytics Founder
> > > Tel: +44(0)5603641316
> > >
> > > (Thanks to the Saiku community we reached our Kickstart
> > > <
> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
> >
> > > goal, but you can always help by sponsoring the project
> > > )
> > >
> > > On 29 February 2016 at 22:43, Tom Barber 
> wrote:
> > >
> > >> Hi Serge
> > >>
> > >> Fresh reboot and updated image, image boots with SSHD working fine, so
> > >> whatever you did, i assume worked or is a freak occurrence. I don't
> have
> > >> any old images kicking around and the import I copied from your email
> > >> appears to have stomped on the old image.
> > >>
> > >> FYI
> > >>
> > >> bugg@tomsdevbox:~$ lxc config show t1
> > >> name: t1
> > >> profiles:
> > >> - default
> > >> config:
> > >>   volatile.base_image:
> > >> 510c27eb5e30ac53c6cf8b423d4e145bd2e40b8845e89bd66a5d78e2a087727a
> > >>   volatile.eth0.hwaddr: 00:16:3e:94:d5:66
> > >>   volatile.last_state.idmap:
> > >>
> '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
> > >>   volatile.lo.hwaddr: 00:16:3e:d2:98:62
> > >> devices:
> > >>   root:
> > >> path: /
> > >> type: disk
> > >> ephemeral: false
> > >>
> > >>
> > >> juju bootstrap now seems to run fine without remounting the kernel
> debug.
> > >>
> > >> Thanks for your help!
> > >>
> > >> Tom
> > >>
> > >>
> > >> --
> > >>
> > >> Director Meteorite.bi - Saiku Analytics Founder
> > >> Tel: +44(0)5603641316
> > >>
> > >> (Thanks to the Saiku community we reached our Kickstart
> > >> <
> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
> >
> > >> goal, but you can always help by sponsoring the project
> > >> )
> > >>
> > >> On 29 February 2016 at 21:45, Serge E. Hallyn 
> wrote:
> > >>
> > >>> On Mon, Feb 29, 2016 at 09:45:14AM +, Tom Barber wrote:
> > >>> > Hi Serge
> > >>> >
> > >>> > I rebooted the host to see what happened and the lxc images that
> were
> > >>> > running fine all now have broken SSHD. This, to make absolutely
> clear
> > >>> > doesn't affect the Xenial image, just the trusty one I test with.
> > >>> >
> > >>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2
> > >>> > Creating fix-server2
> > >>> > Starting fix-server2
> > >>> >
> > >>> > bugg@tomsdevbox:~$ lxc exec fix-server2 /bin/bash
> > >>> > root@fix-server2:~# ps aux |grep ssh
> > >>> > root  1597  0.0  0.0   8868   660 ?S+   09:41   0:00
> grep
> > >>> > --color=auto ssh
> > >>> >
> > >>> > exit
> > >>> >
> > >>> > umount and remount kernel debug
> > >>> >
> > >>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server3
> > >>> > Creating fix-server3
> > >>> > Starting fix-server3
> > >>> > bugg@tomsdevbox:~$ lxc exec fix-server3 /bin/bash
> > >>> > root@fix-server3:~# ps aux |grep ssh
> > >>> > root  1759  0.0  0.0  61380  3816 ?Ss   09:42   0:00
> > >>> > /usr/sbin/sshd -D
> > >>> > root  1944  0.0  0.0   8868   604 ?S+   09:43   0:00
> grep
> > >>> > --color=auto ssh
> > >>>
> > >>> If you pull a fresh image using
> > >>>
> > >>> lxd-images import ubuntu --alias newtrusty trusty amd64
> > >>>
> > >>> and launch that
> > >>>
> > >>> lxc launch newtrusty t1
> > >>>
> > >>> does it have the same failure?
> > >>>
> > >>> What does
> > >>>
> > >>> lxc config show fix-server2 show?
> > >>>
> > >>
> > >>
> > >
> > > --
> > > Juju mailing list
> > > Juju@lists.ubuntu.com
> > > Modify settings or unsubscribe at:
> > > https://lists.ubuntu.com/mailman/listinfo/juju
> > >
> > >

Re: LXD Bootstrap

[Tom Barber]

Okay we're back.

Here is the /proc/mount stuff:

http://paste.ubuntu.com/15260347/
http://paste.ubuntu.com/15260350/

You can see a bit of a diff after the remount, hope it helps!

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 29 February 2016 at 23:38, Tom Barber  wrote:

> Its pretty weird, because a few reboots and it failed, now its magically
> working post reboot. Worst comes to the worst I can flatten the machine
> again and I'm sure it will reappear as it did the previous 2 occasions.
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 29 February 2016 at 23:35, Serge E. Hallyn  wrote:
>
>> Hi Casey,
>>
>> I haven't reproduced that here in VMs.  If you can reproduce this at will
>> (by
>> rebooting the host) could you file a bug against the kernel (
>> pad.lv/u/linux) ?
>>
>> thanks,
>> -serge
>>
>> Quoting Casey Marshall (casey.marsh...@canonical.com):
>> > On Mon, Feb 29, 2016 at 4:57 PM, Tom Barber 
>> wrote:
>> >
>> > > Seemingly the image name and key are the same, LXD and Juju are the
>> same,
>> > > so you've either done something magic or I'm confused with its now
>> seeming
>> > > happiness of the kernel debug mountpoint! :)
>> > >
>> >
>> > I ran into a similar issue today. xenial host, running latest juju out
>> of
>> > master for LXD API compatibility. I was unable to bootstrap and sshd was
>> > not starting in the controller instance.
>> >
>> > Remounted kernel debug on the host, and bootstrap started working, sshd
>> > starting up now in my trusty instances.
>> >
>> > Did not refresh my images. If it happens after rebooting the host, I'll
>> try
>> > to collect more info.
>> >
>> > -Casey
>> >
>> >
>> > > --
>> > >
>> > > Director Meteorite.bi - Saiku Analytics Founder
>> > > Tel: +44(0)5603641316
>> > >
>> > > (Thanks to the Saiku community we reached our Kickstart
>> > > <
>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>> >
>> > > goal, but you can always help by sponsoring the project
>> > > )
>> > >
>> > > On 29 February 2016 at 22:43, Tom Barber 
>> wrote:
>> > >
>> > >> Hi Serge
>> > >>
>> > >> Fresh reboot and updated image, image boots with SSHD working fine,
>> so
>> > >> whatever you did, i assume worked or is a freak occurrence. I don't
>> have
>> > >> any old images kicking around and the import I copied from your email
>> > >> appears to have stomped on the old image.
>> > >>
>> > >> FYI
>> > >>
>> > >> bugg@tomsdevbox:~$ lxc config show t1
>> > >> name: t1
>> > >> profiles:
>> > >> - default
>> > >> config:
>> > >>   volatile.base_image:
>> > >> 510c27eb5e30ac53c6cf8b423d4e145bd2e40b8845e89bd66a5d78e2a087727a
>> > >>   volatile.eth0.hwaddr: 00:16:3e:94:d5:66
>> > >>   volatile.last_state.idmap:
>> > >>
>> '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
>> > >>   volatile.lo.hwaddr: 00:16:3e:d2:98:62
>> > >> devices:
>> > >>   root:
>> > >> path: /
>> > >> type: disk
>> > >> ephemeral: false
>> > >>
>> > >>
>> > >> juju bootstrap now seems to run fine without remounting the kernel
>> debug.
>> > >>
>> > >> Thanks for your help!
>> > >>
>> > >> Tom
>> > >>
>> > >>
>> > >> --
>> > >>
>> > >> Director Meteorite.bi - Saiku Analytics Founder
>> > >> Tel: +44(0)5603641316
>> > >>
>> > >> (Thanks to the Saiku community we reached our Kickstart
>> > >> <
>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>> >
>> > >> goal, but you can always help by sponsoring the project
>> > >> )
>> > >>
>> > >> On 29 February 2016 at 21:45, Serge E. Hallyn 
>> wrote:
>> > >>
>> > >>> On Mon, Feb 29, 2016 at 09:45:14AM +, Tom Barber wrote:
>> > >>> > Hi Serge
>> > >>> >
>> > >>> > I rebooted the host to see what happened and the lxc images that
>> were
>> > >>> > running fine all now have broken SSHD. This, to make absolutely
>> clear
>> > >>> > doesn't affect the Xenial image, just the trusty one I test with.
>> > >>> >
>> > >>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2
>> > >>> > Creating fix-server2
>> > >>> > Starting fix-server2
>> > >>> >
>> > >>> > bugg@tomsdevbox:~$ lxc exec fix-server2 /bin/bash
>> > >>> > root@fix-server2:~# ps aux |grep s

Re: LXD Bootstrap

[Tom Barber]

Its pretty weird, because a few reboots and it failed, now its magically
working post reboot. Worst comes to the worst I can flatten the machine
again and I'm sure it will reappear as it did the previous 2 occasions.

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 29 February 2016 at 23:35, Serge E. Hallyn  wrote:

> Hi Casey,
>
> I haven't reproduced that here in VMs.  If you can reproduce this at will
> (by
> rebooting the host) could you file a bug against the kernel (
> pad.lv/u/linux) ?
>
> thanks,
> -serge
>
> Quoting Casey Marshall (casey.marsh...@canonical.com):
> > On Mon, Feb 29, 2016 at 4:57 PM, Tom Barber 
> wrote:
> >
> > > Seemingly the image name and key are the same, LXD and Juju are the
> same,
> > > so you've either done something magic or I'm confused with its now
> seeming
> > > happiness of the kernel debug mountpoint! :)
> > >
> >
> > I ran into a similar issue today. xenial host, running latest juju out of
> > master for LXD API compatibility. I was unable to bootstrap and sshd was
> > not starting in the controller instance.
> >
> > Remounted kernel debug on the host, and bootstrap started working, sshd
> > starting up now in my trusty instances.
> >
> > Did not refresh my images. If it happens after rebooting the host, I'll
> try
> > to collect more info.
> >
> > -Casey
> >
> >
> > > --
> > >
> > > Director Meteorite.bi - Saiku Analytics Founder
> > > Tel: +44(0)5603641316
> > >
> > > (Thanks to the Saiku community we reached our Kickstart
> > > <
> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
> >
> > > goal, but you can always help by sponsoring the project
> > > )
> > >
> > > On 29 February 2016 at 22:43, Tom Barber 
> wrote:
> > >
> > >> Hi Serge
> > >>
> > >> Fresh reboot and updated image, image boots with SSHD working fine, so
> > >> whatever you did, i assume worked or is a freak occurrence. I don't
> have
> > >> any old images kicking around and the import I copied from your email
> > >> appears to have stomped on the old image.
> > >>
> > >> FYI
> > >>
> > >> bugg@tomsdevbox:~$ lxc config show t1
> > >> name: t1
> > >> profiles:
> > >> - default
> > >> config:
> > >>   volatile.base_image:
> > >> 510c27eb5e30ac53c6cf8b423d4e145bd2e40b8845e89bd66a5d78e2a087727a
> > >>   volatile.eth0.hwaddr: 00:16:3e:94:d5:66
> > >>   volatile.last_state.idmap:
> > >>
> '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
> > >>   volatile.lo.hwaddr: 00:16:3e:d2:98:62
> > >> devices:
> > >>   root:
> > >> path: /
> > >> type: disk
> > >> ephemeral: false
> > >>
> > >>
> > >> juju bootstrap now seems to run fine without remounting the kernel
> debug.
> > >>
> > >> Thanks for your help!
> > >>
> > >> Tom
> > >>
> > >>
> > >> --
> > >>
> > >> Director Meteorite.bi - Saiku Analytics Founder
> > >> Tel: +44(0)5603641316
> > >>
> > >> (Thanks to the Saiku community we reached our Kickstart
> > >> <
> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
> >
> > >> goal, but you can always help by sponsoring the project
> > >> )
> > >>
> > >> On 29 February 2016 at 21:45, Serge E. Hallyn 
> wrote:
> > >>
> > >>> On Mon, Feb 29, 2016 at 09:45:14AM +, Tom Barber wrote:
> > >>> > Hi Serge
> > >>> >
> > >>> > I rebooted the host to see what happened and the lxc images that
> were
> > >>> > running fine all now have broken SSHD. This, to make absolutely
> clear
> > >>> > doesn't affect the Xenial image, just the trusty one I test with.
> > >>> >
> > >>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2
> > >>> > Creating fix-server2
> > >>> > Starting fix-server2
> > >>> >
> > >>> > bugg@tomsdevbox:~$ lxc exec fix-server2 /bin/bash
> > >>> > root@fix-server2:~# ps aux |grep ssh
> > >>> > root  1597  0.0  0.0   8868   660 ?S+   09:41   0:00
> grep
> > >>> > --color=auto ssh
> > >>> >
> > >>> > exit
> > >>> >
> > >>> > umount and remount kernel debug
> > >>> >
> > >>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server3
> > >>> > Creating fix-server3
> > >>> > Starting fix-server3
> > >>> > bugg@tomsdevbox:~$ lxc exec fix-server3 /bin/bash
> > >>> > root@fix-server3:~# ps aux |grep ssh
> > >>> > root  1759  0.0  0.0  61380  3816 ?Ss   09:42   0:00
> > >>> > /usr/sbin/sshd -D
> > >>> > root  1944  0.0  0.0   8868   604 ?S+   09:43   0:00
> grep
> > >>> > --color=auto ssh
> > >>>
> > >>> If you pull a fresh image using
> > >>>
> > >>> lxd-images import ubu

Re: LXD Bootstrap

[Serge E. Hallyn]

Hi Casey,

I haven't reproduced that here in VMs.  If you can reproduce this at will (by
rebooting the host) could you file a bug against the kernel (pad.lv/u/linux) ?

thanks,
-serge

Quoting Casey Marshall (casey.marsh...@canonical.com):
> On Mon, Feb 29, 2016 at 4:57 PM, Tom Barber  wrote:
> 
> > Seemingly the image name and key are the same, LXD and Juju are the same,
> > so you've either done something magic or I'm confused with its now seeming
> > happiness of the kernel debug mountpoint! :)
> >
> 
> I ran into a similar issue today. xenial host, running latest juju out of
> master for LXD API compatibility. I was unable to bootstrap and sshd was
> not starting in the controller instance.
> 
> Remounted kernel debug on the host, and bootstrap started working, sshd
> starting up now in my trusty instances.
> 
> Did not refresh my images. If it happens after rebooting the host, I'll try
> to collect more info.
> 
> -Casey
> 
> 
> > --
> >
> > Director Meteorite.bi - Saiku Analytics Founder
> > Tel: +44(0)5603641316
> >
> > (Thanks to the Saiku community we reached our Kickstart
> > 
> > goal, but you can always help by sponsoring the project
> > )
> >
> > On 29 February 2016 at 22:43, Tom Barber  wrote:
> >
> >> Hi Serge
> >>
> >> Fresh reboot and updated image, image boots with SSHD working fine, so
> >> whatever you did, i assume worked or is a freak occurrence. I don't have
> >> any old images kicking around and the import I copied from your email
> >> appears to have stomped on the old image.
> >>
> >> FYI
> >>
> >> bugg@tomsdevbox:~$ lxc config show t1
> >> name: t1
> >> profiles:
> >> - default
> >> config:
> >>   volatile.base_image:
> >> 510c27eb5e30ac53c6cf8b423d4e145bd2e40b8845e89bd66a5d78e2a087727a
> >>   volatile.eth0.hwaddr: 00:16:3e:94:d5:66
> >>   volatile.last_state.idmap:
> >> '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
> >>   volatile.lo.hwaddr: 00:16:3e:d2:98:62
> >> devices:
> >>   root:
> >> path: /
> >> type: disk
> >> ephemeral: false
> >>
> >>
> >> juju bootstrap now seems to run fine without remounting the kernel debug.
> >>
> >> Thanks for your help!
> >>
> >> Tom
> >>
> >>
> >> --
> >>
> >> Director Meteorite.bi - Saiku Analytics Founder
> >> Tel: +44(0)5603641316
> >>
> >> (Thanks to the Saiku community we reached our Kickstart
> >> 
> >> goal, but you can always help by sponsoring the project
> >> )
> >>
> >> On 29 February 2016 at 21:45, Serge E. Hallyn  wrote:
> >>
> >>> On Mon, Feb 29, 2016 at 09:45:14AM +, Tom Barber wrote:
> >>> > Hi Serge
> >>> >
> >>> > I rebooted the host to see what happened and the lxc images that were
> >>> > running fine all now have broken SSHD. This, to make absolutely clear
> >>> > doesn't affect the Xenial image, just the trusty one I test with.
> >>> >
> >>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2
> >>> > Creating fix-server2
> >>> > Starting fix-server2
> >>> >
> >>> > bugg@tomsdevbox:~$ lxc exec fix-server2 /bin/bash
> >>> > root@fix-server2:~# ps aux |grep ssh
> >>> > root  1597  0.0  0.0   8868   660 ?S+   09:41   0:00 grep
> >>> > --color=auto ssh
> >>> >
> >>> > exit
> >>> >
> >>> > umount and remount kernel debug
> >>> >
> >>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server3
> >>> > Creating fix-server3
> >>> > Starting fix-server3
> >>> > bugg@tomsdevbox:~$ lxc exec fix-server3 /bin/bash
> >>> > root@fix-server3:~# ps aux |grep ssh
> >>> > root  1759  0.0  0.0  61380  3816 ?Ss   09:42   0:00
> >>> > /usr/sbin/sshd -D
> >>> > root  1944  0.0  0.0   8868   604 ?S+   09:43   0:00 grep
> >>> > --color=auto ssh
> >>>
> >>> If you pull a fresh image using
> >>>
> >>> lxd-images import ubuntu --alias newtrusty trusty amd64
> >>>
> >>> and launch that
> >>>
> >>> lxc launch newtrusty t1
> >>>
> >>> does it have the same failure?
> >>>
> >>> What does
> >>>
> >>> lxc config show fix-server2 show?
> >>>
> >>
> >>
> >
> > --
> > 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: LXD Bootstrap

[Casey Marshall]

On Mon, Feb 29, 2016 at 4:57 PM, Tom Barber  wrote:

> Seemingly the image name and key are the same, LXD and Juju are the same,
> so you've either done something magic or I'm confused with its now seeming
> happiness of the kernel debug mountpoint! :)
>

I ran into a similar issue today. xenial host, running latest juju out of
master for LXD API compatibility. I was unable to bootstrap and sshd was
not starting in the controller instance.

Remounted kernel debug on the host, and bootstrap started working, sshd
starting up now in my trusty instances.

Did not refresh my images. If it happens after rebooting the host, I'll try
to collect more info.

-Casey


> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 29 February 2016 at 22:43, Tom Barber  wrote:
>
>> Hi Serge
>>
>> Fresh reboot and updated image, image boots with SSHD working fine, so
>> whatever you did, i assume worked or is a freak occurrence. I don't have
>> any old images kicking around and the import I copied from your email
>> appears to have stomped on the old image.
>>
>> FYI
>>
>> bugg@tomsdevbox:~$ lxc config show t1
>> name: t1
>> profiles:
>> - default
>> config:
>>   volatile.base_image:
>> 510c27eb5e30ac53c6cf8b423d4e145bd2e40b8845e89bd66a5d78e2a087727a
>>   volatile.eth0.hwaddr: 00:16:3e:94:d5:66
>>   volatile.last_state.idmap:
>> '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
>>   volatile.lo.hwaddr: 00:16:3e:d2:98:62
>> devices:
>>   root:
>> path: /
>> type: disk
>> ephemeral: false
>>
>>
>> juju bootstrap now seems to run fine without remounting the kernel debug.
>>
>> Thanks for your help!
>>
>> Tom
>>
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 29 February 2016 at 21:45, Serge E. Hallyn  wrote:
>>
>>> On Mon, Feb 29, 2016 at 09:45:14AM +, Tom Barber wrote:
>>> > Hi Serge
>>> >
>>> > I rebooted the host to see what happened and the lxc images that were
>>> > running fine all now have broken SSHD. This, to make absolutely clear
>>> > doesn't affect the Xenial image, just the trusty one I test with.
>>> >
>>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2
>>> > Creating fix-server2
>>> > Starting fix-server2
>>> >
>>> > bugg@tomsdevbox:~$ lxc exec fix-server2 /bin/bash
>>> > root@fix-server2:~# ps aux |grep ssh
>>> > root  1597  0.0  0.0   8868   660 ?S+   09:41   0:00 grep
>>> > --color=auto ssh
>>> >
>>> > exit
>>> >
>>> > umount and remount kernel debug
>>> >
>>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server3
>>> > Creating fix-server3
>>> > Starting fix-server3
>>> > bugg@tomsdevbox:~$ lxc exec fix-server3 /bin/bash
>>> > root@fix-server3:~# ps aux |grep ssh
>>> > root  1759  0.0  0.0  61380  3816 ?Ss   09:42   0:00
>>> > /usr/sbin/sshd -D
>>> > root  1944  0.0  0.0   8868   604 ?S+   09:43   0:00 grep
>>> > --color=auto ssh
>>>
>>> If you pull a fresh image using
>>>
>>> lxd-images import ubuntu --alias newtrusty trusty amd64
>>>
>>> and launch that
>>>
>>> lxc launch newtrusty t1
>>>
>>> does it have the same failure?
>>>
>>> What does
>>>
>>> lxc config show fix-server2 show?
>>>
>>
>>
>
> --
> 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: LXD Bootstrap

[Tom Barber]

Seemingly the image name and key are the same, LXD and Juju are the same,
so you've either done something magic or I'm confused with its now seeming
happiness of the kernel debug mountpoint! :)

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 29 February 2016 at 22:43, Tom Barber  wrote:

> Hi Serge
>
> Fresh reboot and updated image, image boots with SSHD working fine, so
> whatever you did, i assume worked or is a freak occurrence. I don't have
> any old images kicking around and the import I copied from your email
> appears to have stomped on the old image.
>
> FYI
>
> bugg@tomsdevbox:~$ lxc config show t1
> name: t1
> profiles:
> - default
> config:
>   volatile.base_image:
> 510c27eb5e30ac53c6cf8b423d4e145bd2e40b8845e89bd66a5d78e2a087727a
>   volatile.eth0.hwaddr: 00:16:3e:94:d5:66
>   volatile.last_state.idmap:
> '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
>   volatile.lo.hwaddr: 00:16:3e:d2:98:62
> devices:
>   root:
> path: /
> type: disk
> ephemeral: false
>
>
> juju bootstrap now seems to run fine without remounting the kernel debug.
>
> Thanks for your help!
>
> Tom
>
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 29 February 2016 at 21:45, Serge E. Hallyn  wrote:
>
>> On Mon, Feb 29, 2016 at 09:45:14AM +, Tom Barber wrote:
>> > Hi Serge
>> >
>> > I rebooted the host to see what happened and the lxc images that were
>> > running fine all now have broken SSHD. This, to make absolutely clear
>> > doesn't affect the Xenial image, just the trusty one I test with.
>> >
>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2
>> > Creating fix-server2
>> > Starting fix-server2
>> >
>> > bugg@tomsdevbox:~$ lxc exec fix-server2 /bin/bash
>> > root@fix-server2:~# ps aux |grep ssh
>> > root  1597  0.0  0.0   8868   660 ?S+   09:41   0:00 grep
>> > --color=auto ssh
>> >
>> > exit
>> >
>> > umount and remount kernel debug
>> >
>> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server3
>> > Creating fix-server3
>> > Starting fix-server3
>> > bugg@tomsdevbox:~$ lxc exec fix-server3 /bin/bash
>> > root@fix-server3:~# ps aux |grep ssh
>> > root  1759  0.0  0.0  61380  3816 ?Ss   09:42   0:00
>> > /usr/sbin/sshd -D
>> > root  1944  0.0  0.0   8868   604 ?S+   09:43   0:00 grep
>> > --color=auto ssh
>>
>> If you pull a fresh image using
>>
>> lxd-images import ubuntu --alias newtrusty trusty amd64
>>
>> and launch that
>>
>> lxc launch newtrusty t1
>>
>> does it have the same failure?
>>
>> What does
>>
>> lxc config show fix-server2 show?
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

Hi Serge

Fresh reboot and updated image, image boots with SSHD working fine, so
whatever you did, i assume worked or is a freak occurrence. I don't have
any old images kicking around and the import I copied from your email
appears to have stomped on the old image.

FYI

bugg@tomsdevbox:~$ lxc config show t1
name: t1
profiles:
- default
config:
  volatile.base_image:
510c27eb5e30ac53c6cf8b423d4e145bd2e40b8845e89bd66a5d78e2a087727a
  volatile.eth0.hwaddr: 00:16:3e:94:d5:66
  volatile.last_state.idmap:
'[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
  volatile.lo.hwaddr: 00:16:3e:d2:98:62
devices:
  root:
path: /
type: disk
ephemeral: false


juju bootstrap now seems to run fine without remounting the kernel debug.

Thanks for your help!

Tom


--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 29 February 2016 at 21:45, Serge E. Hallyn  wrote:

> On Mon, Feb 29, 2016 at 09:45:14AM +, Tom Barber wrote:
> > Hi Serge
> >
> > I rebooted the host to see what happened and the lxc images that were
> > running fine all now have broken SSHD. This, to make absolutely clear
> > doesn't affect the Xenial image, just the trusty one I test with.
> >
> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2
> > Creating fix-server2
> > Starting fix-server2
> >
> > bugg@tomsdevbox:~$ lxc exec fix-server2 /bin/bash
> > root@fix-server2:~# ps aux |grep ssh
> > root  1597  0.0  0.0   8868   660 ?S+   09:41   0:00 grep
> > --color=auto ssh
> >
> > exit
> >
> > umount and remount kernel debug
> >
> > bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server3
> > Creating fix-server3
> > Starting fix-server3
> > bugg@tomsdevbox:~$ lxc exec fix-server3 /bin/bash
> > root@fix-server3:~# ps aux |grep ssh
> > root  1759  0.0  0.0  61380  3816 ?Ss   09:42   0:00
> > /usr/sbin/sshd -D
> > root  1944  0.0  0.0   8868   604 ?S+   09:43   0:00 grep
> > --color=auto ssh
>
> If you pull a fresh image using
>
> lxd-images import ubuntu --alias newtrusty trusty amd64
>
> and launch that
>
> lxc launch newtrusty t1
>
> does it have the same failure?
>
> What does
>
> lxc config show fix-server2 show?
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Serge E. Hallyn]

On Mon, Feb 29, 2016 at 09:45:14AM +, Tom Barber wrote:
> Hi Serge
> 
> I rebooted the host to see what happened and the lxc images that were
> running fine all now have broken SSHD. This, to make absolutely clear
> doesn't affect the Xenial image, just the trusty one I test with.
> 
> bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2
> Creating fix-server2
> Starting fix-server2
> 
> bugg@tomsdevbox:~$ lxc exec fix-server2 /bin/bash
> root@fix-server2:~# ps aux |grep ssh
> root  1597  0.0  0.0   8868   660 ?S+   09:41   0:00 grep
> --color=auto ssh
> 
> exit
> 
> umount and remount kernel debug
>
> bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server3
> Creating fix-server3
> Starting fix-server3
> bugg@tomsdevbox:~$ lxc exec fix-server3 /bin/bash
> root@fix-server3:~# ps aux |grep ssh
> root  1759  0.0  0.0  61380  3816 ?Ss   09:42   0:00
> /usr/sbin/sshd -D
> root  1944  0.0  0.0   8868   604 ?S+   09:43   0:00 grep
> --color=auto ssh

If you pull a fresh image using

lxd-images import ubuntu --alias newtrusty trusty amd64

and launch that

lxc launch newtrusty t1

does it have the same failure?

What does

lxc config show fix-server2 show?

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Serge E. Hallyn]

On Sat, Feb 27, 2016 at 11:42:51PM +, Tom Barber wrote:
> Okay I think I worked it out, but i dont' cause the cause in reality:
> 
> in upstart mountall was failing during the boot of the containers
> 
> so I did:
> 
> root@tomsdevbox ~ # umount /sys/kernel/debug
> root@tomsdevbox ~ # mount -t debugfs none /sys/kernel/debug

Is this on the host (vm, whatever), or in the container?

What does /proc/self/mountinfo show before and after the
remount?

-serge

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

Hi Serge

I rebooted the host to see what happened and the lxc images that were
running fine all now have broken SSHD. This, to make absolutely clear
doesn't affect the Xenial image, just the trusty one I test with.

bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server2
Creating fix-server2
Starting fix-server2

bugg@tomsdevbox:~$ lxc exec fix-server2 /bin/bash
root@fix-server2:~# ps aux |grep ssh
root  1597  0.0  0.0   8868   660 ?S+   09:41   0:00 grep
--color=auto ssh

exit

umount and remount kernel debug


bugg@tomsdevbox:~$ lxc launch ubuntu-trusty fix-server3
Creating fix-server3
Starting fix-server3
bugg@tomsdevbox:~$ lxc exec fix-server3 /bin/bash
root@fix-server3:~# ps aux |grep ssh
root  1759  0.0  0.0  61380  3816 ?Ss   09:42   0:00
/usr/sbin/sshd -D
root  1944  0.0  0.0   8868   604 ?S+   09:43   0:00 grep
--color=auto ssh


bugg@tomsdevbox:~$ lxc-config -l
lxc.default_config
lxc.lxcpath
lxc.bdev.lvm.vg
lxc.bdev.lvm.thin_pool
lxc.bdev.zfs.root
lxc.cgroup.use
lxc.cgroup.pattern


Cheers

Tom



--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 29 February 2016 at 07:57, Serge E. Hallyn  wrote:

> Hi Tom,
>
> can you reproduce this with lxd alone?
>
> What does 'lxc config show tomsdevbox' show?
>
> -serge
>
> On Sat, Feb 27, 2016 at 11:42:51PM +, Tom Barber wrote:
> > Okay I think I worked it out, but i dont' cause the cause in reality:
> >
> > in upstart mountall was failing during the boot of the containers
> >
> > so I did:
> >
> > root@tomsdevbox ~ # umount /sys/kernel/debug
> > root@tomsdevbox ~ # mount -t debugfs none /sys/kernel/debug
> >
> >
> > and suddenly trusty images started booting..
> >
> > --
> >
> > Director Meteorite.bi - Saiku Analytics Founder
> > Tel: +44(0)5603641316
> >
> > (Thanks to the Saiku community we reached our Kickstart
> > <
> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
> >
> > goal, but you can always help by sponsoring the project
> > )
> >
> > On 27 February 2016 at 22:26, Tom Barber 
> wrote:
> >
> > > Also, right on boot, like the moment the image spins up if I force the
> > > runlevel to 5, then the node gets bootstrapped without issue. So it is
> > > something to do with:
> > > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/924337 or similar,
> > > just with a Xenial host.
> > >
> > > --
> > >
> > > Director Meteorite.bi - Saiku Analytics Founder
> > > Tel: +44(0)5603641316
> > >
> > > (Thanks to the Saiku community we reached our Kickstart
> > > <
> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
> >
> > > goal, but you can always help by sponsoring the project
> > > )
> > >
> > > On 27 February 2016 at 22:11, Tom Barber 
> wrote:
> > >
> > >> Okay trusty images are failing for me because upstart borks and I get
> > >> dumped into runlevel unknown.
> > >>
> > >> Serge might have an idea as he was involved in a similar bug issue a
> > >> while ago on launchpad
> > >>
> > >> --
> > >>
> > >> Director Meteorite.bi - Saiku Analytics Founder
> > >> Tel: +44(0)5603641316
> > >>
> > >> (Thanks to the Saiku community we reached our Kickstart
> > >> <
> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
> >
> > >> goal, but you can always help by sponsoring the project
> > >> )
> > >>
> > >> On 27 February 2016 at 16:49, Tom Barber 
> wrote:
> > >>
> > >>> Okay so a summary from IRC investigations with Rick H.
> > >>>
> > >>> I thought yesterday on trusty manual sshd was running, i may have
> been
> > >>> wrong.
> > >>>
> > >>> Xenial image has a running sshd but I can't bootstrap it due to
> missing
> > >>> tools
> > >>>
> > >>> If anyone has a snippet for generating and using tools locally
> instead
> > >>> of from the platform, feel free to share so I can bootstrap a xenial
> node
> > >>> currently its failing with missing tools.
> > >>>
> > >>> Cheers
> > >>>
> > >>> Tom
> > >>>
> > >>> --
> > >>>
> > >>> Director Meteorite.bi - Saiku Analytics Founder
> > >>> Tel: +44(0)5603641316
> > >>>
> > >>> (Thanks to the Saiku community we reached our Kickstart
> > >>> <
> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
> >
> > >>> goal, but you can always help by sponsoring the project
> > >>> )
> > >>>
> > >>> On 27 February 2016 at 15:17, Tom Barber 
> > >>> wrote:
> > >>>
> >  Also:
> > 
> >  bu

Re: LXD Bootstrap

[Tom Barber]

Okay I think I worked it out, but i dont' cause the cause in reality:

in upstart mountall was failing during the boot of the containers

so I did:

root@tomsdevbox ~ # umount /sys/kernel/debug
root@tomsdevbox ~ # mount -t debugfs none /sys/kernel/debug


and suddenly trusty images started booting..

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 22:26, Tom Barber  wrote:

> Also, right on boot, like the moment the image spins up if I force the
> runlevel to 5, then the node gets bootstrapped without issue. So it is
> something to do with:
> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/924337 or similar,
> just with a Xenial host.
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 27 February 2016 at 22:11, Tom Barber  wrote:
>
>> Okay trusty images are failing for me because upstart borks and I get
>> dumped into runlevel unknown.
>>
>> Serge might have an idea as he was involved in a similar bug issue a
>> while ago on launchpad
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 27 February 2016 at 16:49, Tom Barber  wrote:
>>
>>> Okay so a summary from IRC investigations with Rick H.
>>>
>>> I thought yesterday on trusty manual sshd was running, i may have been
>>> wrong.
>>>
>>> Xenial image has a running sshd but I can't bootstrap it due to missing
>>> tools
>>>
>>> If anyone has a snippet for generating and using tools locally instead
>>> of from the platform, feel free to share so I can bootstrap a xenial node
>>> currently its failing with missing tools.
>>>
>>> Cheers
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 27 February 2016 at 15:17, Tom Barber 
>>> wrote:
>>>
 Also:

 bugg@tomsdevbox:~$ lsb_release -a
 No LSB modules are available.
 Distributor ID: Ubuntu
 Description: Ubuntu Xenial Xerus (development branch)
 Release: 16.04
 Codename: xenial


 lxd-images import ubuntu xenial amd64 --sync --alias ubuntu-xenial


  juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
 xenial


 2016-02-27 15:15:38 ERROR cmd supercommand.go:448 failed to bootstrap
 model: no matching tools available


 So that doesn't help ;)

 As this is an empty box, I'll happily give you access so you can prod
 around and see if you can figure it out ;)



 --

 Director Meteorite.bi - Saiku Analytics Founder
 Tel: +44(0)5603641316

 (Thanks to the Saiku community we reached our Kickstart
 
 goal, but you can always help by sponsoring the project
 )

 On 27 February 2016 at 15:00, Tom Barber 
 wrote:

>
> On 27 February 2016 at 14:53, John Meinel 
> wrote:
>
>> juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
>> trusty"
>
>
> No difference. Im on juju-dev as magicaltrout.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>


>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

Also, right on boot, like the moment the image spins up if I force the
runlevel to 5, then the node gets bootstrapped without issue. So it is
something to do with:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/924337 or similar, just
with a Xenial host.

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 22:11, Tom Barber  wrote:

> Okay trusty images are failing for me because upstart borks and I get
> dumped into runlevel unknown.
>
> Serge might have an idea as he was involved in a similar bug issue a while
> ago on launchpad
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 27 February 2016 at 16:49, Tom Barber  wrote:
>
>> Okay so a summary from IRC investigations with Rick H.
>>
>> I thought yesterday on trusty manual sshd was running, i may have been
>> wrong.
>>
>> Xenial image has a running sshd but I can't bootstrap it due to missing
>> tools
>>
>> If anyone has a snippet for generating and using tools locally instead of
>> from the platform, feel free to share so I can bootstrap a xenial node
>> currently its failing with missing tools.
>>
>> Cheers
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 27 February 2016 at 15:17, Tom Barber  wrote:
>>
>>> Also:
>>>
>>> bugg@tomsdevbox:~$ lsb_release -a
>>> No LSB modules are available.
>>> Distributor ID: Ubuntu
>>> Description: Ubuntu Xenial Xerus (development branch)
>>> Release: 16.04
>>> Codename: xenial
>>>
>>>
>>> lxd-images import ubuntu xenial amd64 --sync --alias ubuntu-xenial
>>>
>>>
>>>  juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
>>> xenial
>>>
>>>
>>> 2016-02-27 15:15:38 ERROR cmd supercommand.go:448 failed to bootstrap
>>> model: no matching tools available
>>>
>>>
>>> So that doesn't help ;)
>>>
>>> As this is an empty box, I'll happily give you access so you can prod
>>> around and see if you can figure it out ;)
>>>
>>>
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 27 February 2016 at 15:00, Tom Barber 
>>> wrote:
>>>

 On 27 February 2016 at 14:53, John Meinel 
 wrote:

> juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
> trusty"


 No difference. Im on juju-dev as magicaltrout.

 Tom

 --

 Director Meteorite.bi - Saiku Analytics Founder
 Tel: +44(0)5603641316

 (Thanks to the Saiku community we reached our Kickstart
 
 goal, but you can always help by sponsoring the project
 )

>>>
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

Okay trusty images are failing for me because upstart borks and I get
dumped into runlevel unknown.

Serge might have an idea as he was involved in a similar bug issue a while
ago on launchpad

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 16:49, Tom Barber  wrote:

> Okay so a summary from IRC investigations with Rick H.
>
> I thought yesterday on trusty manual sshd was running, i may have been
> wrong.
>
> Xenial image has a running sshd but I can't bootstrap it due to missing
> tools
>
> If anyone has a snippet for generating and using tools locally instead of
> from the platform, feel free to share so I can bootstrap a xenial node
> currently its failing with missing tools.
>
> Cheers
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 27 February 2016 at 15:17, Tom Barber  wrote:
>
>> Also:
>>
>> bugg@tomsdevbox:~$ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description: Ubuntu Xenial Xerus (development branch)
>> Release: 16.04
>> Codename: xenial
>>
>>
>> lxd-images import ubuntu xenial amd64 --sync --alias ubuntu-xenial
>>
>>
>>  juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
>> xenial
>>
>>
>> 2016-02-27 15:15:38 ERROR cmd supercommand.go:448 failed to bootstrap
>> model: no matching tools available
>>
>>
>> So that doesn't help ;)
>>
>> As this is an empty box, I'll happily give you access so you can prod
>> around and see if you can figure it out ;)
>>
>>
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 27 February 2016 at 15:00, Tom Barber  wrote:
>>
>>>
>>> On 27 February 2016 at 14:53, John Meinel 
>>> wrote:
>>>
 juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
 trusty"
>>>
>>>
>>> No difference. Im on juju-dev as magicaltrout.
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

Okay so a summary from IRC investigations with Rick H.

I thought yesterday on trusty manual sshd was running, i may have been
wrong.

Xenial image has a running sshd but I can't bootstrap it due to missing
tools

If anyone has a snippet for generating and using tools locally instead of
from the platform, feel free to share so I can bootstrap a xenial node
currently its failing with missing tools.

Cheers

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 15:17, Tom Barber  wrote:

> Also:
>
> bugg@tomsdevbox:~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu Xenial Xerus (development branch)
> Release: 16.04
> Codename: xenial
>
>
> lxd-images import ubuntu xenial amd64 --sync --alias ubuntu-xenial
>
>
>  juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
> xenial
>
>
> 2016-02-27 15:15:38 ERROR cmd supercommand.go:448 failed to bootstrap
> model: no matching tools available
>
>
> So that doesn't help ;)
>
> As this is an empty box, I'll happily give you access so you can prod
> around and see if you can figure it out ;)
>
>
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 27 February 2016 at 15:00, Tom Barber  wrote:
>
>>
>> On 27 February 2016 at 14:53, John Meinel  wrote:
>>
>>> juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
>>> trusty"
>>
>>
>> No difference. Im on juju-dev as magicaltrout.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

Also:

bugg@tomsdevbox:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Xenial Xerus (development branch)
Release: 16.04
Codename: xenial


lxd-images import ubuntu xenial amd64 --sync --alias ubuntu-xenial


 juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
xenial


2016-02-27 15:15:38 ERROR cmd supercommand.go:448 failed to bootstrap
model: no matching tools available


So that doesn't help ;)

As this is an empty box, I'll happily give you access so you can prod
around and see if you can figure it out ;)



--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 15:00, Tom Barber  wrote:

>
> On 27 February 2016 at 14:53, John Meinel  wrote:
>
>> juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
>> trusty"
>
>
> No difference. Im on juju-dev as magicaltrout.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

On 27 February 2016 at 14:53, John Meinel  wrote:

> juju bootstrap test-lxd lxd --debug --upload-tools --bootstrap-series
> trusty"


No difference. Im on juju-dev as magicaltrout.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[John Meinel]

One thing you could try, "juju bootstrap test-lxd lxd --debug
--upload-tools --bootstrap-series trusty". It may be a difference based on
what the target series is.

John
=:->


On Sat, Feb 27, 2016 at 6:50 PM, John Meinel  wrote:

> Is 10.0.3.94 the correct IP for the LXD container? Did you let it sit a
> while so it had a chance to keep trying until maybe SSH came up on its own?
> And yet again, if you just do "lxc create" a container from exactly the
> same image, is SSH running on it?
>
> I'm recompiling my own work here making sure I'm tracking exactly the
> lxd-container-type branch (though I merged it into the proposed branch I
> had been working on.)
>
> I'm running on Trusty, having installed LXD from the
> ppa:ubuntu-lxc/lxd-stable ppa. I don't know if that has anything to do with
> it. Would it be easier to chat about this on IRC? Are you available on
> irc.freenode.net #juju-dev ?
>
> John
> =:->
>
>
> On Sat, Feb 27, 2016 at 6:43 PM, Tom Barber 
> wrote:
>
>> Okay, evolution on a theme, clean install, compiled the new version and
>> added lxd and checked my user now I get:
>>
>> 016-02-27 14:40:51 DEBUG juju.provider.common bootstrap.go:318 connection
>> attempt for 10.0.3.94 failed: ssh: connect to host 10.0.3.94 port 22:
>> Connection refused
>> 2016-02-27 14:40:52 DEBUG juju.provider.common bootstrap.go:318
>> connection attempt for ::1 failed: Permission denied (publickey,password).
>> 2016-02-27 14:40:52 DEBUG juju.provider.common bootstrap.go:318
>> connection attempt for 127.0.0.1 failed: Permission denied
>> (publickey,password).
>> 2016-02-27 14:40:56 DEBUG juju.provider.common bootstrap.go:318
>> connection attempt for fe80::216:3eff:fe6e:86b5 failed: ssh: connect to
>> host fe80::216:3eff:fe6e:86b5 port 22: Invalid argument
>> 2016-02-27 14:40:56 DEBUG juju.provider.common bootstrap.go:318
>> connection attempt for 10.0.3.94 failed: ssh: connect to host 10.0.3.94
>> port 22: Connection refused
>> 2016-02-27 14:40:58 DEBUG juju.provider.common bootstrap.go:318
>> connection attempt for ::1 failed: Permission denied (publickey,password).
>> 2016-02-27 14:40:58 DEBUG juju.provider.common bootstrap.go:318
>> connection attempt for 127.0.0.1 failed: Permission denied
>> (publickey,password).
>>
>>
>> So similar, but different, still no sshd. So same problem on a clean OS
>> where only the lxd branch has ever run.
>>
>> WTF? :)
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[John Meinel]

Is 10.0.3.94 the correct IP for the LXD container? Did you let it sit a
while so it had a chance to keep trying until maybe SSH came up on its own?
And yet again, if you just do "lxc create" a container from exactly the
same image, is SSH running on it?

I'm recompiling my own work here making sure I'm tracking exactly the
lxd-container-type branch (though I merged it into the proposed branch I
had been working on.)

I'm running on Trusty, having installed LXD from the
ppa:ubuntu-lxc/lxd-stable ppa. I don't know if that has anything to do with
it. Would it be easier to chat about this on IRC? Are you available on
irc.freenode.net #juju-dev ?

John
=:->


On Sat, Feb 27, 2016 at 6:43 PM, Tom Barber  wrote:

> Okay, evolution on a theme, clean install, compiled the new version and
> added lxd and checked my user now I get:
>
> 016-02-27 14:40:51 DEBUG juju.provider.common bootstrap.go:318 connection
> attempt for 10.0.3.94 failed: ssh: connect to host 10.0.3.94 port 22:
> Connection refused
> 2016-02-27 14:40:52 DEBUG juju.provider.common bootstrap.go:318 connection
> attempt for ::1 failed: Permission denied (publickey,password).
> 2016-02-27 14:40:52 DEBUG juju.provider.common bootstrap.go:318 connection
> attempt for 127.0.0.1 failed: Permission denied (publickey,password).
> 2016-02-27 14:40:56 DEBUG juju.provider.common bootstrap.go:318 connection
> attempt for fe80::216:3eff:fe6e:86b5 failed: ssh: connect to host
> fe80::216:3eff:fe6e:86b5 port 22: Invalid argument
> 2016-02-27 14:40:56 DEBUG juju.provider.common bootstrap.go:318 connection
> attempt for 10.0.3.94 failed: ssh: connect to host 10.0.3.94 port 22:
> Connection refused
> 2016-02-27 14:40:58 DEBUG juju.provider.common bootstrap.go:318 connection
> attempt for ::1 failed: Permission denied (publickey,password).
> 2016-02-27 14:40:58 DEBUG juju.provider.common bootstrap.go:318 connection
> attempt for 127.0.0.1 failed: Permission denied (publickey,password).
>
>
> So similar, but different, still no sshd. So same problem on a clean OS
> where only the lxd branch has ever run.
>
> WTF? :)
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

Okay, evolution on a theme, clean install, compiled the new version and
added lxd and checked my user now I get:

016-02-27 14:40:51 DEBUG juju.provider.common bootstrap.go:318 connection
attempt for 10.0.3.94 failed: ssh: connect to host 10.0.3.94 port 22:
Connection refused
2016-02-27 14:40:52 DEBUG juju.provider.common bootstrap.go:318 connection
attempt for ::1 failed: Permission denied (publickey,password).
2016-02-27 14:40:52 DEBUG juju.provider.common bootstrap.go:318 connection
attempt for 127.0.0.1 failed: Permission denied (publickey,password).
2016-02-27 14:40:56 DEBUG juju.provider.common bootstrap.go:318 connection
attempt for fe80::216:3eff:fe6e:86b5 failed: ssh: connect to host
fe80::216:3eff:fe6e:86b5 port 22: Invalid argument
2016-02-27 14:40:56 DEBUG juju.provider.common bootstrap.go:318 connection
attempt for 10.0.3.94 failed: ssh: connect to host 10.0.3.94 port 22:
Connection refused
2016-02-27 14:40:58 DEBUG juju.provider.common bootstrap.go:318 connection
attempt for ::1 failed: Permission denied (publickey,password).
2016-02-27 14:40:58 DEBUG juju.provider.common bootstrap.go:318 connection
attempt for 127.0.0.1 failed: Permission denied (publickey,password).


So similar, but different, still no sshd. So same problem on a clean OS
where only the lxd branch has ever run.

WTF? :)

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

Yeah I did run the build like that, so not sure whats going on there. lxc
launch still works fine.

The box is empty except this hacking so I might flatten it and reinstall
wily and upgrade through it again, see if a clean slate does the trick. LXD
looks fine though, so I'm not sure what I'm doing wrong.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 13:25, John Meinel  wrote:

> You're running on Xenial but you don't have a Xenial image listed. Maybe
> its launching a Trusty image for bootstrap? I thought it always tried to
> match the host version.
> I assume you did:
> cd $GOPATH/src/github.com/juju/juju
> git checkout lxd-container-type
> godeps -u dependencies.tsv
> go install ./...
> $GOPATH/bin/juju --version
> etc.
>
> That particular "cannot unmarshal string into Go value" is exactly what I
> would expect to see if you are using the wrong version of Juju with the
> wrong version of LXD. LXD changed a few fields from ints to strings.
> (2.0.0beta3 had an Architecture int, which they changed to Architecture
> string.)
> The unmarshall failure sounds like you're using 2.0.0beta4 for LXD, but a
> version of juju that was compiled against 2.0.0beta3 bindings.
>
> John
> =:->
>
>
> On Sat, Feb 27, 2016 at 5:20 PM, Tom Barber 
> wrote:
>
>> The only thing I can tell you about this box that might different from
>> the test beds you guys use was it was a dist upgrade from wily because that
>> was the latest image the hosts had.
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 27 February 2016 at 13:14, Tom Barber  wrote:
>>
>>> Okay checked out and tested but no dice currently:
>>>
>>> bugg@tomsdevbox:~$ juju --version
>>> 2.0-beta2-xenial-amd64
>>>
>>>
>>>
>>> bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxc --version
>>> 2.0.0.beta4
>>>
>>>
>>> bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxd --version
>>> 2.0.0.beta4
>>>
>>>
>>> bugg@tomsdevbox:~/work/src/github.com/juju/juju$ juju bootstrap
>>> mycontroller lxd --debug --upload-tools
>>> 2016-02-27 13:09:10 INFO juju.cmd supercommand.go:59 running juju
>>> [2.0-beta2 gc go1.6]
>>> 2016-02-27 13:09:10 INFO cmd cmd.go:141 cloud "lxd" not found, trying as
>>> a provider name
>>> 2016-02-27 13:09:10 INFO cmd cmd.go:141 no credentials found, checking
>>> environment
>>> 2016-02-27 13:09:10 DEBUG juju.cmd.juju.commands bootstrap.go:340
>>> preparing controller with config: map[type:lxd name:mycontroller]
>>> 2016-02-27 13:09:14 DEBUG juju.container.lxd.lxdclient client.go:57
>>> loading LXD client config from "/home/bugg/.config/lxc/juju-mycontroller"
>>> 2016-02-27 13:09:14 DEBUG juju.container.lxd.lxdclient client.go:64
>>> using LXD remote "local"
>>> 2016-02-27 13:09:14 ERROR cmd supercommand.go:448 invalid config: json:
>>> cannot unmarshal string into Go value of type int
>>> bugg@tomsdevbox:~/work/src/github.com/juju/juju$
>>>
>>>
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 27 February 2016 at 13:01, Tom Barber 
>>> wrote:
>>>
 bugg@tomsdevbox:~$ lxc launch ubuntu-trusty my-test-container
 Creating my-test-container

 Starting my-test-container
 bugg@tomsdevbox:~$
 bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bas
 bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bash
 root@my-test-container:~# ps axu |grep ssh
 root  1800  0.0  0.0  61380  5408 ?Ss   12:59   0:00
 /usr/sbin/sshd -D
 root  1993  0.0  0.0   8868   784 ?S+   13:00   0:00 grep
 --color=auto ssh
 root@my-test-container:~#


 Seems alright if I just launch an instance. Also inside the juju
 bootstrapped containers you can see some ssh related stuff where it sets
 keys etc in the logs so its logging in and doing something.

 I've compiled everything from 1.26 alpha2 to master so I'll happily
 wipe it clean and try the branch! ;)

 Tom

 --

 Director Meteorite.bi - Saiku Analytics Founder
 Tel: +44(0)5603641316

 (Thanks to the Saiku com

Re: LXD Bootstrap

[John Meinel]

You're running on Xenial but you don't have a Xenial image listed. Maybe
its launching a Trusty image for bootstrap? I thought it always tried to
match the host version.
I assume you did:
cd $GOPATH/src/github.com/juju/juju
git checkout lxd-container-type
godeps -u dependencies.tsv
go install ./...
$GOPATH/bin/juju --version
etc.

That particular "cannot unmarshal string into Go value" is exactly what I
would expect to see if you are using the wrong version of Juju with the
wrong version of LXD. LXD changed a few fields from ints to strings.
(2.0.0beta3 had an Architecture int, which they changed to Architecture
string.)
The unmarshall failure sounds like you're using 2.0.0beta4 for LXD, but a
version of juju that was compiled against 2.0.0beta3 bindings.

John
=:->


On Sat, Feb 27, 2016 at 5:20 PM, Tom Barber  wrote:

> The only thing I can tell you about this box that might different from the
> test beds you guys use was it was a dist upgrade from wily because that was
> the latest image the hosts had.
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 27 February 2016 at 13:14, Tom Barber  wrote:
>
>> Okay checked out and tested but no dice currently:
>>
>> bugg@tomsdevbox:~$ juju --version
>> 2.0-beta2-xenial-amd64
>>
>>
>>
>> bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxc --version
>> 2.0.0.beta4
>>
>>
>> bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxd --version
>> 2.0.0.beta4
>>
>>
>> bugg@tomsdevbox:~/work/src/github.com/juju/juju$ juju bootstrap
>> mycontroller lxd --debug --upload-tools
>> 2016-02-27 13:09:10 INFO juju.cmd supercommand.go:59 running juju
>> [2.0-beta2 gc go1.6]
>> 2016-02-27 13:09:10 INFO cmd cmd.go:141 cloud "lxd" not found, trying as
>> a provider name
>> 2016-02-27 13:09:10 INFO cmd cmd.go:141 no credentials found, checking
>> environment
>> 2016-02-27 13:09:10 DEBUG juju.cmd.juju.commands bootstrap.go:340
>> preparing controller with config: map[type:lxd name:mycontroller]
>> 2016-02-27 13:09:14 DEBUG juju.container.lxd.lxdclient client.go:57
>> loading LXD client config from "/home/bugg/.config/lxc/juju-mycontroller"
>> 2016-02-27 13:09:14 DEBUG juju.container.lxd.lxdclient client.go:64 using
>> LXD remote "local"
>> 2016-02-27 13:09:14 ERROR cmd supercommand.go:448 invalid config: json:
>> cannot unmarshal string into Go value of type int
>> bugg@tomsdevbox:~/work/src/github.com/juju/juju$
>>
>>
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 27 February 2016 at 13:01, Tom Barber  wrote:
>>
>>> bugg@tomsdevbox:~$ lxc launch ubuntu-trusty my-test-container
>>> Creating my-test-container
>>>
>>> Starting my-test-container
>>> bugg@tomsdevbox:~$
>>> bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bas
>>> bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bash
>>> root@my-test-container:~# ps axu |grep ssh
>>> root  1800  0.0  0.0  61380  5408 ?Ss   12:59   0:00
>>> /usr/sbin/sshd -D
>>> root  1993  0.0  0.0   8868   784 ?S+   13:00   0:00 grep
>>> --color=auto ssh
>>> root@my-test-container:~#
>>>
>>>
>>> Seems alright if I just launch an instance. Also inside the juju
>>> bootstrapped containers you can see some ssh related stuff where it sets
>>> keys etc in the logs so its logging in and doing something.
>>>
>>> I've compiled everything from 1.26 alpha2 to master so I'll happily wipe
>>> it clean and try the branch! ;)
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 27 February 2016 at 12:56, John Meinel 
>>> wrote:
>>>
 BTW, if you are comfortable running Juju from master, there is a branch
 "lxd-container-type" which should support LXD 2.0.0~beta4 (I have it
 running here), and I'd be happy to get feedback on it.

 John
 =:->


 On Sat, Feb 27, 2016 at 4:55 PM, John Meinel 
 wrote:

> That does seem correct. But I thought cloud-images run openssh by
> default. So that seems surprising.
>
> What happens if you just do "lxc create" to spawn an instance instead
> of using Juju?
>
>

Re: LXD Bootstrap

[Tom Barber]

The only thing I can tell you about this box that might different from the
test beds you guys use was it was a dist upgrade from wily because that was
the latest image the hosts had.

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 13:14, Tom Barber  wrote:

> Okay checked out and tested but no dice currently:
>
> bugg@tomsdevbox:~$ juju --version
> 2.0-beta2-xenial-amd64
>
>
>
> bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxc --version
> 2.0.0.beta4
>
>
> bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxd --version
> 2.0.0.beta4
>
>
> bugg@tomsdevbox:~/work/src/github.com/juju/juju$ juju bootstrap
> mycontroller lxd --debug --upload-tools
> 2016-02-27 13:09:10 INFO juju.cmd supercommand.go:59 running juju
> [2.0-beta2 gc go1.6]
> 2016-02-27 13:09:10 INFO cmd cmd.go:141 cloud "lxd" not found, trying as a
> provider name
> 2016-02-27 13:09:10 INFO cmd cmd.go:141 no credentials found, checking
> environment
> 2016-02-27 13:09:10 DEBUG juju.cmd.juju.commands bootstrap.go:340
> preparing controller with config: map[type:lxd name:mycontroller]
> 2016-02-27 13:09:14 DEBUG juju.container.lxd.lxdclient client.go:57
> loading LXD client config from "/home/bugg/.config/lxc/juju-mycontroller"
> 2016-02-27 13:09:14 DEBUG juju.container.lxd.lxdclient client.go:64 using
> LXD remote "local"
> 2016-02-27 13:09:14 ERROR cmd supercommand.go:448 invalid config: json:
> cannot unmarshal string into Go value of type int
> bugg@tomsdevbox:~/work/src/github.com/juju/juju$
>
>
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 27 February 2016 at 13:01, Tom Barber  wrote:
>
>> bugg@tomsdevbox:~$ lxc launch ubuntu-trusty my-test-container
>> Creating my-test-container
>>
>> Starting my-test-container
>> bugg@tomsdevbox:~$
>> bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bas
>> bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bash
>> root@my-test-container:~# ps axu |grep ssh
>> root  1800  0.0  0.0  61380  5408 ?Ss   12:59   0:00
>> /usr/sbin/sshd -D
>> root  1993  0.0  0.0   8868   784 ?S+   13:00   0:00 grep
>> --color=auto ssh
>> root@my-test-container:~#
>>
>>
>> Seems alright if I just launch an instance. Also inside the juju
>> bootstrapped containers you can see some ssh related stuff where it sets
>> keys etc in the logs so its logging in and doing something.
>>
>> I've compiled everything from 1.26 alpha2 to master so I'll happily wipe
>> it clean and try the branch! ;)
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 27 February 2016 at 12:56, John Meinel  wrote:
>>
>>> BTW, if you are comfortable running Juju from master, there is a branch
>>> "lxd-container-type" which should support LXD 2.0.0~beta4 (I have it
>>> running here), and I'd be happy to get feedback on it.
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Sat, Feb 27, 2016 at 4:55 PM, John Meinel 
>>> wrote:
>>>
 That does seem correct. But I thought cloud-images run openssh by
 default. So that seems surprising.

 What happens if you just do "lxc create" to spawn an instance instead
 of using Juju?

 John
 =:->


 On Sat, Feb 27, 2016 at 4:17 PM, Tom Barber 
 wrote:

> I used:
>
> lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty
>
> Which I stole from Jorge's blog.
>
> bugg@tomsdevbox:~$ lxc image list
>
> ++--++++--+--+
> | ALIAS  | FINGERPRINT  | PUBLIC |DESCRIPTION
> |  ARCH  |   SIZE   | UPLOAD DATE  |
>
> ++--++++--+--+
> | ubuntu-precise | 4029ee764a39 | no | Ubuntu 12.04 LTS server
> (20160222) | x86_64 | 155.25MB | Feb 26, 2016 at 5:12pm (CET) |
> | ubuntu-trusty  | 510c27eb5e30 | no | Ubuntu 14.04 LTS server
> (20160222) | x86_64 | 118.51MB | Feb 26,

Re: LXD Bootstrap

[Tom Barber]

Okay checked out and tested but no dice currently:

bugg@tomsdevbox:~$ juju --version
2.0-beta2-xenial-amd64



bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxc --version
2.0.0.beta4


bugg@tomsdevbox:~/work/src/github.com/juju/juju$ lxd --version
2.0.0.beta4


bugg@tomsdevbox:~/work/src/github.com/juju/juju$ juju bootstrap
mycontroller lxd --debug --upload-tools
2016-02-27 13:09:10 INFO juju.cmd supercommand.go:59 running juju
[2.0-beta2 gc go1.6]
2016-02-27 13:09:10 INFO cmd cmd.go:141 cloud "lxd" not found, trying as a
provider name
2016-02-27 13:09:10 INFO cmd cmd.go:141 no credentials found, checking
environment
2016-02-27 13:09:10 DEBUG juju.cmd.juju.commands bootstrap.go:340 preparing
controller with config: map[type:lxd name:mycontroller]
2016-02-27 13:09:14 DEBUG juju.container.lxd.lxdclient client.go:57 loading
LXD client config from "/home/bugg/.config/lxc/juju-mycontroller"
2016-02-27 13:09:14 DEBUG juju.container.lxd.lxdclient client.go:64 using
LXD remote "local"
2016-02-27 13:09:14 ERROR cmd supercommand.go:448 invalid config: json:
cannot unmarshal string into Go value of type int
bugg@tomsdevbox:~/work/src/github.com/juju/juju$



--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 13:01, Tom Barber  wrote:

> bugg@tomsdevbox:~$ lxc launch ubuntu-trusty my-test-container
> Creating my-test-container
>
> Starting my-test-container
> bugg@tomsdevbox:~$
> bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bas
> bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bash
> root@my-test-container:~# ps axu |grep ssh
> root  1800  0.0  0.0  61380  5408 ?Ss   12:59   0:00
> /usr/sbin/sshd -D
> root  1993  0.0  0.0   8868   784 ?S+   13:00   0:00 grep
> --color=auto ssh
> root@my-test-container:~#
>
>
> Seems alright if I just launch an instance. Also inside the juju
> bootstrapped containers you can see some ssh related stuff where it sets
> keys etc in the logs so its logging in and doing something.
>
> I've compiled everything from 1.26 alpha2 to master so I'll happily wipe
> it clean and try the branch! ;)
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 27 February 2016 at 12:56, John Meinel  wrote:
>
>> BTW, if you are comfortable running Juju from master, there is a branch
>> "lxd-container-type" which should support LXD 2.0.0~beta4 (I have it
>> running here), and I'd be happy to get feedback on it.
>>
>> John
>> =:->
>>
>>
>> On Sat, Feb 27, 2016 at 4:55 PM, John Meinel 
>> wrote:
>>
>>> That does seem correct. But I thought cloud-images run openssh by
>>> default. So that seems surprising.
>>>
>>> What happens if you just do "lxc create" to spawn an instance instead of
>>> using Juju?
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Sat, Feb 27, 2016 at 4:17 PM, Tom Barber 
>>> wrote:
>>>
 I used:

 lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty

 Which I stole from Jorge's blog.

 bugg@tomsdevbox:~$ lxc image list

 ++--++++--+--+
 | ALIAS  | FINGERPRINT  | PUBLIC |DESCRIPTION
   |  ARCH  |   SIZE   | UPLOAD DATE  |

 ++--++++--+--+
 | ubuntu-precise | 4029ee764a39 | no | Ubuntu 12.04 LTS server
 (20160222) | x86_64 | 155.25MB | Feb 26, 2016 at 5:12pm (CET) |
 | ubuntu-trusty  | 510c27eb5e30 | no | Ubuntu 14.04 LTS server
 (20160222) | x86_64 | 118.51MB | Feb 26, 2016 at 5:13pm (CET) |
 | ubuntu-wily| fb2cf6ab4af1 | no | Ubuntu 15.10 server
 (20160222) | x86_64 | 154.27MB | Feb 26, 2016 at 5:12pm (CET) |

 ++--++++--+--+


 --

 Director Meteorite.bi - Saiku Analytics Founder
 Tel: +44(0)5603641316

 (Thanks to the Saiku community we reached our Kickstart
 
 goal, but you can always help by sponsoring the project
 )

 On 27 February 2016 at 1

Re: LXD Bootstrap

[Tom Barber]

bugg@tomsdevbox:~$ lxc launch ubuntu-trusty my-test-container
Creating my-test-container

Starting my-test-container
bugg@tomsdevbox:~$
bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bas
bugg@tomsdevbox:~$ lxc exec my-test-container /bin/bash
root@my-test-container:~# ps axu |grep ssh
root  1800  0.0  0.0  61380  5408 ?Ss   12:59   0:00
/usr/sbin/sshd -D
root  1993  0.0  0.0   8868   784 ?S+   13:00   0:00 grep
--color=auto ssh
root@my-test-container:~#


Seems alright if I just launch an instance. Also inside the juju
bootstrapped containers you can see some ssh related stuff where it sets
keys etc in the logs so its logging in and doing something.

I've compiled everything from 1.26 alpha2 to master so I'll happily wipe it
clean and try the branch! ;)

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 12:56, John Meinel  wrote:

> BTW, if you are comfortable running Juju from master, there is a branch
> "lxd-container-type" which should support LXD 2.0.0~beta4 (I have it
> running here), and I'd be happy to get feedback on it.
>
> John
> =:->
>
>
> On Sat, Feb 27, 2016 at 4:55 PM, John Meinel 
> wrote:
>
>> That does seem correct. But I thought cloud-images run openssh by
>> default. So that seems surprising.
>>
>> What happens if you just do "lxc create" to spawn an instance instead of
>> using Juju?
>>
>> John
>> =:->
>>
>>
>> On Sat, Feb 27, 2016 at 4:17 PM, Tom Barber 
>> wrote:
>>
>>> I used:
>>>
>>> lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty
>>>
>>> Which I stole from Jorge's blog.
>>>
>>> bugg@tomsdevbox:~$ lxc image list
>>>
>>> ++--++++--+--+
>>> | ALIAS  | FINGERPRINT  | PUBLIC |DESCRIPTION
>>>   |  ARCH  |   SIZE   | UPLOAD DATE  |
>>>
>>> ++--++++--+--+
>>> | ubuntu-precise | 4029ee764a39 | no | Ubuntu 12.04 LTS server
>>> (20160222) | x86_64 | 155.25MB | Feb 26, 2016 at 5:12pm (CET) |
>>> | ubuntu-trusty  | 510c27eb5e30 | no | Ubuntu 14.04 LTS server
>>> (20160222) | x86_64 | 118.51MB | Feb 26, 2016 at 5:13pm (CET) |
>>> | ubuntu-wily| fb2cf6ab4af1 | no | Ubuntu 15.10 server
>>> (20160222) | x86_64 | 154.27MB | Feb 26, 2016 at 5:12pm (CET) |
>>>
>>> ++--++++--+--+
>>>
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 27 February 2016 at 12:14, John Meinel 
>>> wrote:
>>>
 What image did you import into LXD? You should use something like:
   lxd-images import ubuntu trusty --alias ubuntu-trusty

 (substitute xenial/wily etc as relevant.)

 That looks like you are using an image from linuxcontainers.org which
 is very different from the ones built by cloud-images.ubuntu.com

 John
 =:->


 On Sat, Feb 27, 2016 at 4:09 PM, Tom Barber 
 wrote:

> Thanks John
>
> That was sort of my thinking too. But it's not a groups thing that I
> can see. Same issue as root or as unprivileged users.
>
>
> bugg@tomsdevbox:~$ groups
>
> bugg lxd
>
> bugg@tomsdevbox:~$ lxd --version
> 2.0.0.beta2
>
>
> bugg@tomsdevbox:~$ lxc --version
> 2.0.0.beta2
>
>
> at which point the bootstrap trust image starts fine, and i can
>
> lxc exec juju-.. /bin/bash
>
> into it. But sshd isn't running which explains why the connection
> refused error appears.
>
> Tom
>
> On 27 Feb 2016 11:56, "John Meinel"  wrote:
>
>> Connection refused isn't the error you would be getting if it was the
>> current incompatibilities. What you're seeing looks more like you aren't 
>> in
>> the "LXD" group, or you didn't refresh your groups after installing LXD.
>> (newgrp lxd)
>>
>> John
>> =:->
>>
>>
>> On Sat, Feb 27, 2016 at 12:08 AM, Tom Barber > > wrote:
>>
>>> No worries Serge I was just some Friday fun to get me out of the
>>> daily grind. Thanks for the update.
>>>
>>> Tom
>>> On 26 Feb 2016 

Re: LXD Bootstrap

[John Meinel]

BTW, if you are comfortable running Juju from master, there is a branch
"lxd-container-type" which should support LXD 2.0.0~beta4 (I have it
running here), and I'd be happy to get feedback on it.

John
=:->


On Sat, Feb 27, 2016 at 4:55 PM, John Meinel  wrote:

> That does seem correct. But I thought cloud-images run openssh by default.
> So that seems surprising.
>
> What happens if you just do "lxc create" to spawn an instance instead of
> using Juju?
>
> John
> =:->
>
>
> On Sat, Feb 27, 2016 at 4:17 PM, Tom Barber 
> wrote:
>
>> I used:
>>
>> lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty
>>
>> Which I stole from Jorge's blog.
>>
>> bugg@tomsdevbox:~$ lxc image list
>>
>> ++--++++--+--+
>> | ALIAS  | FINGERPRINT  | PUBLIC |DESCRIPTION
>> |  ARCH  |   SIZE   | UPLOAD DATE  |
>>
>> ++--++++--+--+
>> | ubuntu-precise | 4029ee764a39 | no | Ubuntu 12.04 LTS server
>> (20160222) | x86_64 | 155.25MB | Feb 26, 2016 at 5:12pm (CET) |
>> | ubuntu-trusty  | 510c27eb5e30 | no | Ubuntu 14.04 LTS server
>> (20160222) | x86_64 | 118.51MB | Feb 26, 2016 at 5:13pm (CET) |
>> | ubuntu-wily| fb2cf6ab4af1 | no | Ubuntu 15.10 server (20160222)
>> | x86_64 | 154.27MB | Feb 26, 2016 at 5:12pm (CET) |
>>
>> ++--++++--+--+
>>
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 27 February 2016 at 12:14, John Meinel  wrote:
>>
>>> What image did you import into LXD? You should use something like:
>>>   lxd-images import ubuntu trusty --alias ubuntu-trusty
>>>
>>> (substitute xenial/wily etc as relevant.)
>>>
>>> That looks like you are using an image from linuxcontainers.org which
>>> is very different from the ones built by cloud-images.ubuntu.com
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Sat, Feb 27, 2016 at 4:09 PM, Tom Barber 
>>> wrote:
>>>
 Thanks John

 That was sort of my thinking too. But it's not a groups thing that I
 can see. Same issue as root or as unprivileged users.


 bugg@tomsdevbox:~$ groups

 bugg lxd

 bugg@tomsdevbox:~$ lxd --version
 2.0.0.beta2


 bugg@tomsdevbox:~$ lxc --version
 2.0.0.beta2


 at which point the bootstrap trust image starts fine, and i can

 lxc exec juju-.. /bin/bash

 into it. But sshd isn't running which explains why the connection
 refused error appears.

 Tom

 On 27 Feb 2016 11:56, "John Meinel"  wrote:

> Connection refused isn't the error you would be getting if it was the
> current incompatibilities. What you're seeing looks more like you aren't 
> in
> the "LXD" group, or you didn't refresh your groups after installing LXD.
> (newgrp lxd)
>
> John
> =:->
>
>
> On Sat, Feb 27, 2016 at 12:08 AM, Tom Barber 
> wrote:
>
>> No worries Serge I was just some Friday fun to get me out of the
>> daily grind. Thanks for the update.
>>
>> Tom
>> On 26 Feb 2016 8:02 pm, "Serge E. Hallyn"  wrote:
>>
>>> On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote:
>>> > Afternoon, got bored decided to try Jorge's blog post about Juju
>>> LXD and ZFS
>>> >
>>> > I'd read on a few posts about the requirement for LXD beta2
>>> because of API
>>> > incompatibilities so I found the deb's and installed them.
>>> >
>>> > Its up and running and images start fine, but juju bootstrap fails
>>> with
>>> > connection refused when trying to SSH in. Something stupid i'm
>>> doing or
>>> > just broke for now?
>>>
>>> Hi Tom,
>>>
>>> Yeah it's just broken for now.  It will be fixed when a new feature
>>> branch
>>> is merged, which I think is supposed to happen on or before Monday.
>>>
>>> -serge
>>>
>>
>> --
>> 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: LXD Bootstrap

[John Meinel]

That does seem correct. But I thought cloud-images run openssh by default.
So that seems surprising.

What happens if you just do "lxc create" to spawn an instance instead of
using Juju?

John
=:->


On Sat, Feb 27, 2016 at 4:17 PM, Tom Barber  wrote:

> I used:
>
> lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty
>
> Which I stole from Jorge's blog.
>
> bugg@tomsdevbox:~$ lxc image list
>
> ++--++++--+--+
> | ALIAS  | FINGERPRINT  | PUBLIC |DESCRIPTION
> |  ARCH  |   SIZE   | UPLOAD DATE  |
>
> ++--++++--+--+
> | ubuntu-precise | 4029ee764a39 | no | Ubuntu 12.04 LTS server
> (20160222) | x86_64 | 155.25MB | Feb 26, 2016 at 5:12pm (CET) |
> | ubuntu-trusty  | 510c27eb5e30 | no | Ubuntu 14.04 LTS server
> (20160222) | x86_64 | 118.51MB | Feb 26, 2016 at 5:13pm (CET) |
> | ubuntu-wily| fb2cf6ab4af1 | no | Ubuntu 15.10 server (20160222)
> | x86_64 | 154.27MB | Feb 26, 2016 at 5:12pm (CET) |
>
> ++--++++--+--+
>
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 27 February 2016 at 12:14, John Meinel  wrote:
>
>> What image did you import into LXD? You should use something like:
>>   lxd-images import ubuntu trusty --alias ubuntu-trusty
>>
>> (substitute xenial/wily etc as relevant.)
>>
>> That looks like you are using an image from linuxcontainers.org which is
>> very different from the ones built by cloud-images.ubuntu.com
>>
>> John
>> =:->
>>
>>
>> On Sat, Feb 27, 2016 at 4:09 PM, Tom Barber 
>> wrote:
>>
>>> Thanks John
>>>
>>> That was sort of my thinking too. But it's not a groups thing that I can
>>> see. Same issue as root or as unprivileged users.
>>>
>>>
>>> bugg@tomsdevbox:~$ groups
>>>
>>> bugg lxd
>>>
>>> bugg@tomsdevbox:~$ lxd --version
>>> 2.0.0.beta2
>>>
>>>
>>> bugg@tomsdevbox:~$ lxc --version
>>> 2.0.0.beta2
>>>
>>>
>>> at which point the bootstrap trust image starts fine, and i can
>>>
>>> lxc exec juju-.. /bin/bash
>>>
>>> into it. But sshd isn't running which explains why the connection
>>> refused error appears.
>>>
>>> Tom
>>>
>>> On 27 Feb 2016 11:56, "John Meinel"  wrote:
>>>
 Connection refused isn't the error you would be getting if it was the
 current incompatibilities. What you're seeing looks more like you aren't in
 the "LXD" group, or you didn't refresh your groups after installing LXD.
 (newgrp lxd)

 John
 =:->


 On Sat, Feb 27, 2016 at 12:08 AM, Tom Barber 
 wrote:

> No worries Serge I was just some Friday fun to get me out of the daily
> grind. Thanks for the update.
>
> Tom
> On 26 Feb 2016 8:02 pm, "Serge E. Hallyn"  wrote:
>
>> On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote:
>> > Afternoon, got bored decided to try Jorge's blog post about Juju
>> LXD and ZFS
>> >
>> > I'd read on a few posts about the requirement for LXD beta2 because
>> of API
>> > incompatibilities so I found the deb's and installed them.
>> >
>> > Its up and running and images start fine, but juju bootstrap fails
>> with
>> > connection refused when trying to SSH in. Something stupid i'm
>> doing or
>> > just broke for now?
>>
>> Hi Tom,
>>
>> Yeah it's just broken for now.  It will be fixed when a new feature
>> branch
>> is merged, which I think is supposed to happen on or before Monday.
>>
>> -serge
>>
>
> --
> 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: LXD Bootstrap

[Tom Barber]

I used:

lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty

Which I stole from Jorge's blog.

bugg@tomsdevbox:~$ lxc image list
++--++++--+--+
| ALIAS  | FINGERPRINT  | PUBLIC |DESCRIPTION
  |  ARCH  |   SIZE   | UPLOAD DATE  |
++--++++--+--+
| ubuntu-precise | 4029ee764a39 | no | Ubuntu 12.04 LTS server
(20160222) | x86_64 | 155.25MB | Feb 26, 2016 at 5:12pm (CET) |
| ubuntu-trusty  | 510c27eb5e30 | no | Ubuntu 14.04 LTS server
(20160222) | x86_64 | 118.51MB | Feb 26, 2016 at 5:13pm (CET) |
| ubuntu-wily| fb2cf6ab4af1 | no | Ubuntu 15.10 server (20160222)
  | x86_64 | 154.27MB | Feb 26, 2016 at 5:12pm (CET) |
++--++++--+--+


--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 27 February 2016 at 12:14, John Meinel  wrote:

> What image did you import into LXD? You should use something like:
>   lxd-images import ubuntu trusty --alias ubuntu-trusty
>
> (substitute xenial/wily etc as relevant.)
>
> That looks like you are using an image from linuxcontainers.org which is
> very different from the ones built by cloud-images.ubuntu.com
>
> John
> =:->
>
>
> On Sat, Feb 27, 2016 at 4:09 PM, Tom Barber 
> wrote:
>
>> Thanks John
>>
>> That was sort of my thinking too. But it's not a groups thing that I can
>> see. Same issue as root or as unprivileged users.
>>
>>
>> bugg@tomsdevbox:~$ groups
>>
>> bugg lxd
>>
>> bugg@tomsdevbox:~$ lxd --version
>> 2.0.0.beta2
>>
>>
>> bugg@tomsdevbox:~$ lxc --version
>> 2.0.0.beta2
>>
>>
>> at which point the bootstrap trust image starts fine, and i can
>>
>> lxc exec juju-.. /bin/bash
>>
>> into it. But sshd isn't running which explains why the connection refused
>> error appears.
>>
>> Tom
>>
>> On 27 Feb 2016 11:56, "John Meinel"  wrote:
>>
>>> Connection refused isn't the error you would be getting if it was the
>>> current incompatibilities. What you're seeing looks more like you aren't in
>>> the "LXD" group, or you didn't refresh your groups after installing LXD.
>>> (newgrp lxd)
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Sat, Feb 27, 2016 at 12:08 AM, Tom Barber 
>>> wrote:
>>>
 No worries Serge I was just some Friday fun to get me out of the daily
 grind. Thanks for the update.

 Tom
 On 26 Feb 2016 8:02 pm, "Serge E. Hallyn"  wrote:

> On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote:
> > Afternoon, got bored decided to try Jorge's blog post about Juju LXD
> and ZFS
> >
> > I'd read on a few posts about the requirement for LXD beta2 because
> of API
> > incompatibilities so I found the deb's and installed them.
> >
> > Its up and running and images start fine, but juju bootstrap fails
> with
> > connection refused when trying to SSH in. Something stupid i'm doing
> or
> > just broke for now?
>
> Hi Tom,
>
> Yeah it's just broken for now.  It will be fixed when a new feature
> branch
> is merged, which I think is supposed to happen on or before Monday.
>
> -serge
>

 --
 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: LXD Bootstrap

[John Meinel]

What image did you import into LXD? You should use something like:
  lxd-images import ubuntu trusty --alias ubuntu-trusty

(substitute xenial/wily etc as relevant.)

That looks like you are using an image from linuxcontainers.org which is
very different from the ones built by cloud-images.ubuntu.com

John
=:->


On Sat, Feb 27, 2016 at 4:09 PM, Tom Barber  wrote:

> Thanks John
>
> That was sort of my thinking too. But it's not a groups thing that I can
> see. Same issue as root or as unprivileged users.
>
>
> bugg@tomsdevbox:~$ groups
>
> bugg lxd
>
> bugg@tomsdevbox:~$ lxd --version
> 2.0.0.beta2
>
>
> bugg@tomsdevbox:~$ lxc --version
> 2.0.0.beta2
>
>
> at which point the bootstrap trust image starts fine, and i can
>
> lxc exec juju-.. /bin/bash
>
> into it. But sshd isn't running which explains why the connection refused
> error appears.
>
> Tom
>
> On 27 Feb 2016 11:56, "John Meinel"  wrote:
>
>> Connection refused isn't the error you would be getting if it was the
>> current incompatibilities. What you're seeing looks more like you aren't in
>> the "LXD" group, or you didn't refresh your groups after installing LXD.
>> (newgrp lxd)
>>
>> John
>> =:->
>>
>>
>> On Sat, Feb 27, 2016 at 12:08 AM, Tom Barber 
>> wrote:
>>
>>> No worries Serge I was just some Friday fun to get me out of the daily
>>> grind. Thanks for the update.
>>>
>>> Tom
>>> On 26 Feb 2016 8:02 pm, "Serge E. Hallyn"  wrote:
>>>
 On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote:
 > Afternoon, got bored decided to try Jorge's blog post about Juju LXD
 and ZFS
 >
 > I'd read on a few posts about the requirement for LXD beta2 because
 of API
 > incompatibilities so I found the deb's and installed them.
 >
 > Its up and running and images start fine, but juju bootstrap fails
 with
 > connection refused when trying to SSH in. Something stupid i'm doing
 or
 > just broke for now?

 Hi Tom,

 Yeah it's just broken for now.  It will be fixed when a new feature
 branch
 is merged, which I think is supposed to happen on or before Monday.

 -serge

>>>
>>> --
>>> 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: LXD Bootstrap

[Tom Barber]

Thanks John

That was sort of my thinking too. But it's not a groups thing that I can
see. Same issue as root or as unprivileged users.


bugg@tomsdevbox:~$ groups

bugg lxd

bugg@tomsdevbox:~$ lxd --version
2.0.0.beta2


bugg@tomsdevbox:~$ lxc --version
2.0.0.beta2


at which point the bootstrap trust image starts fine, and i can

lxc exec juju-.. /bin/bash

into it. But sshd isn't running which explains why the connection refused
error appears.

Tom

On 27 Feb 2016 11:56, "John Meinel"  wrote:

> Connection refused isn't the error you would be getting if it was the
> current incompatibilities. What you're seeing looks more like you aren't in
> the "LXD" group, or you didn't refresh your groups after installing LXD.
> (newgrp lxd)
>
> John
> =:->
>
>
> On Sat, Feb 27, 2016 at 12:08 AM, Tom Barber 
> wrote:
>
>> No worries Serge I was just some Friday fun to get me out of the daily
>> grind. Thanks for the update.
>>
>> Tom
>> On 26 Feb 2016 8:02 pm, "Serge E. Hallyn"  wrote:
>>
>>> On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote:
>>> > Afternoon, got bored decided to try Jorge's blog post about Juju LXD
>>> and ZFS
>>> >
>>> > I'd read on a few posts about the requirement for LXD beta2 because of
>>> API
>>> > incompatibilities so I found the deb's and installed them.
>>> >
>>> > Its up and running and images start fine, but juju bootstrap fails with
>>> > connection refused when trying to SSH in. Something stupid i'm doing or
>>> > just broke for now?
>>>
>>> Hi Tom,
>>>
>>> Yeah it's just broken for now.  It will be fixed when a new feature
>>> branch
>>> is merged, which I think is supposed to happen on or before Monday.
>>>
>>> -serge
>>>
>>
>> --
>> 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: LXD Bootstrap

[John Meinel]

Connection refused isn't the error you would be getting if it was the
current incompatibilities. What you're seeing looks more like you aren't in
the "LXD" group, or you didn't refresh your groups after installing LXD.
(newgrp lxd)

John
=:->


On Sat, Feb 27, 2016 at 12:08 AM, Tom Barber 
wrote:

> No worries Serge I was just some Friday fun to get me out of the daily
> grind. Thanks for the update.
>
> Tom
> On 26 Feb 2016 8:02 pm, "Serge E. Hallyn"  wrote:
>
>> On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote:
>> > Afternoon, got bored decided to try Jorge's blog post about Juju LXD
>> and ZFS
>> >
>> > I'd read on a few posts about the requirement for LXD beta2 because of
>> API
>> > incompatibilities so I found the deb's and installed them.
>> >
>> > Its up and running and images start fine, but juju bootstrap fails with
>> > connection refused when trying to SSH in. Something stupid i'm doing or
>> > just broke for now?
>>
>> Hi Tom,
>>
>> Yeah it's just broken for now.  It will be fixed when a new feature branch
>> is merged, which I think is supposed to happen on or before Monday.
>>
>> -serge
>>
>
> --
> 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: LXD Bootstrap

[Tom Barber]

No worries Serge I was just some Friday fun to get me out of the daily
grind. Thanks for the update.

Tom
On 26 Feb 2016 8:02 pm, "Serge E. Hallyn"  wrote:

> On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote:
> > Afternoon, got bored decided to try Jorge's blog post about Juju LXD and
> ZFS
> >
> > I'd read on a few posts about the requirement for LXD beta2 because of
> API
> > incompatibilities so I found the deb's and installed them.
> >
> > Its up and running and images start fine, but juju bootstrap fails with
> > connection refused when trying to SSH in. Something stupid i'm doing or
> > just broke for now?
>
> Hi Tom,
>
> Yeah it's just broken for now.  It will be fixed when a new feature branch
> is merged, which I think is supposed to happen on or before Monday.
>
> -serge
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Serge E. Hallyn]

On Fri, Feb 26, 2016 at 02:42:51PM +, Tom Barber wrote:
> Afternoon, got bored decided to try Jorge's blog post about Juju LXD and ZFS
> 
> I'd read on a few posts about the requirement for LXD beta2 because of API
> incompatibilities so I found the deb's and installed them.
> 
> Its up and running and images start fine, but juju bootstrap fails with
> connection refused when trying to SSH in. Something stupid i'm doing or
> just broke for now?

Hi Tom,

Yeah it's just broken for now.  It will be fixed when a new feature branch
is merged, which I think is supposed to happen on or before Monday.

-serge

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

On Jorge's advice I rolled all the way back to the juju 1.26 beta 2 tag,
lxd beta 2 and xenial and still it fails with connection refused weird.
On 26 Feb 2016 16:02, "Tom Barber"  wrote:

> I've tried rolling back on Juju but still can't find a combination, its
> not the end of the world, I was curious. Anyway, if I lxc exec into the
> machine I find SSH is down which sorta explains the connection failure:
>
> cloud init runs but then seems to get no futher
>
> https://gist.github.com/buggtb/c5785a74a1124cdc7bb7  <- bootstrap debug
> output.
>
>
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 26 February 2016 at 14:44, Tom Barber  wrote:
>
>> Sorry forgot to mention, Juju was built from trunk this morning.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 26 February 2016 at 14:42, Tom Barber  wrote:
>>
>>> Afternoon, got bored decided to try Jorge's blog post about Juju LXD and
>>> ZFS
>>>
>>> I'd read on a few posts about the requirement for LXD beta2 because of
>>> API incompatibilities so I found the deb's and installed them.
>>>
>>> Its up and running and images start fine, but juju bootstrap fails with
>>> connection refused when trying to SSH in. Something stupid i'm doing or
>>> just broke for now?
>>>
>>> Cheers
>>>
>>>
>>> Tom
>>>
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

I've tried rolling back on Juju but still can't find a combination, its not
the end of the world, I was curious. Anyway, if I lxc exec into the machine
I find SSH is down which sorta explains the connection failure:

cloud init runs but then seems to get no futher

https://gist.github.com/buggtb/c5785a74a1124cdc7bb7  <- bootstrap debug
output.



--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 26 February 2016 at 14:44, Tom Barber  wrote:

> Sorry forgot to mention, Juju was built from trunk this morning.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 26 February 2016 at 14:42, Tom Barber  wrote:
>
>> Afternoon, got bored decided to try Jorge's blog post about Juju LXD and
>> ZFS
>>
>> I'd read on a few posts about the requirement for LXD beta2 because of
>> API incompatibilities so I found the deb's and installed them.
>>
>> Its up and running and images start fine, but juju bootstrap fails with
>> connection refused when trying to SSH in. Something stupid i'm doing or
>> just broke for now?
>>
>> Cheers
>>
>>
>> Tom
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: LXD Bootstrap

[Tom Barber]

Sorry forgot to mention, Juju was built from trunk this morning.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 26 February 2016 at 14:42, Tom Barber  wrote:

> Afternoon, got bored decided to try Jorge's blog post about Juju LXD and
> ZFS
>
> I'd read on a few posts about the requirement for LXD beta2 because of API
> incompatibilities so I found the deb's and installed them.
>
> Its up and running and images start fine, but juju bootstrap fails with
> connection refused when trying to SSH in. Something stupid i'm doing or
> just broke for now?
>
> Cheers
>
>
> Tom
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju