Open Stack

Hi Lakshminarayanan,

I believe the extensions you proposed will extend HOT software components
usability. In general I have only one concern related to components naming.
In your examples you have software components like install_mysql (you got
it from Steve's example) and configure_app.
I would say, that these components are not software components, but some
actions on software components. This is a small deviation from declarative
approach as in general declarative objects more or less independent while
actions are naturally have some sequence. For example your configure_app
should not be executed before install_app and technically it is the same
component on different stages. I don't know what is inside puppet manifest
in configure_app but it might contain app installation phase or might not.

>From my perspective it will be better to add some concepts of actions for
components and have some predefined actions like pre_install, install,
post_install and probably some custom actions. This will be more clear
approach then declaring action as a software component. This is quite
typical approach in different PaaS solutions.

Thanks
Georgy


On Mon, Oct 28, 2013 at 8:08 AM, Randall Burt <randall.burt at rackspace.com>wrote:

>
> On Oct 28, 2013, at 9:49 AM, Steven Hardy <shardy at redhat.com> wrote:
>
> > On Mon, Oct 28, 2013 at 02:33:40PM +0000, Randall Burt wrote:
> >>
> >> On Oct 28, 2013, at 8:53 AM, Steven Hardy <shardy at redhat.com>
> >> wrote:
> >>
> >>> On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana
> wrote:
> >>>> A few us at IBM studied Steve Baker's proposal on HOT Software
> >>>> Configuration. Overall the proposed constructs and syntax are great
> -- we
> >>>> really like the clean syntax and concise specification of components.
> We
> >>>> would like to propose a few minor extensions that help with better
> >>>> expression of dependencies among components and resources, and in-turn
> >>>> enable cross-vm coordination. We have captured our thoughts on this
> on the
> >>>> following Wiki page
> >>>>
> >>>>
> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response
> >>>
> >>> Thanks for putting this together.  I'll post inline below with
> cut/paste
> >>> from the wiki followed by my response/question:
> >>>
> >>>> E2: Allow usage of component outputs (similar to resources):
> >>>> There are fundamental differences between components and resources...
> >>>
> >>> So... lately I've been thinking this is not actually true, and that
> >>> components are really just another type of resource.  If we can
> implement
> >>> the software-config functionality without inventing a new template
> >>> abstraction, IMO a lot of the issues described in your wiki page no
> longer
> >>> exist.
> >>>
> >>> Can anyone provide me with a clear argument for what the "fundamental
> >>> differences" actually are?
> >>>
> >>> My opinion is we could do the following:
> >>> - Implement software config "components" as ordinary resources, using
> the
> >>> existing interfaces (perhaps with some enhancements to dependency
> >>> declaration)
> >>> - Give OS::Nova::Server a components property, which simply takes a
> list of
> >>> resources which describe the software configuration(s) to be applied
> >>
> >> I see the appeal here, but I'm leaning toward having the components
> define the resources they apply to rather than extending the interfaces of
> every compute-related resource we have or may have in the future. True,
> this may make things trickier in some respects with regard to bootstrapping
> the compute resource, but then again, don't most configuration management
> systems work on active compute instances?
> >
> > What "every" though?  Don't we have exactly one compute resource,
> > OS::Nova::Server?  (I'm assuming this functionality won't be available
> via
> > AWS compatible Instance resource)
>
> Yes, I suppose it wouldn't do to go extending the AWS compatibility
> interface with this functionality, so I withdraw my concern.
>
> >
> > Steve
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> 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/20131028/195c82ee/attachment.html>