[placement] Train upgrade warning

melanie witt melwittt at gmail.com
Fri Oct 30 16:50:03 UTC 2020


On 10/30/20 01:37, Seth Tunstall wrote:
> Hello,
> 
> On 10/28/20 12:01, melanie witt wrote:
>  >> The main idea of the row deletions is to delete "orphan" records 
> which are records tied to an instance's lifecycle when that instance no 
> longer exists. Going forward, nova will delete these records itself at 
> instance deletion time but did not in the past because of bugs, and any 
> records generated before a bug was fixed will become orphaned once the 
> associated instance is deleted.
> 
> I've done the following in this order:
> 
> nova-manage api_db sync
> 
> nova-manage db sync
> 
> (to bring the DBs up to the version I'm upgrading to (Train)
> 
> nova-manage db archive_deleted_rows --verbose --until-complete

The thing I notice here ^ is that you didn't (but should) use 
--all-cells to also clean up based on the nova_cell0 database (where 
instances that failed scheduling go). If you've ever had an instance go 
into ERROR state for failing the scheduling step and you deleted it, its 
nova_api.instance_mappings record would be a candidate for being 
archived (removed).

<snip>

> # placement-status upgrade check
> +-----------------------------------------------------------------------+
> | Upgrade Check Results |
> +-----------------------------------------------------------------------+
> | Check: Missing Root Provider IDs |
> | Result: Success |
> | Details: None |
> +-----------------------------------------------------------------------+
> | Check: Incomplete Consumers |
> | Result: Warning |
> | Details: There are -2 incomplete consumers table records for existing |
> | allocations. Run the "placement-manage db |
> | online_data_migrations" command. |
> +-----------------------------------------------------------------------+
> 
> argh! again a negative number! But at least it's only 2, which is well 
> within the realm of manual fixes.

The only theory I have for how this occurred is you have 2 consumers 
that are orphaned due to missing the nova_cell0 during database 
archiving ... Like if you have a couple of deleted instances in 
nova_cell0 and thus still have nova_api.instance_mappings and without 
--all-cells those instance_mappings didn't get removed and so affected 
the manual cleanup query you ran (presence of instance_mappings 
prevented deletion of 2 orphaned consumers).

If that's not it, then I'm afraid I don't have any other ideas at the 
moment.

-melanie



More information about the openstack-discuss mailing list