Zane, Thanks for the reply; this is the information I was looking for. Cheers, Praveen
On Thu, Apr 14, 2016 at 10:51 AM Zane Bitter <zbit...@redhat.com> wrote: > On 11/04/16 14:06, Praveen Yalagandula wrote: > > Hi, > > > > We are developing a custom heat resource plug-in and wondering about how > > to handle plug-in upgrades. As our product's object model changes with > > new releases, we will need to release updated resource plug-in code too. > > So, in the first instance, I would recommend trying very hard not to do > this. If you can, try to keep a stable interface even if the product > changes underneath. (You can still add properties, as long as they are > not required, but don't remove, rename, or otherwise make > backward-incompatible changes to properties in the resource schema.) > That said, I realise this is not always possible because of reasons. > > > However, the "properties" stored in the heat DB for the existing > > resources, whose definitions have been upgraded, need to be updated too. > > Was there any discussion on this? > > I believe this is what you need: > > > http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/translation.py > > Documentation is unfortunately light on the ground, but you should be > able to find a few examples in the core resources. Here is the spec: > > > http://specs.openstack.org/openstack/heat-specs/specs/liberty/deprecating-improvements.html > > cheers, > Zane. >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
