Re: [openstack-dev] [Heat] Upwards-compatibility for HOT
On 8 July 2014 01:25, Zane Bitter zbit...@redhat.com wrote: With the Icehouse release we announced that there would be no further backwards-incompatible changes to HOT without a revision bump. However, I notice that we've already made an upward-incompatible change in Juno: https://review.openstack.org/#/c/102718/ So a user will be able to create a valid template for a Juno (or later) version of Heat with the version heat_template_version: 2013-05-23 but the same template may break on an Icehouse installation of Heat with the stable HOT parser. IMO this is almost equally as bad as breaking backwards compatibility, since a user moving between clouds will generally have no idea whether they are going forward or backward in version terms. (Note: AWS don't use the version field this way, because there is only one AWS and therefore in theory they don't have this problem. This implies that we might need a more sophisticated versioning system.) I'd like to propose a policy that we bump the revision of HOT whenever we make a change from the previous stable version, and that we declare the new version stable at the end of each release cycle. Maybe we can post-date it to indicate the policy more clearly. (I'd also like to propose that the Juno version drops cfn-style function support.) +1 for idea creating new version for each release cycle. I think it will help to modify format and additional features easier without backward compatibility problems. +1 for rejecting cfn functions in HOT. Sometimes it leads to confusing situation (F.e. when user try to use Fn::GetAtt instead of get_attr in HOT, where we have not such function). ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Upwards-compatibility for HOT
On 07/07/14 20:02, Steve Baker wrote: On 08/07/14 09:25, Zane Bitter wrote: With the Icehouse release we announced that there would be no further backwards-incompatible changes to HOT without a revision bump. However, I notice that we've already made an upward-incompatible change in Juno: https://review.openstack.org/#/c/102718/ So a user will be able to create a valid template for a Juno (or later) version of Heat with the version heat_template_version: 2013-05-23 but the same template may break on an Icehouse installation of Heat with the stable HOT parser. IMO this is almost equally as bad as breaking backwards compatibility, since a user moving between clouds will generally have no idea whether they are going forward or backward in version terms. (Note: AWS don't use the version field this way, because there is only one AWS and therefore in theory they don't have this problem. This implies that we might need a more sophisticated versioning system.) I'd like to propose a policy that we bump the revision of HOT whenever we make a change from the previous stable version, and that we declare the new version stable at the end of each release cycle. Maybe we can post-date it to indicate the policy more clearly. (I'd also like to propose that the Juno version drops cfn-style function support.) +1 on setting the juno release date as the latest heat_template_version, and putting list_join in that. It seems reasonable to remove cfn-style functions from latest heat_template_version as long as they are still registered in 2013-05-23 I'm hearing consensus on this general approach, so I put up an implementation for further comment: https://review.openstack.org/105558 cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Upwards-compatibility for HOT
Excerpts from Zane Bitter's message of 2014-07-07 14:25:50 -0700: With the Icehouse release we announced that there would be no further backwards-incompatible changes to HOT without a revision bump. However, I notice that we've already made an upward-incompatible change in Juno: https://review.openstack.org/#/c/102718/ So a user will be able to create a valid template for a Juno (or later) version of Heat with the version heat_template_version: 2013-05-23 but the same template may break on an Icehouse installation of Heat with the stable HOT parser. IMO this is almost equally as bad as breaking backwards compatibility, since a user moving between clouds will generally have no idea whether they are going forward or backward in version terms. Sounds like a bug in Juno that we need to fix. I agree, this is a new template version. (Note: AWS don't use the version field this way, because there is only one AWS and therefore in theory they don't have this problem. This implies that we might need a more sophisticated versioning system.) A good manual with a this was introduced in version X and this was changed in version Y would, IMO be enough, to help users not go crazy and help us know whether something is a bug or not. We can probably achieve this entirely in the in-code template guide. I'd like to propose a policy that we bump the revision of HOT whenever we make a change from the previous stable version, and that we declare the new version stable at the end of each release cycle. Maybe we can post-date it to indicate the policy more clearly. (I'd also like to propose that the Juno version drops cfn-style function support.) Agreed. I'm also curious if we're going to reject a template with version 2013-05-23 that includes list_join. If we don't reject it, we probably need to look at how to show the user warnings about version/feature skew. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Upwards-compatibility for HOT
On 07/07/14 18:13, Clint Byrum wrote: Excerpts from Zane Bitter's message of 2014-07-07 14:25:50 -0700: I'd like to propose a policy that we bump the revision of HOT whenever we make a change from the previous stable version, and that we declare the new version stable at the end of each release cycle. Maybe we can post-date it to indicate the policy more clearly. (I'd also like to propose that the Juno version drops cfn-style function support.) Agreed. I'm also curious if we're going to reject a template with version 2013-05-23 that includes list_join. If we don't reject it, we probably need to look at how to show the user warnings about version/feature skew. To be clear, my proposal is that we would reject it. - ZB ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Upwards-compatibility for HOT
On 08/07/14 09:25, Zane Bitter wrote: With the Icehouse release we announced that there would be no further backwards-incompatible changes to HOT without a revision bump. However, I notice that we've already made an upward-incompatible change in Juno: https://review.openstack.org/#/c/102718/ So a user will be able to create a valid template for a Juno (or later) version of Heat with the version heat_template_version: 2013-05-23 but the same template may break on an Icehouse installation of Heat with the stable HOT parser. IMO this is almost equally as bad as breaking backwards compatibility, since a user moving between clouds will generally have no idea whether they are going forward or backward in version terms. (Note: AWS don't use the version field this way, because there is only one AWS and therefore in theory they don't have this problem. This implies that we might need a more sophisticated versioning system.) I'd like to propose a policy that we bump the revision of HOT whenever we make a change from the previous stable version, and that we declare the new version stable at the end of each release cycle. Maybe we can post-date it to indicate the policy more clearly. (I'd also like to propose that the Juno version drops cfn-style function support.) +1 on setting the juno release date as the latest heat_template_version, and putting list_join in that. It seems reasonable to remove cfn-style functions from latest heat_template_version as long as they are still registered in 2013-05-23 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Upwards-compatibility for HOT
On 08/07/14 10:13, Clint Byrum wrote: Excerpts from Zane Bitter's message of 2014-07-07 14:25:50 -0700: With the Icehouse release we announced that there would be no further backwards-incompatible changes to HOT without a revision bump. However, I notice that we've already made an upward-incompatible change in Juno: https://review.openstack.org/#/c/102718/ So a user will be able to create a valid template for a Juno (or later) version of Heat with the version heat_template_version: 2013-05-23 but the same template may break on an Icehouse installation of Heat with the stable HOT parser. IMO this is almost equally as bad as breaking backwards compatibility, since a user moving between clouds will generally have no idea whether they are going forward or backward in version terms. Sounds like a bug in Juno that we need to fix. I agree, this is a new template version. (Note: AWS don't use the version field this way, because there is only one AWS and therefore in theory they don't have this problem. This implies that we might need a more sophisticated versioning system.) A good manual with a this was introduced in version X and this was changed in version Y would, IMO be enough, to help users not go crazy and help us know whether something is a bug or not. We can probably achieve this entirely in the in-code template guide. Intrinsic functions are manually documented, but it would be great to be able to generate this for resource types, properties and attributes. The SupportStatus structures are all there, it just takes someone to go through the release history and populate them. Users often trip over attempting to use a documented new thing on an older heat release. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
