Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

2016-04-14 Thread Praveen Yalagandula 
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-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

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

2016-04-14 Thread Zane Bitter 

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

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

2016-04-11 Thread Randall Burt 
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" 
 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  
> 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" 
>  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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

2016-04-11 Thread Praveen Yalagandula 
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 
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" <
> yprav...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

2016-04-11 Thread Randall Burt 
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:

> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] upgrade options for custom heat resource plug-ins

2016-04-11 Thread Praveen Yalagandula 
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev