Remove the column 'can_host' from the ResourceProvider table

[Ed Leafe]

There is a column in the ResourceProvider table named 'can_host'. It is used to distinguish compute nodes (can_host=1) from shared storage providers (can_host=0) for queries that need to distinguish those different types of providers. However, the name is very Nova-specific, and when the Placement engine is extended to support a variety of resource allocation requirements, it will probably cause confusion. After a discussion on IRC, we decided to change the name to "shared", and reverse any logic using can_host, since can_host=1 will now be shared=0, and vice-versa.

[Chris Dent (cdent)]

I remain somewhat unconvinced that can_host or shared are necessary when we have resource classes. Doesn't VCPU mean 'can_host'?

Or I suppose the problem there is that in the world of NUMA VCPU is not always going to be a requested resource class for something destined for a compute-node? If that's the case that seems like a potential semantic problem that ought to resolved, rather than making a special case flag for compute-node/not-compute-node.

[Ed Leafe (ed-leafe)]

Jay explained it more as an aid in constructing the SQL for distinguishing shared disk providers vs. compute node disk providers. So in that sense, joining to the VCPU class would work, but would make the hairy SQL even hairier.

[Matt Riedemann (mriedem)]

From what I can tell, we don't even set can_host to anything to signal a compute node today.

[Jay Pipes (jaypipes)]

We're not going to use the can_host field. Instead, the new MISC_SHARES_VIA_AGGREGATE trait is being used to identify providers that share resources. So, I think this bug should be changed to "Remove the can_host column from the resource_providers table"

[Ed Leafe (ed-leafe)]

Changed. I'll start working on this

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/461494

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/461494
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=fcfe28192eaa63d2ca000d38bc435a5e662ad8f5
Submitter: Jenkins
Branch: master

commit fcfe28192eaa63d2ca000d38bc435a5e662ad8f5
Author: EdLeafe <email address hidden>
Date: Mon May 1 15:32:06 2017 +0000

    Remove the can_host column

    Originally it was felt that we would need this column to distinguish
    between compute nodes and non-compute providers. With the advent of
    traits, though, this column is no longer used or needed.

    Closes-Bug: #1648197

    Change-Id: I614db98727f4737deb6728ee874ab0f68024ebe5

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 16.0.0.0b2 development milestone.

[Christian Rohmann (christian-rohmann)]

Hello Ed,

I just ran into this bug while working on the migration from PostgreSQL to MySQL on an Ussuri installation using https://pypi.org/project/psql2mysql/ and got errors on copying over the table placement.resource_providers from the existing db (PostgreSQL) to a newly initialized MariaDB.

Your change https://review.opendev.org/c/openstack/nova/+/461494 does cause the column for newly initialized (db sync) databases to not be created anymore, but what about existing databases? There seems to be no SQL schema update task to drop this column at any point. So it will live on forever in installs that started when this column was still a thing.

Or am I missing something here?

[Ed Leafe (ed-leafe)]

On Jun 14, 2022, at 04:10, Christian Rohmann <email address hidden> wrote:
>
> Your change https://review.opendev.org/c/openstack/nova/+/461494 does
> cause the column for newly initialized (db sync) databases to not be
> created anymore, but what about existing databases? There seems to be no
> SQL schema update task to drop this column at any point. So it will live
> on forever in installs that started when this column was still a thing.
>
> Or am I missing something here?

I would imagine it would be like the rest of OpenStack: older systems continue to function as is. I'm not sure of the upgrade path for older systems, but having that column there shouldn't be an issue, as it should no longer be referenced in any code accessing the DB.

-- Ed Leafe