Yeah. Unmesh, we need to have ResourcePropertiesObserved. The columns too need
to be as mentioned in blueprint. Having all properties under a single json will
cause concurrency issues.
-Vishnu
-Original Message-
From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
Sent: Wednesday,
Hi All,
Below is the model proposal for persisting ResourceGraph.
Column name
Type
Constraint
resource_id
varchar(36)
NOT NULL ForeignKey resource.id
needed_by
varchar(36)
NULL ForeignKey resource.id
stack_id
varchar(36)
NOT NULL ForeignKey stack.id
retry_count
Integer
Default (0)
Hi all,
Convergence-POC distributes stack operations by sending resource actions over
RPC for any heat-engine to execute. Entire stack lifecycle will be controlled
by worker/observer notifications. This distributed model has its own advantages
and disadvantages.
Any stack operation has a
a
liveness issue and not a resource timeout one), those 2 things seem separable.
[1] http://docs.openstack.org/developer/taskflow/jobs.html
[2]
http://docs.openstack.org/developer/taskflow/examples.html#jobboard-producer-consumer-simple
On Nov 13, 2014, at 12:29 AM, Murugan, Visnusaran
-dev] [Heat] Using Job Queues for timeout ops
On Thu, Nov 13, 2014 at 6:29 PM, Murugan, Visnusaran
visnusaran.muru...@hp.commailto:visnusaran.muru...@hp.com wrote:
Hi all,
Convergence-POC distributes stack operations by sending resource actions over
RPC for any heat-engine to execute. Entire
, November 13, 2014 7:05 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] Using Job Queues for timeout ops
On 13/11/14 06:52, Angus Salkeld wrote:
On Thu, Nov 13, 2014 at 6:29 PM, Murugan, Visnusaran
visnusaran.muru...@hp.com mailto:visnusaran.muru...@hp.com wrote
Hi All,
Latest convergence-poc code is available [1]
Reason for this fork was to avoid constant rebase. Wiki [2] also has been
updated to reflect latest changes/deviations. One prominent deviation from
convergence-blueprint is that observer and workers are not separate operating
system
Hi Zane,
At this stage our implementation (as mentioned in
wikihttps://wiki.openstack.org/wiki/Heat/ConvergenceDesign) achieves your
design goals.
1. In case of a parallel update, our implementation adjusts graph
according to new template and waits for dispatched resource tasks to
-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com]
Sent: Tuesday, December 9, 2014 3:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] Convergence proof-of-concept showdown
On 08/12/14 07:00, Murugan, Visnusaran wrote:
Hi Zane Michael
support ;)
Apologies :) I screwed up my mail client's configuration.
On 10/12/14 06:42, Murugan, Visnusaran wrote:
Well, we still have to persist the dependencies of each version of a
resource _somehow_, because otherwise we can't know how to clean them
up in the correct order. But what I
-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com]
Sent: Friday, December 12, 2014 6:37 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] Convergence proof-of-concept
showdown
On 11/12/14 08:26, Murugan, Visnusaran wrote:
[Murugan
Hi zaneb,
Etherpad updated.
https://etherpad.openstack.org/p/execution-stream-and-aggregator-based-convergence
-Original Message-
From: Murugan, Visnusaran
Sent: Friday, December 12, 2014 4:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re
-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] Convergence proof-of-concept
showdown
On 12/12/14 05:29, Murugan, Visnusaran wrote:
-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com]
Sent: Friday, December 12, 2014 6:37 AM
To: openstack-dev
Steve,
My reasoning to have a “--continue” like functionality was to run it as a
periodic task and substitute continuous observer for now.
“--continue” based command should work on realized vs. actual graph and issue a
stack update.
I completely agree that user action should not be needed to
14 matches
Mail list logo