Ask Your Question

eswenson's profile - activity

2017-07-27 03:44:26 -0500 received badge  Famous Question (source)
2017-07-26 05:54:03 -0500 received badge  Notable Question (source)
2017-07-25 17:27:25 -0500 received badge  Popular Question (source)
2017-07-25 17:08:02 -0500 answered a question Getting unexpected NoValidHost: No valid host was found. There are not enough hosts available. error

The issue turned out to be this: The compute and controller nodes had FQDNs configured for their hostnames. The contents of /etc/hostname, and the value returned by hostname were FQDNs. This appears to be a Centos/RHEL default, or perhaps the result of bring up a Centos instance on AWS/EC2. In any case, Nova gets confused in this case and when trying to find a host on which to launch an instance, looks for entries in the various Nova database tables with the host name up to and excluding the first "." in the name. We ended up fixing this by correcting the hostnames on all instances, stopping all nova/neutron-related services, dropping all the SQL tables for nova, nova_api, and nova_cell0, re-syncing the api_db and db, and then restarting all services.

2017-07-24 22:01:54 -0500 commented question Getting unexpected NoValidHost: No valid host was found. There are not enough hosts available. error

I had done that and did it again. "nova-status upgrade check" shows that everything is good.

2017-07-24 18:55:30 -0500 asked a question Getting unexpected NoValidHost: No valid host was found. There are not enough hosts available. error

I'm running openstack ocata. Any attempt to launch any flavor and any instance results in the error: "No valid host was found. There are not enough hosts available." Examining nova-schedule.log on the control shows:

2017-07-24 02:38:56.046 14400 WARNING nova.scheduler.host_manager [req-498bfbb6-8940-4706-8322-9c893ba61763 9879cf1dc8954d5a9606fb555beed1fb f2d743585bd84323959131e1aabd885b - - -] No compute service record found for host ip-10-0-0-\
180
2017-07-24 02:38:56.047 14400 WARNING nova.scheduler.host_manager [req-498bfbb6-8940-4706-8322-9c893ba61763 9879cf1dc8954d5a9606fb555beed1fb f2d743585bd84323959131e1aabd885b - - -] No compute service record found for host ip-10-0-0-\
78
2017-07-24 02:38:56.047 14400 INFO nova.filters [req-498bfbb6-8940-4706-8322-9c893ba61763 9879cf1dc8954d5a9606fb555beed1fb f2d743585bd84323959131e1aabd885b - - -] Filter RetryFilter returned 0 hosts
2017-07-24 02:38:56.047 14400 INFO nova.filters [req-498bfbb6-8940-4706-8322-9c893ba61763 9879cf1dc8954d5a9606fb555beed1fb f2d743585bd84323959131e1aabd885b - - -] Filtering removed all hosts for the request with instance ID '4ed4c17\
9-22ad-4eaf-a417-3deebc6ccd06'. Filter results: ['RetryFilter: (start: 0, end: 0)']

Running "nova hypervisor-list" shows:

+----+---------------------------------------------+-------+---------+
| ID | Hypervisor hostname                         | State | Status  |
+----+---------------------------------------------+-------+---------+
| 3  | ip-10-0-0-180.eu-central-1.compute.internal | up    | enabled |
| 4  | ip-10-0-0-78.eu-central-1.compute.internal  | up    | enabled |
+----+---------------------------------------------+-------+---------+

Running "nova service-list" shows:

+----+------------------+---------------------------------------------+----------+---------+-------+----------------------------+-----------------+
| Id | Binary           | Host                                        | Zone     | Status  | State | Updated_at                 | Disabled Reason |
+----+------------------+---------------------------------------------+----------+---------+-------+----------------------------+-----------------+
| 9  | nova-cert        | ip-10-0-0-92.eu-central-1.compute.internal  | internal | enabled | up    | 2017-07-24T23:47:31.000000 | -               |
| 10 | nova-consoleauth | ip-10-0-0-92.eu-central-1.compute.internal  | internal | enabled | up    | 2017-07-24T23:47:36.000000 | -               |
| 11 | nova-conductor   | ip-10-0-0-92.eu-central-1.compute.internal  | internal | enabled | up    | 2017-07-24T23:47:40.000000 | -               |
| 12 | nova-scheduler   | ip-10-0-0-92.eu-central-1.compute.internal  | internal | enabled | up    | 2017-07-24T23:47:34.000000 | -               |
| 13 | nova-compute     | ip-10-0-0-180.eu-central-1.compute.internal | nova     | enabled | up    | 2017-07-24T23:47:31.000000 | -               |
| 14 | nova-compute     | ip-10-0-0-78.eu-central-1.compute.internal  | nova     | enabled | up    | 2017-07-24T23:47:36.000000 | -               |
+----+------------------+---------------------------------------------+----------+---------+-------+----------------------------+-----------------+

The two compute instances are up and running and have plenty of memory/disk/etc. I have never been successful in running even the tiniest of instance. The errors are always the same.

In nova-condutor.log, I see this:

2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager [req-498bfbb6-8940-4706-8322-9c893ba61763 9879cf1dc8954d5a9606fb555beed1fb f2d743585bd84323959131e1aabd885b - - -] Failed to schedule instances
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager Traceback (most recent call last):
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 866, in schedule_and_build_instances
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager     request_specs[0].to_legacy_filter_properties_dict())
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 597, in _schedule_instances
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager     hosts = self.scheduler_client.select_destinations(context, spec_obj)
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/scheduler/utils.py", line 371, in wrapped
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager     return func(*args, **kwargs)
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py", line 51, in select_destinations
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager     return self.queryclient.select_destinations(context, spec_obj)
2017-07-24 02:38:56.062 14437 ERROR nova.conductor.manager   File "/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py", line 37, in __run_method
2017-07-24 02:38:56.062 14437 ...
(more)
2016-06-27 11:11:08 -0500 answered a question How do you set Access-Control-Allow-Credentials CORS header

Hi SyCode7, I did manage to get around the issues, but it was so long ago and I haven't looked at our on-prem swift deployment in so longer that I've forgotten the details. Here is what I have in my notes that I added to /etc/swift/proxy-server.conf:

` [filter:crossdomain]

use = egg:swift#crossdomain

cross_domain_policy = <allow-access-from domain="xxx.example.com"/> `

However, I do remember making some other changes to the actual buckets I needed to be able to access -- I think I did the following:

`swift post xxxx --meta "Access-Control-Allow-Credentials: https://xxx.example.com"

swift post xxxx --meta "X-Container-Meta-Access-Control-Allow-Origin: https://xxx.example.com"

swift post xxxx --meta "Access-Control-Allow-Origin: https://xxx.example.com"

swift post xxxx --meta "Access-Control-Allow-Headers: https://xxx.example.com"

swift post xxxx --meta "Access-Control-Expose-Headers: https://xxx.example.com" `

What I don't remember is whether I had to patch any of the swift code. I'm sorry it's been too long since I worked on this. -- Eric

2016-06-23 07:35:13 -0500 received badge  Student (source)
2015-06-25 07:06:30 -0500 received badge  Famous Question (source)
2015-04-16 14:37:14 -0500 received badge  Notable Question (source)
2015-04-16 14:37:14 -0500 received badge  Popular Question (source)
2015-03-16 20:09:34 -0500 asked a question How do you set Access-Control-Allow-Credentials CORS header

I see that SWIFT supports Access-Control-Allow-Origin and Access-Control-Allow-Headers, but how do you get it to send Access-Control-Allow-Credentials headers? Chrome preflight requests are failing to allow POSTs to SWIFT containers (with a policy) because ORIGIN pre-flight requests don't return an Access-Control-Allow-Credentials header.

How can I make SWIFT do this, when the ORIGIN request is on the container to which the user wants to upload?

2014-10-25 09:41:06 -0500 commented answer How can I enable S3 for Swift storage

Virtually every quoted link I try to follow into http://docs.openstack.org lands me at the index page. Can someone update the above link to work? I can't seem to get at any S3 documentation within the openstack doc.