Hi,

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. 

Thanks,
-Avi


__________________________________________________________________________
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

Reply via email to