All:
I apologize but I decided to "start over" with this project. Wiped it all out and try again. That said, I can offer up some answers here.
The Openstack client - never caught the version number but it is whatever CentOS is distributing from their Caracal repo.
The installation is the results of these instructions:
https://docs.openstack.org/install-guide/openstack-services.html#minimal-deployment-for-2023-2-bobcat.
Yes, I know it's not Caracal but since there is no such thing
posted anywhere I can find. I figured the differences should be
minimal. The install is an all-in-one install with no load
balancers or anything fun like that.
I had found the problem with the install and it was what led to
my decision to start over. The WSGI linkage between the placement
code and httpd wasn't right. Doing a 'curl http://cloud:8778/'
was returning the Apache Welcome page and not the expected JSON
answer. I removed the welcome.conf from apache, restarted and was
getting a permissions denied page. Apache logs were showing 403
error codes on all requests.
I know it's not much to go on, but maybe it will help somehow. I
should have the rebuild done tonight and if you want I can provide
access (maybe a Jitsi Screen Share or a Google Meet).
Ron Gage
Hi Ron,
Please share:- openstack client version you are using- openrc contents (without secrets)- is it all-in-one installation? Are you using some kind of load balancer in front of services?
Regards,Franciszek
On 24 Sep 2024, at 16:17, Pierre Riteau <pierre@stackhpc.com> wrote:
The volume_backup_unset message is a red herring, as it comes from python-openstackclient itself. Ron, you may want to reinstall your client (but it won't solve your placement issues).
On Tue, 24 Sept 2024 at 15:28, Eugen Block <eblock@nde.ag> wrote:
Hi,
I'd start with debug logs for placement and see where it refers to
"volume_backup_unset". I don't have an idea how the volume backup gets
into the way here.
You could also run the command with the debug flag:
openstack --debug --os-placement-api-version 1.2 resource class list
and see if anything stands out.
What does a curl return when you query the endpoint directly? Here's
my output:
root@controller02:~# curl http://controller.domain:8778
{"versions": [{"id": "v1.0", "max_version": "1.36", "min_version":
"1.0", "status": "CURRENT", "links": [{"rel": "self", "href": ""}]}]}
Regards,
Eugen
Zitat von Ron Gage <ron@rongage.org>:
> Hi all:
>
> I must have done something wrong in the installation of Openstack
> Placement. I have been through the steps to install placement
> multiple times now. I am using the Caracal release. I am on CentOS
> Stream 9.
>
> Everything seems to be installed correctly. Indeed, the upgrade
> check returns no errors:
>
> [root@cloud ~]# placement-status upgrade check
> +-------------------------------------------+
> | Upgrade Check Results |
> +-------------------------------------------+
> | Check: Missing Root Provider IDs |
> | Result: Success |
> | Details: None |
> +-------------------------------------------+
> | Check: Incomplete Consumers |
> | Result: Success |
> | Details: None |
> +-------------------------------------------+
> | Check: Policy File JSON to YAML Migration |
> | Result: Success |
> | Details: None |
> +-------------------------------------------+
> [root@cloud ~]#
>
> Verifying operation however returns nothing:
>
> [root@cloud ~]# openstack --os-placement-api-version 1.2 resource class list
> Could not load 'volume_backup_unset': module
> 'openstackclient.volume.v2.volume_backup' has no attribute
> 'UnsetVolumeBackup'
> Expecting value: line 1 column 1 (char 0)
>
> The placement service has been defined (the host name is "cloud",
> not "controller").
>
> [root@cloud ~]# openstack endpoint list
> Could not load 'volume_backup_unset': module
> 'openstackclient.volume.v2.volume_backup' has no attribute
> 'UnsetVolumeBackup'
> +----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------+
> | ID | Region | Service Name |
> Service Type | Enabled | Interface | URL |
> +----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------+
> | 0e81501847db4aa38c864a2329a43052 | RegionOne | glance |
> image | True | admin | http://cloud:9292 |
> | 171c34b267674e798f625a811e87fcf8 | RegionOne | keystone |
> identity | True | admin | http://cloud:5000/v3/ |
> | 209386e7cddd44bbbbd5d5b3b9aa4ff5 | RegionOne | nova |
> compute | True | internal | http://cloud:8774/v2.1 |
> | 2f9d477115924b24a12204f54b1d6ddb | RegionOne | placement |
> placement | True | internal | http://cloud:8778 |
> | 58eb375281724e7998c0b6c8015302c4 | RegionOne | keystone |
> identity | True | public | http://cloud:5000/v3/ |
> | 618b400dc67c4038a6f62540f97d4246 | RegionOne | glance |
> image | True | internal | http://cloud:9292 |
> | 77843d0ddbac4cacb805cefd1c029544 | RegionOne | glance |
> image | True | public | http://cloud:9292 |
> | 8a8cca4fee32461fbe7836e756751df5 | RegionOne | keystone |
> identity | True | internal | http://cloud:5000/v3/ |
> | a01d89f6ea624e09af9d08d85e9bef40 | RegionOne | nova |
> compute | True | admin | http://cloud:8774/v2.1 |
> | d06d6b75e9bf4014b4de07df0bce8dd1 | RegionOne | placement |
> placement | True | public | http://cloud:8778 |
> | dfd618e52cc54af6bcf7afbf1a3a32cd | RegionOne | nova |
> compute | True | public | http://cloud:8774/v2.1 |
> | f6c41b2d7ba946908da5f0ed4d591c2a | RegionOne | placement |
> placement | True | admin | http://cloud:8778 |
> +----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------+
>
> What on earth could I have messed up to prevent the Placement API
> from working. Yes, I have restarted httpd.
>
> How do I know that Placement isn't working? Nova Conductor and Nova
> Scheduler can't connect to it (firewall is off and iptables rules
> are flushed) and therefore won't start properly. I can telnet to
> port 8778 yet the Nova services claim it can't connect.
>
> Thank you for your help!
>
> Ron Gage