heat stack-list failed: Unknown column 'stack.stack_user_project_id'

[guillaume thouvenin]

I build a fuel ISO in an Ubuntu 12.04.4. Then I installed an environments Icehouse on CentOS 6.5 (2014.1-5.1) in Multi-node with HA. The status reported is "Operational". Then I deployed one controller and one compute node.

When I run the command "heat stack-list" I have the following error:

# heat stack-list
ERROR: Remote error: OperationalError (OperationalError) (1054, "Unknown column 'stack.stack_user_project_id' in 'field list'") 'SELECT stack.status_reason AS stack_status_reason, stack.created_at AS stack_created_at, stack.deleted_at AS stack_deleted_at, stack.action AS stack_action, stack.status AS stack_status, stack.id AS stack_id, stack.name AS stack_name, stack.raw_template_id AS stack_raw_template_id, stack.username AS stack_username, stack.tenant AS stack_tenant, stack.parameters AS stack_parameters, stack.user_creds_id AS stack_user_creds_id, stack.owner_id AS stack_owner_id, stack.timeout AS stack_timeout, stack.disable_rollback AS stack_disable_rollback, stack.stack_user_project_id AS stack_stack_user_project_id, stack.updated_at AS stack_updated_at \nFROM stack \nWHERE stack.deleted_at IS NULL AND stack.owner_id IS NULL AND stack.tenant = %s ORDER BY stack.created_at DESC, stack.id DESC' ('75f0081b54144f7ba224f534bc424821',)

A quick search in puppet log shows that there is an error when synchronizing the heat DB:

Fri Jul 18 17:51:08 +0000 2014 /Stage[main]/Heat/Exec[heat-dbsync]/returns (notice): 2014-07-18 17:51:08.112 2649 INFO migrate.versioning.api [-] 31 -> 32...
Fri Jul 18 17:51:08 +0000 2014 /Stage[main]/Heat/Exec[heat-dbsync]/returns (notice): 2014-07-18 17:51:08.323 2649 INFO migrate.versioning.api [-] done
Fri Jul 18 17:51:08 +0000 2014 /Stage[main]/Heat/Exec[heat-dbsync]/returns (notice): 2014-07-18 17:51:08.324 2649 INFO migrate.versioning.api [-] 32 -> 33...
Fri Jul 18 17:51:08 +0000 2014 /Stage[main]/Heat/Exec[heat-dbsync]/returns (notice): ERROR: (OperationalError) (1071, 'Specified key was too long; max key length is 767 bytes') 'CREATE INDEX ix_software_config_tenant ON software_config (tenant)' ()
Fri Jul 18 17:51:08 +0000 2014 /Stage[main]/Heat/Exec[heat-dbsync] (err): Failed to call refresh: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0]
Fri Jul 18 17:51:08 +0000 2014 /Stage[main]/Heat/Exec[heat-dbsync] (err): heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0]

[Nastya Urlapova (aurlapova)]

Please, provide sha for all repos via http://MASTER_IP:8000/api/version and diagnostic snapshot.

[Bogdan Dobrelya (bogdando)]

Known issue of Heat and MySQL 5.6

[guillaume thouvenin (guillaume-thouvenin)]

@Nastya:

# curl http://10.20.0.2:8000/api/version
{"ostf_sha": "9863db951a6e159f4fa6e6861c8331e1af069cf8", "auth_required": false, "api": "1.0", "nailgun_sha": "c8846888812b542a7686c7eb47fd7da56e7087f0", "production": "docker", "fuelmain_sha": "d12f4ac69a6299130b360e788b098c1f304b28c3", "astute_sha": "18a6861ecf96e20ead17782ef4ea8d62e7449c14", "feature_groups": ["experimental"], "release": "5.1", "fuellib_sha": "b2caaea7b0a39f40ff08240da4dab81aaba6e29c"}

What do you mean by diagnostic snapshot?

@Bogdan

The strange things is that if I look the patch provided here https://review.openstack.org/#/c/92421/ it seems that it is already applied on my controller node. On the controller the version of mysql is:
  mysql Ver 14.14 Distrib 5.5.28, for Linux (x86_64) using readline 5.1

Even if it seems applied I still have the error. Can someone confirm that it is not a problem with my ISO by running "heat stack-list" from a controller under fuel 5.1?

[guillaume thouvenin (guillaume-thouvenin)]

My comments about the fix that seems applied was wrong sorry. I just checked on the controller and the file /usr/lib/python2.6/site-packages/heat/db/sqlalchemy/migrate_repo/versions/033_software_config.py is not patched:

        ....
        sqlalchemy.Column('tenant', sqlalchemy.String(256),
                          nullable=False,
                          index=True),
        .....

according to the fix, value should be 64 instead of 256. So according to https://bugs.launchpad.net/mos/+bug/1342072 the fix should be committed but it seems that it is not.