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 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-i
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,
There is a mechanism to mark them as support status "hidden" so that they don't
show up in resource-type-show and aren't allowed in new templates, but older
templates should still work. Eventually they may go away altogether but that
should be far in the future. For your custom resources, you ca
Randall,
Thanks for your reply.
I was wondering especially about those "deprecated" properties.. What
happens after several releases? Do you just remove them at that point? If
the expected maximum lifespan of a stack is shorter than the span for which
those "deprecated" properties are maintained,
Not really. Ideally, you need to write your resource such that these changes
are backwards compatible. We do this for the resources we ship with Heat (add
new properties while supporting deprecated properties for several releases).
On Apr 11, 2016, at 1:06 PM, "Praveen Yalagandula"
wrote:
> H
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.
However, the "properties" stored in the heat DB for the existing resources,
w
