Open Stack

On Fri, Jan 16, 2015 at 11:10 PM, Sergey Kraynev <skraynev at mirantis.com>
wrote:

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

Can't we change the property definition to be a migration function?
- It would not be visible to users (once deprecated)
- On loading the template, it would run the migration function that could
  do a migration.

The question is it even possible to achieve technically? But it would be
nice in
that we could stay compatible for ever.

-Angus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150119/b7570266/attachment.html>