juju deployed openstack nova-lxd cannot start instances

[Patrizio Bassi]

Dear James, All

i opened a bug, hope you can give it some love.
https://bugs.launchpad.net/juju/+bug/1690345

Thank you for support

Patrizio

Il giorno mar 9 mag 2017 alle 14:13 Patrizio Bassi <patrizio.bassi at gmail.com>
ha scritto:

> Dear James/all,
>
> I checked /etc/nova/nova.conf in kvm and lxd hypervisor and they look the
> same.
> Regarding glance section it just contains the same endpoint
>
> [glance]
> api_servers = http://10.10.10.95:9292
>
> Following the backtrace it seems it cannot get the image metadata at all.
> I checked the upstream source at https://github.com/openstack/
> nova-lxd/blob/master/nova/virt/lxd/driver.py#L398
>
> has changed the galnce-lxd sync code. Maybe it has been fixed already, did
> anyone try? do we have a bleeding edge ppa to test against?
>
> Patrizio
>
>
> 2017-05-08 18:21 GMT+02:00 Patrizio Bassi <patrizio.bassi at gmail.com>:
>
>>
>>
>> 2017-05-08 18:11 GMT+02:00 James Page <james.page at ubuntu.com>:
>>
>>> Hi Patrizio
>>>
>>> On Mon, 8 May 2017 at 11:53 Patrizio Bassi <patrizio.bassi at gmail.com>
>>> wrote:
>>> [...]
>>>
>>>> 1) [minor] accessing horizon in the hypervisor list it is seen as
>>>> hostname without fqdn while other 4 hosts has fqdn.
>>>>
>>>
>>> Yes there is a minor diff between LXD and KVM hypervisors:
>>>
>>>   https://bugs.launchpad.net/nova-lxd/+bug/1521319
>>>
>>> however that should not effect things functionally.
>>>
>>
>> Yes, it looks fine, but a bit ugly :)
>>
>>
>>>
>>>
>>>> 2) [major] i cannot boot a lxd image
>>>>
>>>> following https://jujucharms.com/u/openstack-charmers-next/
>>>> openstack-lxd/ i imported the xenial image in glance by
>>>>
>>>> # glance image-create --name="xenial_lxd" --visibility public
>>>> --progress --container-format=bare --disk-format=*root-tar* --property
>>>> architecture="x86_64" < ~/openstack/images/xenial-
>>>> server-cloudimg-amd64-root.tar.gz
>>>>
>>>> i got errors like:
>>>>
>>>> 8446f64e0b504345b48673a3e3a328f1 35515180b8b646329e2caa2372250e0b - -
>>>> -] [instance: e4daef69-525c-4413-b39b-7df5e7822f02] Build of instance
>>>> e4daef69-525c-4413-b39b-7df5e7822f02 aborted: *Image  is unacceptable:
>>>> Bad Image format: Image  could not be found.*
>>>>
>>>> in https://linuxcontainers.org//lxd/getting-started-openstack/ instead
>>>> i see it suggests *--disk-format=raw* but actually nothing changes for
>>>> me, same error.
>>>>
>>>
>>> The disk-format property for LXD images can be raw or root-tar - either
>>> should work.  That error is propagating up from the interaction of the
>>> driver with glance - which might indicate a missing relation between the
>>> nova-compute-lxd service and glance?
>>>
>>>
>>
>> It looks i have (i just replaced nova-compute with nova-lxd)
>>
>> # juju status|grep nova|grep glance
>> image-service            glance                 nova-cloud-controller
>>  regular
>> image-service            glance                 nova-compute
>> regular
>> image-service            glance                 *nova-lxd*
>> regular
>>
>> What else can i check?
>>
>>
>>> I tried with Trusty too, in case xenial image may have been corrupted,
>>>> same issue.
>>>>
>>>> So which format should we use for lxd, root-tar (i do think so) or raw?
>>>> And is lxd driver really working?
>>>>
>>>
>>> The root tarball format is the correct format to use.
>>>
>>
>> Ok, fine...even if in https://docs.openstack.org/
>> image-guide/image-formats.html or https://docs.openstack.
>> org/developer/glance/formats.html i can't find that format
>>
>>
>>
>>>
>>>> It was reported with a similar issue some months ago:
>>>> https://ask.openstack.org/en/question/101255/unable-to-
>>>> start-an-instance-using-nova-lxd/
>>>>
>>>> Another important issue is that lxd hypervisor seems to get scheduled
>>>> to run qcow2 images too, failing, but i guess this can be fixed by adding
>>>> hostgroup, i din't investigate yet.
>>>>
>>>
>>> Its possible to run both hypervisors in the same region, but you must
>>> set the hypervisor type property on all images:
>>>
>>>   --property hypervisor_type=lxc
>>>
>>> or
>>>
>>>   --property hypervisor_type=qemu
>>>
>>> Setting this value will ensure that when you boot an instance of the
>>> image, it gets scheduled to the correct hypervisor type for the image.
>>>
>>
>> This is great, it'll give a try as soon i can boot a lxd image (now i
>> just disabled all kvm hypervisors so just a lxd hypervisor is there).
>>
>>
>>>
>>> Hope that helps move your forward.
>>>
>>> James
>>>
>>
>> Thank you for support
>> Patrizio
>>
>
>
>
> --
>
> Patrizio Bassi
> www.patriziobassi.it
> http://piazzadelpopolo.patriziobassi.it
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170512/301d88d9/attachment.html>