Open Stack

Thanks Zane. Please see inline.

-Avi

> -----Original Message-----
> From: Zane Bitter [mailto:zbitter at redhat.com]
> Sent: יום ו 20 מרץ 2015 22:13
> To: openstack-dev at 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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev