openstack overcloud profiles * should validate "capabilities:node"

We probably need some discussion on how to approach this, since the profiles list command only really cares about the per-profile tagging performed via capabilities: profile, and not per-node tagging via capabilities: node (which aren't mapped to any profile, but instead work via *SchedulerHints parameters to control placement precisely on deploy.

I think we may need another command, or a pre-deployment validation to catch when the *SchedulerHints doesn't match the node tagging in ironic - I'm not really sure extending the profiles command to understand heat SchedulerHints is the right approach, but open to suggestions about how we might do that (currently it just looks at the nodes/flavors, the heat parameters aren't defined until the overcloud deploy).

Hello Steven,

Maybe a new subcommand "validate" might be added to "overcloud" part?

something like:

openstack overcloud validate --profiles --environment <env_file>

openstack overcloud validate --nodes --environment <env_file>

The env_file should contain in both cases:
parameter_defaults:
  ComputeCount: 2
  ControllerCount: 3
  CephStorageCount: 1

The first case will provide profiles through the ironic properties/capabilities.

For the latter case, the env_file must contain:
  ControllerSchedulerHints:
    'capabilities:node': 'controller-%index%'
  ComputeSchedulerHints:
    'capabilities:node': 'compute-%index%'
  CephStorageSchedulerHints:
    'capabilities:node': 'ceph-storage-%index%'

That way, we can validate the values in the env file as well - for the recall, the "--*-scale" and "--*-flavor" options are deprecated in the `openstack overcloud deploy' command, and should hence be removed from the other commands for consistency sake.

More over, if the "validate" subcommand can also query nova in order to ensure it sees the nodes, it's all the best.

This might even deprecate the "profiles" subcommand, IFF the validate can also do the dynamic matching. Or maybe push the `profiles' capabilities to `validate' - this would allow to get a common base/entry point for all pre-deploy validation.

Cheers,

C.

Is this something we should still address?

guess, if it's a validation thing, we can get it working as a pre-deploy validation via the new framework?

Viewing the traction on that one, guess we can close it as "wont-fix" or "invalid"... ?