<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Steve, Thanks for the feedback.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On 16 January 2015 at 15:09, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Thu, Dec 25, 2014 at 01:52:43PM +0400, Sergey Kraynev wrote:<br>
> Hi all.<br>
> In the last time we got on review several patches, which removes old<br>
</span>> deprecation properties [1],A<br>
<span class="">> and one mine [2].<br>
> The aim is to delete deprecated code and redundant tests. It looks simple,<br>
> but the main problem, which we met, is backward compatibility.<br>
> F.e. user has created resource (FIP) with old property schema, i.e. using<br>
> SUBNET_ID instead of SUBNET. On first look nothing bad will not happen,<br>
> because:<br>
<br>
</span>FWIW I think it's too soon to remove the Neutron subnet_id/network_id<br>
properties, they were only deprecated in Juno [1], and it's evident that<br>
users are still using them on icehouse [2]<br>
<br>
I thought the normal deprecation cycle was at least two releases, but I<br>
can't recall where I read that. Considering the overhead of maintaining<br>
these is small, I'd favour leaning towards giving more time for users to<br>
update their templates, rather then breaking them via very aggresive<br>
removal of deprecated interfaces.<br></blockquote><div><br></div><div>Honestly I thought, that we use 1 release cycle, but I have not any objections to do it after two releases.</div><div>Will be glad to know what is desired deprecation period.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'd suggest some or all of the following:<br>
<br>
- Add a "planned for removal in $release" to the SupportStatus string<br>
associated with the deprecation, so we can document the planned removal.<br>
- Wait for at least two releases between deprecation and removal, and<br>
announce the interfaces which will be removed in the release notes for<br>
the release before removal e.g:<br>
- Deprecated in Juno<br>
- Announce planned removal in Kilo release notes<br>
- Remove in "J"</blockquote><div><br></div><div>I like this idea, IMO it will make our deprecation process clear.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
[1] <a href="https://review.openstack.org/#/c/82853/" target="_blank">https://review.openstack.org/#/c/82853/</a><br>
[2] <a href="http://lists.openstack.org/pipermail/openstack/2015-January/011156.html" target="_blank">http://lists.openstack.org/pipermail/openstack/2015-January/011156.html</a><br>
<span class=""><br>
> 1. handle_delete use resource_id and any changes in property schema does<br>
> not affect other actions.<br>
> 2. If user want to use old template, he will get adequate error message,<br>
> that this property is not presented in schema. After that he just should<br>
> switch to new property and update stack using this new property.<br>
> In the same time we have one big issues for shadow dependencies, which is<br>
> actual for neutron resources. The simplest approach will not be worked<br>
> [3], due to old properties was deleted from property_schema.<br>
> Why is it bad ?<br>
> - we will get again all bugs related with such dependencies.<br>
</span>> - how to make sure:A<br>
> A A - create stack with old property (my template [4])<br>
> A A - open horizon, and look on topology<br>
> A A - download patch [2] and restart engine<br>
> A A - reload horizon page with topology<br>
> A A - as result it will be different<br>
> A<br>
<span class="">> I have some ideas about how to solve this, but none of them is not enough<br>
> good for me:<br>
</span>> A - getting such information from self.properties.data is bad, because we<br>
<span class="">> will skip all validations mentioned in properties.__getitem__<br>
</span>> A - renaming old key in data to new or creating copy with new key is not<br>
<span class="">> correct for me, because in this case we actually change properties<br>
> (resource representation) invisibly from user.<br>
</span>> A - as possible we may leave old deprecated property and mark it something<br>
<span class="">> like (removed), which will have similar behavior such as for<br>
> implemented=False. I do not like it, because it means, that we never<br>
> remove this "support code", because wants to be compatible with old<br>
> resources. (User may be not very lazy to do simple update or something<br>
> else ...)<br>
</span>> - last way, which I have not tried yet, is usingA _stored_properties_data<br>
> forA extraction necessary information.<br>
<span class="">> So now I have the questions:<br>
</span>> Should we support such case with backward compatibility?A<br>
<span class="">> If yes, how will be better to do it for us and user?<br>
</span>> May be we should create some strategy forA removingA A deprecated<br>
> properties ?<br>
<br>
Yeah, other than the process issues I mentioned above, Angus has pointed<br>
out some technical challenges which may mean property removal breaks<br>
existing stacks. IMHO this is something we *cannot* do - folks must be<br>
able to upgrade heat over multiple versions without breaking their stacks.<br>
<br>
As you say, delete may work, but it's likely several scenarios around<br>
update will break if the stored stack definition doesn't match the schema<br>
of the resource, and maintaining the internal references to removed or<br>
obsolete properties doesn't seem like a good plan long term.<br>
<br>
Could we provide some sort of migration tool, which re-writes the<br>
definition of existing stacks (via a special patch stack update maybe?)<br>
before upgrading heat?<br></blockquote><div><br></div><div>Yeah, I thought about it. Probably it's good solution for upgrading.</div><div>However one thing stops me to start doing it right now:</div><div>If we "upgrade" old resources and stored templates we will come </div><div>to situation, when user's template and stored are different.</div><div>And in this case user's template looks like invalid and can not be used</div><div>without updating wrong properties.</div><div>If we deal with it, I look forward to make this solution work.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Steve<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div><div class="gmail_extra"><br class=""><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Regards,<div>Sergey.</div></div></div></div><br></div></div>