<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 4:02 PM, Ben Nemec <span dir="ltr"><<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 2014-03-10 12:24, Chris Friesen wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi,<br>
<br>
I'm using havana and recent we ran into an issue with heat related to<br>
character sets.<br>
<br>
In heat/db/sqlalchemy/api.py in user_creds_get() we call<br>
_decrypt() on an encrypted password stored in the database and then<br>
try to convert the result to unicode.  Today we hit a case where this<br>
errored out with the following message:<br>
<br>
UnicodeDecodeError: 'utf8' codec can't decode byte 0xf2 in position 0:<br>
invalid continuation byte<br>
<br>
We're using postgres and currently all the databases are using<br>
SQL_ASCII as the charset.<br>
<br>
I see that in icehouse heat will complain if you're using mysql and<br>
not using UTF-8.  There doesn't seem to be any checks for other<br>
databases though.<br>
<br>
It looks like devstack creates most databases as UTF-8 but uses latin1<br>
for nova/nova_bm/nova_cell.  I assume this is because nova expects to<br>
migrate the db to UTF-8 later.  Given that those migrations specify a<br>
character set only for mysql, when using postgres should we explicitly<br>
default to UTF-8 for everything?<br>
<br>
Thanks,<br>
Chris<br>
</blockquote>
<br></div>
We just had a discussion about this in #openstack-oslo too.  See the discussion starting at 2014-03-10T16:32:26 <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2014-03-10.log" target="_blank">http://eavesdrop.openstack.<u></u>org/irclogs/%23openstack-oslo/<u></u>%23openstack-oslo.2014-03-10.<u></u>log</a><br>

<br>
While it seems Heat does require utf8 (or at least matching character sets) across all tables, I'm not sure the current solution is good.  It seems like we may want a migration to help with this for anyone who might already have mismatched tables.  There's a lot of overlap between that discussion and how to handle Postgres with this, I think.<br>

<br>
I don't have a definite answer for any of this yet but I think it is something we need to figure out, so hopefully we can get some input from people who know more about the encoding requirements of the Heat and other projects' databases.<span class=""><font color="#888888"><br>

<br>
-Ben</font></span><div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">Based on the discussion from the project meeting today [1], the Glance team is going to write a migration to fix the database as the other projects have (we have not seen issues with corrupted data, so we believe this to be safe). However, there is one snag. In a follow-up conversation with Ben in #openstack-oslo, he pointed out that no migrations will run until the encoding is correct, so we do need to make some changes to the db code in oslo.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Here's what I think we need to do:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
1. In oslo, db_sync() needs a boolean to control whether _db_schema_sanity_check() is called. This is an all-or-nothing flag (not the "for some tables" implementation that was proposed).</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">2. Glance needs a migration to change the encoding of their tables.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
3. In glance-manage, the code that calls upgrade migrations needs to look at the current state and figure out if the requested state is before or after the migration created in step 2. If it is before, it passes False to disable the sanity check. If it is after, it passes True to enforce the sanity check.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Ben, did I miss any details?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
Doug</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[1] <a href="http://eavesdrop.openstack.org/meetings/project/2014/project.2014-03-18-21.03.log.txt">http://eavesdrop.openstack.org/meetings/project/2014/project.2014-03-18-21.03.log.txt</a></div>
<br></div></div>