Open Stack

In general, I think this is a good idea. Rather than putting the logic
for this in tripleoclient, it would be better to put it in
tripleo-common. Then the --assign-profiles just calls the function
imported from tripleo-common. This way the GUI could consume the same logic.

On 11/09/2015 09:51 AM, 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.
> 
> (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