Open Stack

On 19/03/15 06:17, VACHNIS, AVI (AVI) wrote:
> 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."

I think you're asking the wrong question here; it isn't a question of 
what is _allowed_. The plugin runs in the same memory space as 
everything else in Heat. It's _allowed_ to do anything that is possible 
from Python code. The question for anyone writing a plugin is whether 
that's smart.

In terms of guarantees, we can't offer any at all since we don't have 
any plugins in-tree and participating in continuous integration testing.

The plugin interface itself should be considered stable (i.e. there 
would be a long deprecation cycle for any backward-incompatible 
changes), and if anyone brought an accidental breakage to our attention 
I think it would be cause for a revert or fix.

The read-only behaviour of the arguments passed to the plugin as 
parameters (e.g. the Stack object) is not considered stable. In practice 
it tends to change relatively slowly, but there's much less attention 
paid to not breaking this for lifecycle plugins than there is e.g. for 
Resource plugins.

Finally, the behaviour on write of the arguments is not only not 
considered stable, but support for it even working once is explicitly 
disclaimed. You are truly on your own if you try this.

>  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?

I don't think the word 'parameter' there refers to the user-supplied 
template parameters, it refers to the formal parameter of the plugin's 
do_p[re|ost]_op() method named 'stack'.

On the availability zone thing specifically, I think the way forward is 
to give cloud operators a more sophisticated way of selecting the AZ 
when the user doesn't specify one (i.e. just requests the default). That 
could happen inside Heat, but it would probably be more general if it 
happened in Nova.

You might already be aware of another blueprint that's being worked on 
for distributing scaling group members among AZs. I haven't caught up 
with the latest discussion on that, but I think at some point in the 
future we'll want to make that selection pluggable so that operators can 
have their own schedulers make the decisions there. However, that would 
be a separate plugin interface to the lifecycle plugins.

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

Whether the user has given the cloud provider permission is really the 
least of the worries.

> In case such grant appears in the stack, the plug-point code is allowed to modify the stack to provide the desired service.

Again, it's not a matter of being allowed. It's a matter of whether the 
community would freeze future development (e.g. convergence would have 
to be cancelled) in order to maintain complete internal API stability 
(we won't), or whether you're prepared to pay someone to constantly 
maintain your plugin as internal Heat changes constantly break it (I 
wouldn't, but it's up to you).

> I guess it may be a possible enabler to Congress' policies as well.

That sounds truly horrifying.

cheers,
Zane.