Re: [openstack-dev] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services
Thanks Zane. Please see inline. -Avi -Original Message- From: Zane Bitter [mailto:zbit...@redhat.com] Sent: יום ו 20 מרץ 2015 22:13 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services 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. Right, of course we can do anything in python :) . By _allowed_ I meant would it be wise and future proof. 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. I totally understand and agree with this statement... unless a more sophisticated construct (as you said below) is provided and stitched to a specific argument. Just for illustration, today user can bind a server's property with an output of a another server/SoftwareConfig. It doesn’t feel so odd since the user has constructed dynamic value by using an official types model, Aka, a stable API. Now let’s assume we came to a conclusion that a Placement resource type is something we want in HOT (we've to thoroughly justify why, but let assume for now) then a user will bind this type's output to a certain stack resource property. I guess this is still the same as with any other type dependency (one output affect other property). Now, since we have the cloud provider plug-point and a Resource Placement Type (assume we have ;), I thought it will be appealing for cloud providers to provide their own implementation (e.g. override the default) for the Resource Placement Type interface. I can think of some alternative implementation but just wanted to bring the concept to the team for review early as possible. 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
Re: [openstack-dev] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services
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
[openstack-dev] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services
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
