Open Stack

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 can decide when or if to ever remove them.

On Apr 11, 2016, at 3:58 PM, "Praveen Yalagandula" <ypraveen at avinetworks.com>
 wrote:

> 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, then removing them works. But what happens if it is longer?
> 
> Cheers,
> Praveen
> 
> On Mon, Apr 11, 2016 at 12:02 PM Randall Burt <randall.burt at rackspace.com> wrote:
> 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" <ypraveen at avinetworks.com>
>  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. 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?
> >
> > Thanks,
> > Praveen Yalagandula
> > Avi Networks
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev