<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 16, 2015 at 11:10 PM, Sergey Kraynev <span dir="ltr"><<a href="mailto:skraynev@mirantis.com" target="_blank">skraynev@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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"><span class="">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>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>>    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></span><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><span class=""><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></span><div>I like this idea, IMO it will make our deprecation process clear.</div><div><div class="h5"><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><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>>    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>>    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>>    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>>    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>>    So now I have the questions:<br>
</span>>    Should we support such case with backward compatibility?A<br>
<span>>    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></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></div></div></blockquote><div><br></div><div>Can't we change the property definition to be a migration function?<br></div><div>- It would not be visible to users (once deprecated)<br></div>- On loading the template, it would run the migration function that could<br><div>  do a migration.<br><br></div><div>The question is it even possible to achieve technically? But it would be nice in<br>that we could stay compatible for ever.<br><br></div><div>-Angus<br></div><div> </div></div></div></div>