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