<div dir="ltr">Zane,<div>Thanks for the reply; this is the information I was looking for.</div><div>Cheers,</div><div>Praveen</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 14, 2016 at 10:51 AM Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/04/16 14:06, Praveen Yalagandula wrote:<br>
> Hi,<br>
><br>
> We are developing a custom heat resource plug-in and wondering about how<br>
> to handle plug-in upgrades. As our product's object model changes with<br>
> new releases, we will need to release updated resource plug-in code too.<br>
<br>
So, in the first instance, I would recommend trying very hard not to do<br>
this. If you can, try to keep a stable interface even if the product<br>
changes underneath. (You can still add properties, as long as they are<br>
not required, but don't remove, rename, or otherwise make<br>
backward-incompatible changes to properties in the resource schema.)<br>
That said, I realise this is not always possible because of reasons.<br>
<br>
> However, the "properties" stored in the heat DB for the existing<br>
> resources, whose definitions have been upgraded, need to be updated too.<br>
> Was there any discussion on this?<br>
<br>
I believe this is what you need:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/translation.py" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/translation.py</a><br>
<br>
Documentation is unfortunately light on the ground, but you should be<br>
able to find a few examples in the core resources. Here is the spec:<br>
<br>
<a href="http://specs.openstack.org/openstack/heat-specs/specs/liberty/deprecating-improvements.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/heat-specs/specs/liberty/deprecating-improvements.html</a><br>
<br>
cheers,<br>
Zane.<br>
</blockquote></div>