<div dir="ltr">Short summarize of discussion in email thread and IRC:<div><br></div><div><div>1. We plan to add follow information for property/attribute in release notes.<br></div><div><div> - Deprecated in Juno</div><div> - Announce planned removal in Kilo release notes</div><div> - Remove in "J" (I.e. we will return validation error on all templates with this property)</div></div><div><br></div><div>2. Some improvements for Deprecation status code:</div><div> - Add separate parameter "Deprecated_Since" (optionally may be added two mentioned above - planned_removal, remove)</div><div><br></div><div>3. Add option in attr/prop schema: </div></div><div><div>property_schema = {</div><div> subnet:</div><div> ....</div><div> old_names (or something like that) = subnet_id</div><div>}</div></div><div><br></div><div>4. Add migration mechanism: </div><div>When user use "old" template, property automatically translated to the new name.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Regards,<div>Sergey.</div></div></div></div>
<br><div class="gmail_quote">On 19 January 2015 at 14:51, 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"><br><div class="gmail_quote"><div><div class="h5">On 19 January 2015 at 05:13, Angus Salkeld <span dir="ltr"><<a href="mailto:asalkeld@mirantis.com" target="_blank">asalkeld@mirantis.com</a>></span> wrote:<br></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"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>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><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><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></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.<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>-Angus<br></div><div> </div></font></span></div></div></div>
<br></div></div><span class="">__________________________________________________________________________<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>
<br></span></blockquote></div><br></div><div class="gmail_extra">Angus, I think, that it should be possibly.</div><div class="gmail_extra">Also your suggestion gave me a idea. We can roll up all old/deprecated properties.</div><div class="gmail_extra">F.e. add option: </div><div class="gmail_extra"><br></div><div class="gmail_extra">property_schema = {</div><div class="gmail_extra"> subnet:</div><div class="gmail_extra"> ....</div><div class="gmail_extra"> old_names (or something like that) = subnet_id</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div><div class="gmail_extra">So during creation we will define two properties in template with the same values.</div><div class="gmail_extra">IMO, it should work well, because all deprecated properties now is just renamed properties.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Also, as you suggested above, we may migrate this "deprecation key" and say user, that he should change his template.</div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">Regards,<div>Sergey.</div><div><br></div></div></div></div></div></div>
</blockquote></div><br></div>