Open Stack

On Mon, Oct 28, 2013 at 02:34:44PM -0700, Georgy Okrokvertskhov wrote:
> I believe we had a discussion about difference between declarative approach
> and workflows. A component approach is consistent with declarative format
> as all actions\operations are hidden inside the service. If you want to use
> actions and operations explicitly you will have to add a workflows specific
> language to HOT format. You will need to have some conditions and other
> control structures.

Please don't confuse the component/resource discussion further by adding
all these unrelated terms into the mix:

- Resources are declarative, components aren't in any way more declarative

- The resource/component discussion is unrelated to workflows, we're
  discussing the template level interfaces.

- Adding imperative control-flow interfaces to the template is the opposite
  of a declarative approach

> I also want to highlight that in most of examples on wiki pages there are
> actions instead of components. Just check names: install_mysql,
> configure_app.

Having descriptions of the actions required to do configure an application
is not declarative.  Having a resource define the properties of the
application is.

> I think you revealed the major difference between resource and component.
> While the first has a fixed API and Heat already knows how to work with it,

A resource doesn't have a fixed API as such - it has flexible, user-definable
interfaces (inputs/properties and outputs/attributes)

> components are not determined and Heat does not know what this component
> actually does.

Heat doesn't need to know what a resource or component actually does, it
needs to know what do do with the inputs/properties, and how to obtain the
outputs/attributes.

> I remember the first draft for Software components and it
> had a specific examples for yum invocation for package installation. This
> is a good example of declarative component. When scripts and recipes
> appeared a component definition was blurred.

This makes no sense, scripts defining platform specific installation
methods are the exact opposite of a declarative component.

The blurred component definition you refer to is a very good reason not to
add a new abstraction IMO - we should focus on adding the functionality via
the existing, well understood interfaces.

Steve