Open Stack

On 11/09/2015 03:51 PM, Dmitry Tantsur wrote:
> Hi folks!
>
> I spent some time thinking about bringing profile matching back in, so
> I'd like to get your comments on the following near-future plan.
>
> First, the scope of the problem. What we do is essentially kind of
> capability discovery. We'll help nova scheduler with doing the right
> thing by assigning a capability like "suits for compute", "suits for
> controller", etc. The most obvious path is to use inspector to assign
> capabilities like "profile=1" and then filter nodes by it.
>
> A special care, however, is needed when some of the nodes match 2 or
> more profiles. E.g. if we have all 4 nodes matching "compute" and then
> only 1 matching "controller", nova can select this one node for
> "compute" flavor, and then complain that it does not have enough hosts
> for "controller".
>
> We also want to conduct some sanity check before even calling to
> heat/nova to avoid cryptic "no valid host found" errors.
>
> (1) Inspector part
>
> During the liberty cycle we've landed a whole bunch of API's to
> inspector that allow us to define rules on introspection data. The plan
> is to have rules saying, for example:
>
>   rule 1: if memory_mb >= 8192, add capability "compute_profile=1"
>   rule 2: if local_gb >= 100, add capability "controller_profile=1"
>
> Note that these rules are defined via inspector API using a JSON-based
> DSL [1].
>
> As you see, one node can receive 0, 1 or many such capabilities. So we
> need the next step to make a final decision, based on how many nodes we
> need of every profile.
>
> (2) Modifications of `overcloud deploy` command: assigning profiles
>
> New argument --assign-profiles will be added. If it's provided,
> tripleoclient will fetch all ironic nodes, and try to ensure that we
> have enough nodes with all profiles.
>
> Nodes with existing "profile:xxx" capability are left as they are. For
> nodes without a profile it will look at "xxx_profile" capabilities
> discovered on the previous step. One of the possible profiles will be
> chosen and assigned to "profile" capability. The assignment stops as
> soon as we have enough nodes of a flavor as requested by a user.

New update: after talking to Imre on irc I realized that there's big 
value in decoupling profile validation/assigning from the deploy 
command. One of the use cases is future RAID work: we'll need to 
configure RAID based on the profile.

I'm introducing 2 new commands[*]:

1. overcloud profiles assign --XXX-flavor=YYY --XXX-scale=NN ..

    accepts the same arguments as deploy (XXX = compute, control, etc), 
tries to both validate and assign profiles. in the future we might add 
things like --XXX-raid-configuration to set RAID config for matched 
nodes. or even something generic like --XXX-set-property KEY=VALUE.

2. overcloud profiles list

   shows nodes and their profiles (including possible ones)

Deployment command will only do validation, following the same logic as 
'profiles assign' command.

The patch is not finished yet, but early reviews are welcome: 
https://review.openstack.org/#/c/250405/

[*] note that we more or less agreed on avoiding other projects' OSC 
namespaces, hence 'overcloud' prefix instead of 'baremetal'

>
> (3) Modifications of `overcloud deploy` command: validation
>
> To avoid 'no valid host found' errors from nova, the deploy command will
> fetch all flavors involved and look at the "profile" capabilities. If
> they are set for any flavors, it will check if we have enough ironic
> nodes with a given "profile:xxx" capability. This check will happen
> after profiles assigning, if --assign-profiles is used.
>
> Please let me know what you think.
>
> [1] https://github.com/openstack/ironic-inspector#introspection-rules
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev