openstack overcloud profiles * should validate "capabilities:node"

Bug #1716955 reported by Cédric Jeanneret deactivated on 2017-09-13
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Dear Stackers,

The commands `openstack overcloud profiles list' and `openstack overcloud profiles match <options>' should take care of the "node" capability we can set as shown in the following documentation:

That way, the `list' might show the correct information regarding role and image, and we can also validate we have enough nodes in ironic with the `match' command.

Also, this might relate to regarding the capacity to ensure nova actually sees the nodes as usable.

Thank you!



Steven Hardy (shardy) wrote :

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).

Changed in tripleo:
status: New → Triaged
milestone: none → queens-1

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:
  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:
    'capabilities:node': 'controller-%index%'
    'capabilities:node': 'compute-%index%'
    '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.



Changed in tripleo:
milestone: queens-1 → queens-2
Changed in tripleo:
milestone: queens-2 → queens-3
Changed in tripleo:
milestone: queens-3 → queens-rc1
Changed in tripleo:
importance: Undecided → Medium
milestone: queens-rc1 → rocky-1
Changed in tripleo:
milestone: rocky-1 → rocky-2
Changed in tripleo:
milestone: rocky-2 → rocky-3
Changed in tripleo:
milestone: rocky-3 → rocky-rc1
Changed in tripleo:
milestone: rocky-rc1 → stein-1
Changed in tripleo:
milestone: stein-1 → stein-2
Changed in tripleo:
milestone: stein-2 → stein-3

Is this something we should still address?

Cédric Jeanneret (cjeanner) wrote :

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"... ?

Changed in tripleo:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers