On Sat, Jan 17, 2015 at 5:01 AM, Georgy Okrokvertskhov < [email protected]> 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 <[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. >> >> >> >>> >>> Steve >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> Regards, >> Sergey. >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
