Open Stack

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 <zbitter at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160414/bdb104c8/attachment.html>