Ask Your Question

cdent's profile - activity

2020-02-13 06:33:11 -0500 answered a question psycopg2 postgresql and placment DBAPI Error

This is a bug in in placement, probably because postgresql is not tested enough. If you can please open a bug on storyboard:!/p... Include your tracebacks.

2020-01-02 04:53:28 -0500 answered a question A valid trait must be no longer than 255 characters, start with the prefix \"CUSTOM_\" and use following characters

You need a newer version of the os-traits library installed where the placement service is running. COMPUTE_NODE was added as an official trait in October.

2019-09-07 06:25:02 -0500 answered a question Why does "placement status upgrad check" throw exception on Stein

Since you're doing an upgrade rather than a clean install you may need some different steps, have a look at:

The error you're getting suggests that the command may not be looking at the configuration file you think it is. You can make it explicit by passing a "--config-file PATH" argument placement-status

2019-06-27 08:13:38 -0500 received badge  Teacher (source)
2019-06-27 04:32:54 -0500 answered a question No credentials specified for placement API in nova.conf

While it's true, as Eranachandran says, that you need to configure the placement service itself using a placement.conf you still need to configured a [placement] section in nova.conf so that the compute and controller nodes know how to access and authenticate to the placement service. See the [placement]part of the instructions at ( (near the end of that section).

If you've already got that section, and the credentials in it are correct, then you may have issues with your Keystone service.

2019-05-17 10:53:38 -0500 commented question Stein: failed to create resource provider

You have a placement-api-conf and a db called 'placement' so you are most likely using the extracted placement (pulled out of nova in Stein). You need to figure out is why you are getting a 409. Most likely a duplicate name, the log for the placement api server will say.

2018-12-20 06:44:38 -0500 answered a question Why does Placement api need Public endpoint access?

The eventual plan has always been that placement will be accessible by lots of different services and at some point down the line, non-admin users, so starting it out using a public endpoint made sense so that it would be necessary to later say "oh yeah, add another endpoint for placement".

2018-12-20 06:38:34 -0500 commented answer nova scheduler - no allocation candidates from the placement API

If your flavor is asking for disk, then placement will be asked for disk. It sounds like your flavors may not be ideally set up.

2018-12-20 06:37:01 -0500 commented question nova scheduler - no allocation candidates from the placement API

The placement service does have logging but it seems to end up in different places depending on how the service is deployed.

Or are you saying that the logging in there but it is not complete enough? If the latter, improvements to that have been backported to rocky, but I'm not sure about queens.

2018-12-20 06:33:55 -0500 answered a question How to update vcpu allocation_ratio dynamically?

At the moment what you describe is the behavior as things are coded: the compute node's configuration will control the allocation_ratio that gets reported, and any changes you make over the placement API will be clobbered when the periodic job on the nova-compute runs again. So the way to change the allocation ratio is to update nova.conf.

This is planned to be fixed in Stein.

2018-12-20 06:31:09 -0500 commented question PackStack installed Ocata launch instance [Error: No valid host was found. There are not enough hosts available.].

Agree, the nova-compute log will provide more information about what is happening. It might be that it is not configured with the correct authentication for placement, or is unable to reach the placement service over the network.

2018-12-20 06:27:34 -0500 answered a question HA setup for placement api on ocata release

The port you use to host placement behind haproxy doesn't really matter. It doesn't have to even be a special port. It is perfectly fine to put it on port 80 or port 443 is there is nothing else running on the web server, or if a prefix (such as /placement) is being used.

What matters is what the haproxy exposes to the rest of the world and what is in the service catalog. Ideally the service in the catalog would not use non-standard HTTP ports but would instead either use prefixes or hostnames, e.g. things like: