-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
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
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
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
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
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
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
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
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
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
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
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
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
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 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/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
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
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
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
/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
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
21 matches
Mail list logo
