[Openstack] upgrading heat from icehouse to juno

Steve Baker sbaker at redhat.com
Mon Oct 20 22:34:36 UTC 2014


On 20/10/14 16:04, Don Waterloo wrote:
> After doing this upgrade (with a good chunk of data in the database 
> that was created on icehouse), i'm running into a problem I'm 
> wondering if anyone else has seen.
>
> In particular, if i do a 'heat resource-list' on a stack that was 
> created with icehouse, i get an error, which is below.
>
> I'm not sure how to approach this, my assumption is there is some data 
> in my database which is not formatted correctly, but 'which' data is 
> the problem.
>
> I turned on mysql logging, and all the queries function, so it is 
> parsing something that comes back which is the problem. The below 
> trace makes me thing some column is null or '' in the old, and is 
> expected in the new.
>
> Any suggestions as to where to look next?
>
>   File "/usr/lib/python2.7/dist-packages/heat/engine/stack.py", line 
> 348, in __iter__
>     return iter(self.resources)
>   File "/usr/lib/python2.7/dist-packages/heat/engine/stack.py", line 
> 159, in resources
>     self.t.resource_definitions(self).items())
>   File "/usr/lib/python2.7/dist-packages/heat/engine/stack.py", line 
> 158, in <genexpr>
>     for (name, data) in
>   File "/usr/lib/python2.7/dist-packages/heat/engine/resource.py", 
> line 191, in __init__
>     resource = stack.db_resource_get(name)
>   File "/usr/lib/python2.7/dist-packages/heat/engine/stack.py", line 
> 190, in db_resource_get
>     self.context, self.id <http://self.id>)
>   File "/usr/lib/python2.7/dist-packages/heat/db/api.py", line 96, in 
> resource_get_all_by_stack
>     return IMPL.resource_get_all_by_stack(context, stack_id)
>   File "/usr/lib/python2.7/dist-packages/heat/db/sqlalchemy/api.py", 
> line 263, in resource_get_all_by_stack
>     options(orm.joinedload("data")).all()
>   File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", 
> line 2300, in all
>     return list(self)
>   File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/loading.py", 
> line 73, in instances
>     rows = [process[0](row, None) for row in fetch]
>   File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/loading.py", 
> line 455, in _instance
>     populate_state(state, dict_, row, isnew, only_load_props)
>   File "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/loading.py", 
> line 305, in populate_state
>     populator(state, dict_, row)
>   File 
> "/usr/lib/python2.7/dist-packages/sqlalchemy/orm/strategies.py", line 
> 169, in fetch_col
>     dict_[key] = row[col]
>   File "/usr/lib/python2.7/dist-packages/sqlalchemy/sql/type_api.py", 
> line 911, in process
>     return process_value(impl_processor(value), dialect)
>   File "/usr/lib/python2.7/dist-packages/heat/db/sqlalchemy/types.py", 
> line 37, in process_result_value
>     return loads(value)
>   File "/usr/lib/python2.7/json/__init__.py", line 338, in loads
>     return _default_decoder.decode(s)
>   File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
>     obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> TypeError: expected string or buffer
>
>

The most likely culprit is a Json column which was added in the Juno 
cycle. My guess would be resource.properties_data.

Could you run an update query to set existing null 
resource.properties_data values to '{}'?

I've raised the following bug to track this:
https://bugs.launchpad.net/heat/+bug/1383505

If your update query works could you comment on the bug? The backported 
code fix will either make the Json type tolerate None, or add a new 
migration script.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141021/f83c6881/attachment.html>


More information about the Openstack mailing list