Heat/Blueprints/StackLifecycleSchedulerHint

Stack lifecycle scheduler hint blueprint

Scope: [Short overview and high level description of what the blueprint is trying to achieve.]

A heat provider to may have a need for custom code to examine stack requests prior to performing the operations to create or update a stack. After the custom code completes, the provider may want to provide hints to the nova scheduler with stack related identifiers, for custom scheduler plug-in processing within Nova. The blueprint describes a mechanism whereby when heat processes a stack, the stack id, root stack id, stack resource id, stack resource name and the path in the stack (as a list of tuples, (stackresourcename, stackname)) can be passed to nova by heat as scheduler hints, to the configured schedulers for nova.

Use Cases: [Short overview and high level description of what the blueprint is trying to achieve.]
Enabling holistic scheduling in Heat to provide heat stack/resource identifiers as a hint for scheduler processing within nova, such that a resource scheduler can identify scheduling decisions previously made for resources in a heat stack.

Implementation Overview: [Provide an overview of the implementation and any algorithms that will be used]

Modifications to instance.py and server.py classes to support providing stack hints to the nova scheduler if a new heat configuration option stack_ids_as_scheduler_hints is set to true. Within both these two classes the handle_create() makes the call to nova create to create the individual servers. Before this call is made additional scheduler hints are added with values of the stack id, root stack id, stack resource id, stack resource name and the path in the stack (as a list of tuples, (stackresourcename, stackname)). heat_root_stack_id will be set to the id of the root stack of the resource, heat_stack_id will be set to the id of the resource's parent stack, # heat_stack_name will be set to the id of the resource's parent stack, heat_path_in_stack will be set to a list of tuples, (stackresourcename, stackname) with list[0] being (None, rootstackname), and heat_resource_name will be set to the resource's name. . The implementer of a Nova plugin scheduler can use these hints to identify holistic scheduler decisions previously made, e.g. in a callout within heat via an extension made using the stack lifecycle plugpoint.

Data Model Changes: [Are you introducing new model classes, or extending existing ones?]

[N/A]

Configuration variables: [List and explanation of the new configuration variables (if they exist)]

[N/A]

API's: [List and explanation of the new API's (if they exist)]

[N/A]

Plugin Interface: [Does this feature introduce any change?]

[N/A]

Required Plugin support: [What should the plugins do to support this new feature? (If applicable)] Plugins that support holistic scheduling should use this hint to identify scheduling decisions previously made in Heat. Dependencies: [List of python packages and/or OpenStack components? (If applicable)] [N/A]

CLI Requirements: [List of CLI requirements (If applicable)]

[N/A]

Horizon Requirements: [List of Horizon requirements (If applicable)]

[N/A]

Usage Example: [How to run/use/interface with the new feature. (If applicable)]

Samples would be provided

Test Cases: [Description of various test cases. (If applicable)]

Submit heat template to the heat server. Develop a nova scheduler plugin stub to read heat_stack_id in hint and validate new id.