Re: [openstack-dev] [heat] Convergence - persistence desired and observed state

2014-09-18 Thread Murugan, Visnusaran
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, September 17, 2014 6:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat] Convergence - persistence desired and 
observed state

On Wed, Sep 17, 2014 at 12:27:34PM +, Gurjar, Unmesh wrote:
 Hi All,
 
 The convergence blueprint (https://review.openstack.org/#/c/95907/) 
 introduces two new database tables (resource_observed and 
 resource_properties_observed ) for storing the observed state of a resource 
 (currently under review: https://review.openstack.org/#/c/109012/).
 
 However, it can be simplified by storing the desired and observed state of a 
 resource in the resource table itself (two columns in the form of a blob 
 storing a JSON). Please let me know your concerns or suggestions about this 
 approach.
 
 Thanks,
 Unmesh G.

It doesn't sounds like a good idea to me unless we have some plans to handle 
potential concurrency and compatibility issues.

Regards,
Qiming


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] Convergence - persistence desired and observed state

2014-09-17 Thread Qiming Teng
On Wed, Sep 17, 2014 at 12:27:34PM +, Gurjar, Unmesh wrote:
 Hi All,
 
 The convergence blueprint (https://review.openstack.org/#/c/95907/) 
 introduces two new database tables (resource_observed and 
 resource_properties_observed ) for storing the observed state of a resource 
 (currently under review: https://review.openstack.org/#/c/109012/).
 
 However, it can be simplified by storing the desired and observed state of a 
 resource in the resource table itself (two columns in the form of a blob 
 storing a JSON). Please let me know your concerns or suggestions about this 
 approach.
 
 Thanks,
 Unmesh G.

It doesn't sounds like a good idea to me unless we have some plans to
handle potential concurrency and compatibility issues.

Regards,
Qiming


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev