<div dir="ltr">Hi,<div><br></div><div>Murano uses Heat templates with almost all available resources. Neutron resources are definitely used. </div><div>I think Murano can update our Heat resources handling properly, but there are at least two scenarios which should be considered:</div><div>1) Murano generated stacks are long lasting. Murano uses stack update to modify stacks so it is expected that stack update process is not affected by Heat upgrade and resource schema deprecation.</div><div>2) Murano uses application packages which contain HOT snippets. Application authors heavily rely on backward compatibility so that applications written on Icehouse version should work on later OpenStack versions. If it is not the case there should be some mechanism to automatically translate old resource schema to a new one. </div><div><br></div><div>I hope all the changes will be documented somewhere. I think it will be good to have a wiki page with a list of schema versions and changes. This will help Heat users to modify their templates accordingly.</div><div><br></div><div>Another potential issue I see is the fact that it is quite often when multiple versions of OpenStack are used in data centers. Like previous version in production and new versions of OpenStack are in stage and Dev environment which are used to prepare for production upgrade and current development. If these different versions of OpenStack will require different version of Heat templates it might be a problem as instead of upgrading just infrastructure services one will need to synchronously upgrade different external components which rely on Heat templates. </div><div><br></div><div>Thanks</div><div>Georgy</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 5:10 AM, 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><span class=""><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></span></div><br></div><div class="gmail_extra"><br><br clear="all"><div><div><div dir="ltr">Regards,<div>Sergey.</div></div></div></div><br></div></div>
<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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div></div>
</div>