Open Stack

On Mon, Oct 28, 2013 at 04:48:45PM -0400, Mike Spreitzer wrote:
> Steve Baker <sbaker at redhat.com> wrote on 10/28/2013 04:24:30 PM:
> 
> > On 10/29/2013 02:53 AM, Steven Hardy wrote:
> > > ...
> > > Can anyone provide me with a clear argument for what the "fundamental
> > > differences" actually are?
> > ...
> > Since writing those proposals my thinking has evolved too. I'm currently
> > thinking it would be best to implement software configuration resources
> > rather than create a new component construct.
> 
> Please pardon the newbie question, but I do not understand.  A resource 
> type is implemented in OpenStack code --- a part of Heat that calls a 
> fixed service API that expects Keystone credentials.  

This is not true at all.

A resource is simply an abstraction, a container for data, possibly logic,
which has interfaces (inputs/properties, and outputs/attributes)

There a several ways to define a resource.  One of them is to write a Heat
python plugin, which may, or may not talk to another OpenStack API, but
this is completely unrelated to the concept of a resource.

Another way to define a resource is via a Heat template ("Provider"
resources, combined with environments).  This is a convenient way for users
to define their own resources, and to layer additional data, logic and
dependencies on top of existing Heat built-in resources.

> A component is 
> implemented by a bit of user code (and/or other sorts of instructions) 
> embedded in or referenced by a template, with no fixed API and not invoked 
> with Keystone credentials.  We desire the heat engine to invoke operations 
> on resources; we do not desire the heat engine to invoke components (the 
> VMs do that themselves, via whatever bootstrapping mechanism is used).  So 
> yes, I do see fundamental differences.  What am I missing?

A component is simply some user-provided data, possibly combined with some
logic, which needs to be passed to some resource (or service, or
in-instance tool) which knows how to interpret it.

So the existing resource interface is a perfectly appropriate abstraction
to use to describe what folks have been calling components, IMO.

If we can avoid creating a new template abstraction, we avoid a whole pile
of complexity, as well as user confusion - it's much better to leverage what
we have, unless the abstraction turns out to be fundamentally incompatible
with the feature (my argument is that it's not).

Steve