Open Stack

Short summarize of discussion in email thread and IRC:

1. We plan to add follow information for property/attribute in release
notes.
    - Deprecated in Juno
    - Announce planned removal in Kilo release notes
    - Remove in "J"  (I.e. we will return validation error on all templates
with this property)

2. Some improvements for Deprecation status code:
 - Add separate parameter "Deprecated_Since" (optionally may be added two
mentioned above - planned_removal, remove)

3. Add option in attr/prop schema:
property_schema = {
    subnet:
      ....
      old_names (or something like that) = subnet_id
}

4. Add migration mechanism:
When user use "old" template, property automatically translated to the new
name.

Regards,
Sergey.

On 19 January 2015 at 14:51, Sergey Kraynev <skraynev at mirantis.com> wrote:

>
> On 19 January 2015 at 05:13, Angus Salkeld <asalkeld at mirantis.com> wrote:
>
>> 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
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> Angus, I think, that it should be possibly.
> Also your suggestion gave me a idea. We can roll up all old/deprecated
> properties.
> F.e. add option:
>
> property_schema = {
>     subnet:
>       ....
>       old_names (or something like that) = subnet_id
> }
>
> So during creation we will define two properties in template with the same
> values.
> IMO, it should work well, because all deprecated properties now is just
> renamed properties.
>
> Also, as you suggested above, we may migrate this "deprecation key" and
> say user, that he should change his template.
>
> Regards,
> Sergey.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150126/624a9064/attachment.html>