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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev