Heat/Blueprints/StackLifecycleSchedulerHint - Revision history

Barnold at 21:36, 21 October 2014

2014-10-21T21:36:22Z

Barnold at 18:17, 30 May 2014

2014-05-30T18:17:44Z

Barnold at 17:57, 30 May 2014

2014-05-30T17:57:35Z

Barnold: Stack lifecycle scheduler hint

2014-05-21T18:28:33Z

Stack lifecycle scheduler hint

New page

'''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 of custom code processing for scheduler plug-in processing within Nova. The blueprint describes a mechanism whereby the stack id/stack resource id can be passed to the nova scheduler as a hint when processing the stack resource. 

'''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. Within both these two classes the handle_create() makes the call to nova create to create the individual servers. Before this call is made an additional scheduler hint for the stack id plus stack resource name will be added. The key for this key/value pair will be ‘heat_stack_id’ the stack id of the stack being processed will be set as the value. The implementer of a Nova plugin scheduler can use this id to identify holistic scheduler decisions previously made in the callout within heat. 

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

@@ Line 3: / Line 3: @@
 '''Scope:''' [Short overview and high level description of what the blueprint is trying to achieve.] <br />
-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 resource, the stack id/stack resource id can be passed by heat as a hint, to the configured schedulers for nova.<br />
+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
 '''Use Cases:''' [Short overview and high level description of what the blueprint is trying to achieve.] <br />
@@ Line 10: / Line 11: @@
 Implementation Overview: [Provide an overview of the implementation and any algorithms that will be used] <br />
-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 an additional scheduler hint for the stack id plus stack resource name will be added.  The key for this key/value pair will be ‘heat_stack_id’ the stack id of the stack being processed will be set as the value. The implementer of a Nova plugin scheduler can use this id to identify holistic scheduler decisions previously made, e.g. in a callout within heat via an extension made using the stack lifecycle plugpoint.<br />
+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.<br />
 '''Data Model Changes:''' [Are you introducing new model classes, or extending existing ones?] <br />

@@ Line 3: / Line 3: @@
 '''Scope:''' [Short overview and high level description of what the blueprint is trying to achieve.] <br />
-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 of custom code processing for scheduler plug-in processing within Nova. The blueprint describes a mechanism whereby the stack id/stack resource id can be passed to the nova scheduler as a hint when processing the stack resource.<br />
+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 resource, the stack id/stack resource id can be passed by heat as a hint, to the configured schedulers for nova.<br />
 '''Use Cases:''' [Short overview and high level description of what the blueprint is trying to achieve.] <br />

@@ Line 10: / Line 10: @@
 Implementation Overview: [Provide an overview of the implementation and any algorithms that will be used] <br />
-Modifications to instance.py and server.py classes to support providing stack hints to the nova scheduler.   Within both these two classes the handle_create() makes the call to nova create to create the individual servers.  Before this call is made an additional scheduler hint for the stack id plus stack resource name will be added.  The key for this key/value pair will be ‘heat_stack_id’ the stack id of the stack being processed will be set as the value. The implementer of a Nova plugin scheduler can use this id to identify holistic scheduler decisions previously made in the callout within heat. <br />
+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 an additional scheduler hint for the stack id plus stack resource name will be added.  The key for this key/value pair will be ‘heat_stack_id’ the stack id of the stack being processed will be set as the value. The implementer of a Nova plugin scheduler can use this id to identify holistic scheduler decisions previously made, e.g. in a callout within heat via an extension made using the stack lifecycle plugpoint.<br />
 '''Data Model Changes:''' [Are you introducing new model classes, or extending existing ones?] <br />