On Fri, Jan 16, 2015 at 11:10 PM, Sergey Kraynev <[email protected]> wrote:
> Steve, Thanks for the feedback. > > On 16 January 2015 at 15:09, Steven Hardy <[email protected]> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
