Open Stack

Additions/comments inline below.

Thanks,
Unmesh G.
From: Murugan, Visnusaran
Sent: Thursday, September 18, 2014 1:46 PM
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [heat] Persist graph for convergence

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)

observed_ready

Boolean

Default False



Create cycle:

1.       Persist graph
[Unmesh] - So, it is a pre-requisite to persist all the resources of a stack (in the resource table) to be able to persist a graph (i.e step #0).

2.       Mark desired states for all resources in the stack. (table: resources)
[Unmesh] - This I believe should be done as a part of persisting a stack's resources (in step #0).

3.       Initiate stack create by calculating leaf nodes (All observed_ready=False nodes in resource_id column but not in needed_by column)

4.       Post create resource jobs to engine worker

5.       Engine worker upon task initiation posts observe task to convergence-observer and complete tack execution (return true)

6.       Mark observed_ready upon receiving resource completion notification from observer. Repeat step 3 through 6 till all nodes (resources) are marked observed_ready.
[Unmesh] - In case resource creation fails, the worker will increment retry_count and try creating the resource for a maximum of 'action_retry_limit' configured value.

7.       If not more nodes, then mark stack create complete and return happy

Update cycle:

1.       Persist new graph for new stack created

2.       Mark desired state for all resources in both old and new stacks.

3.       Perform steps 3 to 6

4.       Delete old stack, garbage collect unwanted resources

5.       Mark stack update complete and return happy.


Clint had in fact proposed to have a "version Integer default(0)". To achieve this I feel Table:Stack should also have versioning instead of creating a backup_stack.

Currently backup and nested stack relation is achieved using owner_id. In case if update, versioning makes more sense instead on creating a backup stack and setting owner_id as current stack.

-Vishnu





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140918/d80fd745/attachment.html>