[openstack-dev] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services

VACHNIS, AVI (AVI) avi.vachnis at alcatel-lucent.com
Thu Mar 19 10:17:05 UTC 2015


I'm looking at this interesting blueprint https://blueprints.launchpad.net/heat/+spec/stack-lifecycle-plugpoint and I hope you can easily clarify some things to me.
I see the following statements related to this BP:
* [in "problem description" section]: "There are at least two primary use cases. (1) Enabling holistic (whole-pattern) scheduling of the virtual resources in a template instance (stack) prior to creating or deleting them. This would usually include making decisions about where to host virtual resources in the physical infrastructure to satisfy policy requirements. "
* [in "proposed change" section]: "Pre and post operation methods should not modify the parameter stack(s). Any modifications would be considered to be a bug. "
* [in Patch set 7 comment by Thomas]: "Are the plug-ins allowed to modify the stack? If yes, what parts can they modify? If not, should some code be added to restrict modifications?"
* [in Patch set 8 comment by Bill] : "@Thomas Spatzier, The cleanest approach would be to not allow changes to the stack parameter(s). Since this is cloud-provider-supplied code, I think that it is reasonable to not enforce this restriction, and to treat any modifications of the stack parameter(s) as a defect in the cloud provider's extension code."

>From the problem description one might understand it's desired to allow modification of resource placement (i.e. "making decisions where to host...") by cloud provider plug-point code. Does "should not modify the parameter stack" blocks this desired capability? Or is it just a rule not to "touch" original parameters' values but still allow modifying, let's say availability_zone property as long it's not effected by stack parameters?

In case the original purpose of plugpoint mechanism doesn't allow changing the stack, I'd suggest letting the user creating the stack, explicitly 'grant' the cloud provider to enhance his stack characteristics by enabling cloud provider's extra services.
By 'explicitly grant' I thought on introducing a sort of a Policy resource type that the stack creator will be able to express his desired services he want to leverage. 
In case such grant appears in the stack, the plug-point code is allowed to modify the stack to provide the desired service.
I guess it may be a possible enabler to Congress' policies as well. 


More information about the OpenStack-dev mailing list