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 be more general if > it happened in Nova. As mentioned above, for the sophisticated way, my hunch is to define a resource placement type, but I'm happy to hear other alternatives. And just to be clear, whenever nova can do the job, it shall go there. > > 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. A separate plugin sounds as a great option. I'll be happy to join an existing effort or file a new BP for this. Please let me know. > > > 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. Please forget Congress :) I just wanted to get more comments on my use case, but I see that it’s now supported through Murano so I guess they are satisfied :) > > 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 __________________________________________________________________________ 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
