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 <skray...@mirantis.com> wrote: > > On 19 January 2015 at 05:13, Angus Salkeld <asalk...@mirantis.com> wrote: > >> On Fri, Jan 16, 2015 at 11:10 PM, Sergey Kraynev <skray...@mirantis.com> >> wrote: >> >>> Steve, Thanks for the feedback. >>> >>> On 16 January 2015 at 15:09, Steven Hardy <sha...@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-requ...@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. > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev