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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
