Open Stack

On Sat, Jan 17, 2015 at 5:01 AM, Georgy Okrokvertskhov <
gokrokvertskhov at mirantis.com> wrote:

> Hi,
>
> Murano uses Heat templates with almost all available resources. Neutron
> resources are definitely used.
> I think Murano can update our Heat resources handling properly, but there
> are at least two scenarios which should be considered:
> 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.
> 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.
>
> 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.
>
> 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.
>

Thank Georgy,

We will tread carefully here. Once we add a property, I don't see how we
can ever totally remove support for it.

-Angus


>
> Thanks
> Georgy
>
>
> On Fri, Jan 16, 2015 at 5:10 AM, 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.
>>
>>
>>
>>>
>>> Steve
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>>
>>
>> Regards,
>> Sergey.
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
>
> --
> Georgy Okrokvertskhov
> Architect,
> OpenStack Platform Products,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150119/cc9169c6/attachment.html>