[openstack-dev] [heat] intrinsic function bugfixes and hot versioning

Zane Bitter zbitter at redhat.com
Wed Feb 17 23:43:17 UTC 2016

On 17/02/16 13:54, Steven Hardy wrote:
> Hi all,
> So, Zane and I have discussed $subject and it was suggested I take this to
> the list to reach consensus.
> Recently, I've run into a couple of small but inconvenient limitations in
> our intrinsic function implementations, specifically for str_replace and
> repeat, both of which did not behave the way I expected when referencing
> things via get_param/get_attr:
> https://bugs.launchpad.net/heat/+bug/1539737
> https://bugs.launchpad.net/heat/+bug/1546684

I think the second one is moot because I don't believe it's actually a 
bug. If it were a bug, as I said on IRC I think the presumption would be 
that we should merge it because:

1) it doesn't fail validation now, so if it were a bug then *any* fix 
would have some impact on backwards compatibility (either making this 
legal or validating it so that it's illegal), so it's better to make the 
Right fix; and
2) that function was added in Liberty, so we have a stable branch open 
for it. Eventually everyone should pick up the fix. The same is not true 
for intrinsic functions that have been around in template versions since 
before Liberty and especially before Kilo.

I'm less sure about the first bug, because neither of those apply.

> A patch fixing one has merged, another patch is under review.
> I'm viewing both issues as bugs in our existing implementation, but Zane's
> comment here https://review.openstack.org/#/c/275602/ prompted some
> discussion ref if we should bump the version of the functions (like we did
> recently for e.g json serialization via str_replace).
> I guess it's arguable, but in these cases, I'm thinking they are bugfixes,
> and not new features, but what do folks think, where do we draw the line
> with intrinsic functions in terms of what is considered a fix or a
> version-worthy change in behavior?

It's definitely arguable either way. There's no right answer, and it 
comes down to a trade-off between functionality and ecosystem 
portability. Thanks for starting this thread, it would be good to get 
some other folks to weigh in.

> The real disadvantage of requiring a version bump for bug fixes is that
> folks have to wait longer to consume the fixed version (because we can't
> backport a new HOT version).  The advantage is that there's less chance
> someone will write a template on a newly updated Heat install, then find it
> doesn't work on an older Heat environment (containing the bug) - is this
> any different to any other user-visible bug though?

Devil's advocate: is it any different to e.g. adding a new intrinsic 
function? The same advantages and disadvantages apply there too, but we 
decided to version the templates.


More information about the OpenStack-dev mailing list