"Data too long for column 'resource_properties' at row 1"

Bug #1493858 reported by Marios Andreou
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Heat
Fix Released
High
Steven Hardy
Kilo
Fix Released
Undecided
Unassigned

Bug Description

in tripleo we have a template which is a puppet manifest like [1] (delivered as a SoftwareConfig). Recently this file has grown beyond 65535 chars, resulting in

 DEBUG oslo_db.sqlalchemy.session [req-a797cf52-99e4-4a85-8af0-db44167ead0b - -] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/session.py:513\n2015-09-08 21:09:39.788 32609 ERROR oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from queue: \n2015-09-08 21:09:40.778 2133 DEBUG oslo_db.sqlalchemy.session [req-1a71f3cf-993a-45b2-89db-96bf22664aca - -] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/session.py:513\n2015-09-08 22:00:37.468 2133 ERROR oslo_db.sqlalchemy.exc_filters [-] DBAPIError exception wrapped from (_mysql_exceptions.DataError) (1406, \"Data too long for column 'resource_properties' at row 1\") [SQL: u'INSERT INTO event (created_at, updated_at, stack_id, uuid, resource_action, resource_status, resource_name, physical_resource_id, resource_status_reason, resource_type, resource_properties) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)'] [parameters: (datetime.datetime(2015, 9, 9, 2, 0, 37, 466247), None, '8526154b-6ca6-424a-af5a-c91429707932', '17be30fd-e595-4dfa-9f3d-7bf2ada982c5', 'CREATE', 'IN_PROGRESS', 'ControllerPuppetConfigImpl', None, 'state changed', 'OS::Heat::SoftwareConfig', '\\x80\\x02}q\\x01(U\\x06inputsq\\x02NU\\x06configq\\x03X\\x17\\x05\\x01\\x00# Copyright 2015 Red Hat, Inc.\\n# All Rights Reserved.\\n#\\n#

(the rest of the trace is the continuation of [1] in its entirety)

It seems heat is trying to store all of that as the resource_properties of an event like at [3]. Looking a bit closer, this column is type PickleType [4][5]. I am not sure what we can do about this type? Any ideas?

thanks

[1] https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/manifests/overcloud_controller_pacemaker.pp
[2] https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/controller-config-pacemaker.yaml
[3] https://github.com/openstack/heat/blob/e4264917fa2f457c159415e5ea8e29411c5812a7/heat/engine/event.py#L42
[4] https://github.com/openstack/heat/blob/master/heat/db/sqlalchemy/models.py#L242
[5] http://docs.sqlalchemy.org/en/latest/core/type_basics.html?highlight=pickletype#sqlalchemy.types.PickleType

Revision history for this message
Zane Bitter (zaneb) wrote :

I can't think of a good fix that wouldn't require a DB migration, other than to just retry without including the property values if we encounter this failure.

Changed in heat:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Zane Bitter (zaneb)
milestone: none → liberty-rc1
Revision history for this message
Steven Hardy (shardy) wrote :

If it's just the column in the event table (as opposed to the resource record itself), can we just truncate the event data?

Revision history for this message
Steven Hardy (shardy) wrote :

To clarify my comment, we could do one of:

1. Copy the resource_properties for the event, check the size and drop the largest values if the total size exceeds the column limit, obviously noting in the event resource_properties it was omitted due to size constraints.

2. Add an item to the properties schema which allows you to define "no log" for a property, e.g because we know it's going to be large and easily obtained via other means - in this case explicitly tagging the SoftwareConfig config property as "don't log" wouldn't affect debuggability much, because the operator has the files they fed in to heat (or, even better, we could expose an interface like template-show which dumps the files for the stack) - I don't think we really gain much by committing duplicate data to the DB for every.single.event related to every deployment?

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to heat (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/222171

Revision history for this message
Marios Andreou (marios-b) wrote :

band aid @ https://review.openstack.org/#/c/222171/ along the lines of 1. @ shardy comments, mainly for testing and discussion

thanks!

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to heat (master)

Fix proposed to branch: master
Review: https://review.openstack.org/222352

Changed in heat:
status: Triaged → In Progress
Changed in heat:
assignee: Zane Bitter (zaneb) → Steven Hardy (shardy)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on heat (master)

Change abandoned by Zane Bitter (<email address hidden>) on branch: master
Review: https://review.openstack.org/222171
Reason: Let's abandon this in favour of I668c7ed8ca6c063fd20bc5271d6afea941a5f277 since there seems to be broad agreement in favour of Steve's approach there. Thanks Marios for getting the discussion underway!

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to heat (master)

Reviewed: https://review.openstack.org/222352
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=ab78bde75bb6aae2025815abd4613d8dabbbd4df
Submitter: Jenkins
Branch: master

commit ab78bde75bb6aae2025815abd4613d8dabbbd4df
Author: Zane Bitter <email address hidden>
Date: Thu Sep 10 10:58:52 2015 -0400

    Work around problems storing huge properties in events

    There is a maximum limit on the size of the resource properties we can
    store for an event in MySQL.

    To work around this, store an error instead of the largest property,
    as this is expected to cater for graceful-failure of the most common
    known case (large SoftwareConfig config properties), with a fallback
    of storing only the error when this also fails.

    Co-Authored-By: Steven Hardy <email address hidden>
    Co-Authored-By: Marios Andreou <email address hidden>
    Closes-Bug: #1493858
    Change-Id: I668c7ed8ca6c063fd20bc5271d6afea941a5f277

Changed in heat:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to heat (stable/kilo)

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/224251

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to heat (stable/kilo)

Reviewed: https://review.openstack.org/224251
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=edd2f8f0aca14f225e441dd3efbfa1cce7a859b4
Submitter: Jenkins
Branch: stable/kilo

commit edd2f8f0aca14f225e441dd3efbfa1cce7a859b4
Author: Zane Bitter <email address hidden>
Date: Thu Sep 10 10:58:52 2015 -0400

    Work around problems storing huge properties in events

    There is a maximum limit on the size of the resource properties we can
    store for an event in MySQL.

    To work around this, store an error instead of the largest property,
    as this is expected to cater for graceful-failure of the most common
    known case (large SoftwareConfig config properties), with a fallback
    of storing only the error when this also fails.

    Co-Authored-By: Steven Hardy <email address hidden>
    Co-Authored-By: Marios Andreou <email address hidden>
    Closes-Bug: #1493858
    Change-Id: I668c7ed8ca6c063fd20bc5271d6afea941a5f277
    (cherry picked from commit ab78bde75bb6aae2025815abd4613d8dabbbd4df)

tags: added: in-stable-kilo
Thierry Carrez (ttx)
Changed in heat:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in heat:
milestone: liberty-rc1 → 5.0.0
Revision history for this message
Rakesh H S (rh-s) wrote :

This bug is handled in heat as mentioned above, but oslo_db.sqlalchemy will still log the ERROR message in heat logs and causes confusion when debugging a large stack.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to heat (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/381667

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to heat (master)

Reviewed: https://review.openstack.org/381667
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=1e92462ae6d61ccacda7a1ce8e2621c9cf9ffde7
Submitter: Jenkins
Branch: master

commit 1e92462ae6d61ccacda7a1ce8e2621c9cf9ffde7
Author: Thomas Herve <email address hidden>
Date: Tue Oct 4 13:18:11 2016 +0200

    Properly compute resource_properties pickle

    When you check for resource_properties size when storing event, we use
    the regular pickle module with the default protocol. Sqlalchemy uses
    cPickle if available, with the highest protocol, which can result in
    fairly different storing size. Use that instead, this should remove the
    last occurence of the storage bug.

    Change-Id: Ia417e221f7097a388a6b36959064b12cb818206f
    Related-Bug: #1493858

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to heat (stable/newton)

Related fix proposed to branch: stable/newton
Review: https://review.openstack.org/443168

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to heat (stable/newton)

Reviewed: https://review.openstack.org/443168
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=33c5eee23146584cf5ca67d57727a272625fba00
Submitter: Jenkins
Branch: stable/newton

commit 33c5eee23146584cf5ca67d57727a272625fba00
Author: Thomas Herve <email address hidden>
Date: Tue Oct 4 13:18:11 2016 +0200

    Properly compute resource_properties pickle

    When you check for resource_properties size when storing event, we use
    the regular pickle module with the default protocol. Sqlalchemy uses
    cPickle if available, with the highest protocol, which can result in
    fairly different storing size. Use that instead, this should remove the
    last occurence of the storage bug.

    Change-Id: Ia417e221f7097a388a6b36959064b12cb818206f
    Related-Bug: #1493858
    (cherry picked from commit 1e92462ae6d61ccacda7a1ce8e2621c9cf9ffde7)

tags: added: in-stable-newton
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.