Steven Hardy wrote on 10/09/2013 05:24:38 AM:
>
> So as has already been mentioned, Heat defines an internal workflow,
based
> on the declarative model defined in the template.
>
> The model should define dependencies, and Heat should convert those
> dependencies into a workflow internally. IMO
/person/us-lrengan
Joshua Harlow wrote on 10/09/2013 03:55:00 PM:
> From: Joshua Harlow
> To: OpenStack Development Mailing List d...@lists.openstack.org>, Lakshminaraya Renganarayana/Watson/IBM@IBMUS
> Date: 10/09/2013 03:55 PM
> Subject: Re: [openstack-dev] [Heat] HOT Softwar
Georgy Okrokvertskhov wrote on 10/09/2013
03:37:01 PM:
> From: Georgy Okrokvertskhov
> To: OpenStack Development Mailing List
> Date: 10/09/2013 03:41 PM
> Subject: Re: [openstack-dev] [Heat] HOT Software orchestration
> proposal for workflows
>
> Thank you for bringing your use case and your
workflows language directly
> might harm HOT simplicity by overloaded DSL syntax and structures.
>
> I actually see the value in Steve's idea to have specific resource
> or resource set to call workflows execution on external engine. In
> this case HOT template will be still pret
Excellent discussion on various issues around orchestration and
coordination -- thanks to you all, in particular to Clint, Angus, Stan,
Thomas, Joshua, Zane, Steve ...
After reading the discussions, I am finding the following themes emerging
(please feel free to correct/add):
1. Most of the buil
Clint Byrum wrote on 10/11/2013 12:40:19 PM:
> From: Clint Byrum
> To: openstack-dev
> Date: 10/11/2013 12:43 PM
> Subject: Re: [openstack-dev] [Heat] HOT Software orchestration
> proposal for workflows
>
> > 3. Ability to return arbitrary (JSON-compatible) data structure from
config
> > appli
Hi Angus,
Thanks for detailed reply. I have a few comments that I have written below
in the context.
Angus Salkeld wrote on 10/13/2013 06:40:01 PM:
> >
> >- INPUTS: all the attributes that are consumed/used/read by that
resource
> >(currently, we have Ref, GetAttrs that can give this implicitl
Clint Byrum wrote on 10/16/2013 03:02:13 PM:
>
> Excerpts from Zane Bitter's message of 2013-10-16 06:16:33 -0700:
> >
> > For me the crucial question is, how do we define the interface for
> > synchronising and passing data from and to arbitrary applications
> > running under an arbitrary con
Hi,
In the last Openstack Heat meeting there was good interest in proposals for
cross-vm synchronization and communication and I had mentioned the
prototype I have built. I had also promised that I will post an outline of
the prototype ... Here it is. I might have missed some details, please feel
the cross-vm synchronization and communication of
values between the resources.
Thanks,
LN
Lakshminaraya Renganarayana/Watson/IBM@IBMUS wrote on 10/18/2013 02:45:01
PM:
> From: Lakshminaraya Renganarayana/Watson/IBM@IBMUS
> To: OpenStack Development Mailing List
> Date: 10/18/2013
bringing such solution to the Heat if it would be
> accepted by Heat's core team and community
>
>
> On Fri, Oct 18, 2013 at 10:45 PM, Lakshminaraya Renganarayana <
> lren...@us.ibm.com> wrote:
> Hi,
>
> In the last Openstack Heat meeting there was good interest in
re what
value
is passed between vmB.b1 and vmA.a1, so that the communication can be
facilitated
by the orchestration engine.
Thanks,
LN
>
> Lakshminaraya Renganarayana wrote on 18.10.2013
> 20:57:43:
> > From: Lakshminaraya Renganarayana
> > To: OpenStack Development Mailin
Zane Bitter wrote on 10/22/2013 09:24:28 AM:
>
> On 22/10/13 09:15, Thomas Spatzier wrote:
> > BTW, the convention of properties being input and attributes being
output,
> > i.e. that subtle distinction between properties and attributes is not
> > really intuitive, at least not to me as non-nativ
Hi Steven,
Steven Hardy wrote on 10/21/2013 11:27:43 AM:
>
> On Fri, Oct 18, 2013 at 02:45:01PM -0400, Lakshminaraya Renganarayana
wrote:
>
> > The prototype is implemented in Python and Ruby is used for chef
> > interception.
>
> Where can we find the code?
Wh
Hello,
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
Sorry, Re-posting this with [Heat] in the subject line, because many of us
have filters based on [Heat] in the subject line.
Hello,
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 synt
Robert Collins wrote on 10/28/2013 02:47:53 PM:
> BTW I found it a little weird that you replied as a new
> blueprint-scoped wiki page rather than an email, or as a discussion
> page on Steve's page.
It was a bit too long to directly post as an email text on the mailing
list. Also, posting it a
Georgy Okrokvertskhov wrote on 10/28/2013
02:18:42 PM:
>
> 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 fro
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 H
Zane, thanks very much for the detailed feedback. I have added my comments
inline.
Zane Bitter wrote on 10/29/2013 08:46:21 AM:
...
> As brief feedback on these suggestions:
> E1: Probably +1 for inputs, but tentative -1 for attributes. I'm not
> sure we can check anything useful with that other
-Mike Spreitzer/Watson/IBM@IBMUS wrote: ->To: "OpenStack Development Mailing List \(not for usage questions\)">>From: Mike Spreitzer/Watson/IBM@IBMUS>Date: 10/30/2013 03:56PM>Subject: Re: [openstack-dev] [Heat] Comments on Steve Baker's>Proposal on H
21 matches
Mail list logo
