Juju Openstack - Blocked

James Beedy jamesbeedy at gmail.com
Mon Feb 19 22:42:52 UTC 2018


I wanted to chime back in with the solution to the issue I was
experiencing.

The source of the issue undoubtedly was me. I was trying to launch a flavor
which had insufficient root-disk for a xenial.img (2G).

The the traceback which indicated the insufficient disk error was being
obfuscated by the user facing error I was seeing, block_device_mapping
error [0].
This alongside the erroneous log error messages from service startup led me
down unwarranted rabbit holes.

I thought I was deploying the most stripped down instance with the bare
essentials from the horizon ui, in reality (thanks beisner) you can deploy
an even more stripped down instance (without a block device) from the
command line with the command `openstack server create foo --flavor
<flavor-name> --image <image-name>`.

Deploying an instance without a block device allowed us to bypass the
block_device_mapping error and get the real underlying traceback [1].

Massive thanks to Beisner for taking the time to talk through that with me,
and pointing out the command^ that led us to the real error.


~James

[0] https://paste.ubuntu.com/p/pTPh5vhBPp/
[1] https://paste.ubuntu.com/p/3XtxTTFXHM/


On Thu, Feb 15, 2018 at 7:49 AM, James Beedy <jamesbeedy at gmail.com> wrote:

> Junaid and James,
>
>
> Thanks for the response. Here are the logs.
>
>
> Nova-Cloud-Controller
>
> $ cat /var/log/nova/nova-scheduler.log | http://paste.ubuntu.com/p/TQjD
> SXQSDt/
>
> $ cat /var/log/nova/nova-conductor.log | http://paste.ubuntu.com/p/68Tc
> mMCr82/
>
> $ sudo cat /var/log/nova/nova-api-os-compute.log |
> http://paste.ubuntu.com/p/5xWpXbD5PC/
>
>
> Neutron-Gateway
>
> $ sudo cat /var/log/neutron/neutron-metadata-agent.log  |
> http://paste.ubuntu.com/p/MW3qkQqntJ/
>
>
> $ sudo cat /var/log/neutron/neutron-openvswitch-agent.log |
> http://paste.ubuntu.com/p/qz3vfzG9b9/
>
>
> Neutron-api
>
> $ sudo cat /var/log/neutron/neutron-server.log |
> http://paste.ubuntu.com/p/sCCNw4bXtW/
>
> Thanks,
>
>
> James
>
>
> On Thu, Feb 15, 2018 at 7:24 AM, James Page <james.page at ubuntu.com> wrote:
>
>> Hi James
>>
>> On Wed, 14 Feb 2018 at 20:22 James Beedy <jamesbeedy at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am experiencing some issues with a base-openstack deploy.
>>>
>>> I can get a base-openstack to deploy legitimately using MAAS with no
>>> apparent errors from Juju's perspective. Following some init ops and the
>>> launching of an instance, I find myself stuck with errors I'm unsure how to
>>> diagnose. I upload an image, create my networks, flavors, and launch an
>>> instance, and see the instance erring out with a "host not found" error
>>> when I try to launch them.
>>>
>>> My nova/ceph node and neutron node interface configuration [0] all have
>>> a single flat 1G mgmt-net interface configured via MAAS, and vlans trunked
>>> in on enp4s0f0 (untracked by maas).
>>>
>>>
>>> Looking to the nova logs, I find [1] [2]
>>>
>>
>> You can ignore most of those errors - prior to the charm being fully
>> configured the daemons will log some error messages about broken db/rmq
>> etc...  newer reactive charms tend to disable services until config is
>> complete, older classic ones do not.
>>
>> The compute node is not recording and error which would indicate some
>> sort of scheduler problem - /var/log/nova/nova-scheduler.log from the
>> nova-cloud-controller would tell us more.
>>
>> The bundle I'm using [3] is lightly modified version of the openstack
>>> base bundle [4] with modifications to match my machine tags and mac
>>> addresses for my machines.
>>>
>>
>> Seems reasonable - bundles are meant as a start point after all!
>>
>> I've gone back and forth with network and charm config trying different
>>> combinations in hope this error is caused by some misconfiguration on my
>>> end, but I am now convinced this is something outside of my scope as an
>>> operator, and am hoping for some insight from the greater community.
>>>
>>> I seem to be able to reproduce this consistently (using both Juju <
>>> 2.3.2 and 2.3.2).
>>>
>>> Not even sure if I should create a bug somewhere as I'm not 100% sure
>>> this isn't my fault. Let me know if additional info is needed.
>>>
>>
>>  Lets dig into the scheduler log and see.
>>
>> Cheers
>>
>> James
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20180219/09948a7e/attachment.html>


More information about the Juju mailing list