On Mon, Oct 28, 2013 at 04:48:45PM -0400, Mike Spreitzer wrote:
> Steve Baker <sba...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
