Open Stack

Hi Steve,

I am sorry for my confusing message.
Just for clarification, I am against adding new abstracts to the HOT
template. I just wanted to highlight that in Lakshminarayana proposal there
are multiple steps which represent the same component in different stages.
This might be confusing, because in you initial proposal you refer one
component section for the whole component description, if I am not mistaken.

Thanks
Georgy


On Tue, Oct 29, 2013 at 12:23 AM, Steven Hardy <shardy at redhat.com> wrote:

> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/1a579f46/attachment.html>