Open Stack

I am wondering on the execution semantics of these components or software
config resources with respect to restart or re-execution. Coming from a
iterative development and deployment angle, I would like these software
config resources to be idempotent. What are your thoughts?

Thanks,
LN

Steven Hardy <shardy at redhat.com> wrote on 10/29/2013 03:23:14 AM:

> From: Steven Hardy <shardy at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 10/29/2013 03:28 AM
> Subject: Re: [openstack-dev] [Heat] Comments on Steve Baker's
> Proposal on HOT Software Config
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/cac2765b/attachment.html>