Ask Your Question

number9's profile - activity

2019-10-18 03:19:25 -0600 received badge  Famous Question (source)
2019-05-13 04:40:45 -0600 received badge  Teacher (source)
2019-05-06 05:26:43 -0600 received badge  Notable Question (source)
2019-04-28 21:59:38 -0600 answered a question Image stuck in spawning state

Solved this problem. As embarrassing as this sounds, it was the following configuration error (I found no others):

in /etc/default/etcd, the line:

ETC_INITIAL_CLUSTER='default=http://controller:2380'

was to be changed to match your configuration. Unfortunately, I read that as it was telling me to put:

ETC_INITIAL_CLUSTER='default=http://hpccloud:2380'

Where "hpccloud" was my controller. It actually wants the configuration to say:

ETC_INITIAL_CLUSTER='hpccloud=http://hpccloud:2380'

I suppose I read it wrong, or it actually still does not make sense to me why someone would write a configuration line that way, but whatever, my instance does spawn to completion now... I now have to solve a networking issue as the instance is not accessible, but it is spawning with an IP assigned to it from the dhcp range and it is showing up active.

Thanks for all of the help so far.

2019-04-28 06:28:30 -0600 received badge  Enthusiast
2019-04-26 17:00:46 -0600 commented question Image stuck in spawning state

I have tested the tiny cirros image. I also changed the network which seemed to be failing. It is now going from spawning to error, the image is still 200KB, and I am finding timeout errors in the neutron-linuxbridge-agent log. Other forum posts point to rabbitmq, but I think that is working.

2019-04-26 09:08:22 -0600 received badge  Popular Question (source)
2019-04-26 08:06:51 -0600 commented question Image stuck in spawning state

eblock said: Maybe something's wrong with the base image and its swap? I forgot to mention that I have tried several images (again, linked to by the official openstack docs). Each one fails the same way.

2019-04-26 08:06:50 -0600 commented question Image stuck in spawning state

eblock said: Can you check if /var/lib/nova/instances/_base/abc261a53dd1e62f06a0d7cd2fc8da800b68383a has a valid size? It is 2.2Gigs. Also, I did see the log about it not being able to resize the image. I am using the openstack images they link to from ubuntu. Not sure why that would fail.

2019-04-26 08:06:50 -0600 commented question Image stuck in spawning state

This system will not let me respond to individual comments but: searching for e501e9b6-e4ac-464f-b1d6-9a5439c5c269/ fails. Searching for abc261a53dd1e62f06a0d7cd2fc8da800b68383a just gets logs about it "checking". I am using a stock image. Not sure why it would not resize it.

2019-04-26 06:09:49 -0600 answered a question OpenStack (Rocky): VM not spawning on provider network though it is successfully getting spawned on self-service network.

I just started with openstack, and mine is not running either... but, I think if this is your first error:

2019-04-23 16:32:39.324 1751 ERROR neutron.plugins.ml2.drivers.agent._common_agent [req-4342b879-a822-4c06-9882-ad06c04b1660 - - - - -] Error in agent loop. Devices info: {'current': set(['tap807a015e-9c']), 'timestamps': {'tap807a015e-9c': 10}, 'removed': set([]), 'added': set(['tap807a015e-9c']), 'updated': set([])}: NetlinkError: (13, 'Permission denied')

Then that last part that says "permission denied" should be the place to start. Can you look in your normal linux logs (audit, syslog) and see if the PAM/auth/system is denying openstack from creating the bridge?

2019-04-25 10:23:10 -0600 asked a question Image stuck in spawning state

I have a new openstack install on a compute node and controller node, bare metal. It all seems to work until I try to instantiate and instance. It just hangs in spawning.

On the compute node, I can find the node in the /var/lib/nova/ directory, but the disk file is like 200KB. I have read the faqs, searched and read forum posts, etc... most of them point to a lack of resources, but I have 900GB of disk and countless CPU cores and memory free. I have logged a bit at the time of spawning, and I will reproduce it here. Any help would be greatly appreciated.

Steps taken so far:

Checked resources on the compute node, has nearly 1TB of free storage, 628GB of ram free and 76 CPUs free. Checked permissions on the directories. Tried to debug by turning on debugging on nova on both controller and compute node. I can not see anything totally out of the ordinary. Logs do not show any errors, only warnings.

Followed some advice from here to no avail also:

https://stackoverflow.com/questions/47504867/openstack-vm-instance-stuck-in-spawning-state (https://stackoverflow.com/questions/4...)

I removed the original debugs, as I think they are a red herring. The network (I think) was not properly setup, so I went back and set it up as per these docs: https://computingforgeeks.com/creating-openstack-network-and-subnets/ (https://computingforgeeks.com/creatin...) Now at least when I spawn an instance the dashboard shows the correct IPs.

Now there are no libvirt logs as user eblock was asking for, but I do see this in the neutron-linuxbridge-agent.log:

2019-04-26 11:56:11.394 2417 ERROR neutron.plugins.ml2.drivers.agent._common_agent MessagingTimeout:    Timed out waiting for a reply to message ID 900a069b1c5144ce810da1bae9066159
2019-04-26 11:56:11.394 2417 ERROR neutron.plugins.ml2.drivers.agent._common_agent 
2019-04-26 11:56:11.395 2417 WARNING oslo.service.loopingcall [-] Function 'neutron.plugins.ml2.drivers.agent._common_agent.CommonAgentLoop._report_state' run outlasted interval by  30.00 sec
2019-04-26 11:57:11.396 2417 ERROR neutron.plugins.ml2.drivers.agent._common_agent [-] Failed reporting state!: MessagingTimeout: Timed out waiting for a reply to message ID 7bbd26ab7c624dbeb24f60a1f827f119
2019-04-26 11:57:11.396 2417 ERROR neutron.plugins.ml2.drivers.agent._common_agent Traceback (most recent call last):
2019-04-26 11:57:11.396 2417 ERROR neutron.plugins.ml2.drivers.agent._common_agent   File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/agent/_common_agent.py", line 129, in _report_state
2019-04-26 11:57:11.396 2417 ERROR neutron.plugins.ml2.drivers.agent._common_agent     True)
2019-04-26 11:57:11.396 2417 ERROR neutron.plugins.ml2.drivers.agent._common_agent   File "/usr/lib/python2.7/dist-packages/neutron/agent/rpc.py", line 97, in report_state
2019-04-26 11:57:11.396 2417 ERROR neutron.plugins.ml2.drivers.agent._common_agent     return method(context, 'report_state', **kwargs)
2019-04-26 11:57:11.396 2417 ERROR neutron.plugins.ml2.drivers.agent._common_agent   File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 179, in call
2019-04-26 11:57:11.396 2417 ERROR neutron.plugins ...
(more)
2019-04-10 07:23:20 -0600 answered a question Login to horizon (dashboard) goes back to login, not the dashboard.

I keep trying to edit this post, but it just reverts back to the original. I fixed the original error, and now I have a new error and still can not get to the dashboard. I will post a new question as this one is not working.

Also, the solution to my problem was a cut/paste issue... when I did the keystone bootstrap I typed in the admin password, but when I did all of the other passwords they were cut/paste. The typed in one had one typo. Ouch.

2019-04-10 07:20:33 -0600 received badge  Editor (source)
2019-04-09 14:30:25 -0600 asked a question Login to horizon (dashboard) goes back to login, not the dashboard.

Revising as I solved the previous problem...

I have installed Openstack Rocky on Ubuntu 18 according to the official docs (https://docs.openstack.org/install-guide/openstack-services.html#minimal-deployment-for-rocky (https://docs.openstack.org/install-gu...)).

I have completed and verified every step of the way, and after installing Horizon, I was to verify by logging in (https://docs.openstack.org/horizon/rocky/install/verify-ubuntu.html (https://docs.openstack.org/horizon/ro...)).

When I go to login to horizon, I am using the admin user, the default domain and the admin user password that was setup previously in the docs.

When I login, it goes right back to the login page with no visible error.

Looking at the logs, I think the wsgi error is pointing me the in the right direction, I just have no idea how to check that direction further.

Looking in /var/log/apache/*.log I see these entries:

$ tail /var/log/apache2/*.log
==> /var/log/apache2/access.log <==

==> /var/log/apache2/error.log <==
[Wed Apr 10 06:25:02.673320 2019] [mpm_event:notice] [pid 2787:tid 140663456525248] AH00489: Apache/2.4.29 (Ubuntu) mod_wsgi/4.5.17 Python/2.7 configured -- resuming normal operations
[Wed Apr 10 06:25:02.673367 2019] [core:notice] [pid 2787:tid 140663456525248] AH00094: Command line: '/usr/sbin/apache2'
[Wed Apr 10 07:12:08.830918 2019] [mpm_event:notice] [pid 2787:tid 140663456525248] AH00491: caught SIGTERM, shutting down
[Wed Apr 10 07:12:09.292518 2019] [mpm_event:notice] [pid 20995:tid 140517840231360] AH00489: Apache/2.4.29 (Ubuntu) mod_wsgi/4.5.17 Python/2.7 configured -- resuming normal operations
[Wed Apr 10 07:12:09.292702 2019] [core:notice] [pid 20995:tid 140517840231360] AH00094: Command line: '/usr/sbin/apache2'
[Wed Apr 10 07:12:27.694762 2019] [wsgi:error] [pid 20999:tid 140517728519936] [remote 130.70.77.201:59630] INFO openstack_auth.plugin.base Attempted scope to domain Default failed, will attempt to scope to another domain.
[Wed Apr 10 07:12:29.817081 2019] [wsgi:error] [pid 20999:tid 140517728519936] [remote 130.70.77.201:59630] INFO openstack_auth.forms Login successful for user "admin" using domain "Default", remote address 130.70.77.201.

==> /var/log/apache2/keystone_access.log <==
10.131.36.21 - - [10/Apr/2019:07:03:16 -0500] "GET /v3/auth/tokens HTTP/1.1" 200 3983 "-" "python-keystoneclient"
10.131.36.21 - - [10/Apr/2019:07:08:18 -0500] "GET /v3/auth/tokens HTTP/1.1" 200 3983 "-" "python-keystoneclient"
10.131.36.21 - - [10/Apr/2019:07:12:23 -0500] "POST /v3/auth/tokens HTTP/1.1" 201 805 "-" "keystoneauth1/3.10.0 python-requests/2.18.4 CPython/2.7.15rc1"
10.131.36.21 - - [10/Apr/2019:07:12:25 -0500] "POST /v3/auth/tokens HTTP/1.1" 401 490 "-" "keystoneauth1/3.10.0 python-requests/2.18.4 CPython/2.7.15rc1"
10.131.36.21 - - [10/Apr/2019:07:12:27 -0500] "GET /v3/users/5e3920bdc30948e3a4896e57e0c13187/projects HTTP/1.1" 200 765 "-" "python-keystoneclient"
10.131.36.21 - - [10/Apr/2019 ...
(more)