| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-02 | |||
| 15:24:06 | jaypipes | not sure how I feel about all of dansmith's poking and tickling. | |
| 15:24:25 | dansmith | jaypipes: that's not what you said ... before. | |
| 15:24:51 | jaypipes | oh, dansmith. | |
| 15:25:00 | dansmith | jaypipes: <3 | |
| 15:29:33 | edleafe | get a room, you two | |
| 15:31:21 | mriedem | melwitt: your unicode decode error thing has taken off more since 5/1 http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22instance_update_at_top%5C%22%20AND%20message%3A%5C%22UnicodeDecodeError%5C%22%20AND%20tags%3A%5C%22screen-n-cell-region.txt%5C%22&from=7d | |
| 15:32:19 | melwitt | it's mine *eyes shimmering* | |
| 15:32:49 | mriedem | it looks like it blows up in the compute first http://logs.openstack.org/03/427903/7/check/gate-tempest-dsvm-cells-ubuntu-xenial/87da64a/logs/screen-n-cpu.txt.gz?level=TRACE | |
| 15:32:58 | mriedem | which puts the instance into error state | |
| 15:33:07 | mriedem | and that's causing some stuff to blow up at the top when logging the state change | |
| 15:33:20 | mriedem | File "/opt/stack/new/nova/nova/virt/libvirt/vif.py", line 961, in unplug | |
| 15:33:24 | mriedem | yup it's that same bug as before | |
| 15:33:50 | openstack | Launchpad bug 1580728 in OpenStack Compute (nova) "UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 386: ordinal not in range(128) in nova.virt.libvirt.vif:unplug with unicode instance.display_name" [Medium,Triaged] | |
| 15:33:50 | mriedem | https://bugs.launchpad.net/nova/+bug/1580728 | |
| 15:33:51 | melwitt | oh, the unplug vif you talked about | |
| 15:34:40 | mriedem | yeah, whatever is making that blow up in n-cpu and put the instance into error state, | |
| 15:34:50 | mriedem | also makes n-cell-region instance_update_at_top blow up | |
| 15:34:58 | mriedem | b/c we're logging the full instance | |
| 15:35:02 | mriedem | and something in there is unicode | |
| 15:35:20 | melwitt | the lp bug says the test uses a unicode display name for the instance | |
| 15:35:35 | melwitt | if that's still true then that would do it. I don't get why it doesn't always happen though | |
| 15:40:47 | mriedem | melwitt: yeah test_update_server_name_in_stop_state does create a server, stop it, then update the server name to unicode and then delete it | |
| 15:41:09 | melwitt | mriedem: sdague | |
| 15:41:11 | mriedem | i don't know why it wouldn't blow up everytime though | |
| 15:42:08 | mriedem | melwitt: also, when this fails http://logs.openstack.org/03/427903/7/check/gate-tempest-dsvm-cells-ubuntu-xenial/87da64a/console.html#_2017-05-02_08_22_13_375688 | |
| 15:42:24 | mriedem | it's while waiting for the server to be active, before the name is updated to be unicode | |
| 15:42:34 | melwitt | mriedem: sdague's comment on the lp bug mentions how devstack setting LC_ALL=C for grepping causes this, I wonder if there's some reason we couldn't use en_US.utf8 instead | |
| 15:43:45 | sdague | oh, that would totally explain why it's a gate only thing | |
| 15:43:58 | sdague | though, I thought the gate was C.utf8 | |
| 15:44:29 | Swanson | I see n-crt failing on my CI since yesterday. There something up with it? | |
| 15:44:43 | mriedem | Swanson: n-crt was deleted yesterday | |
| 15:44:53 | mriedem | Swanson: it's been deprecated since newton | |
| 15:45:02 | Swanson | mriedem, Whee! Easy fix. | |
| 15:45:20 | melwitt | sdague: looks like a mix in devstack? https://github.com/openstack-dev/devstack/search?utf8=%E2%9C%93&q=lc_all&type= | |
| 15:45:25 | Swanson | mriedem, Would explain my difficulty actually finding it. | |
| 15:46:02 | sdague | melwitt: yeh | |
| 15:46:26 | sdague | melwitt: if you want to propose change to en_US.utf8 everywhere, I'm good with that | |
| 15:46:37 | sdague | especially if it fixes this | |
| 15:48:10 | melwitt | sdague: yup, let's try that. C is ascii only so probably should be using utf8 anyhow. not 100% sure if it will fix this though | |
| 15:48:27 | sdague | yeh, I feel like I had that patch up before for other reasons | |
| 15:48:32 | sdague | but we never decided to land it | |
| 15:48:39 | sdague | but if it fixes this thing, win! | |
| 15:49:12 | melwitt | ++ | |
| 15:52:11 | mriedem | seems we should still not be logging something that's going to blow up here yeah? | |
| 15:54:50 | melwitt | mriedem: I'm not sure. I had been thinking the failure is environment specific, i.e. if the environment doesn't support utf8 | |
| 15:55:35 | mriedem | melwitt: we put lots of things in six.text_type though for the same reason | |
| 15:55:41 | mriedem | regardless of env | |
| 15:55:42 | melwitt | but I'm still not clear on why it doesn't happen all the time and what we could do the prevent it blowing up in a non utf8 env? | |
| 15:55:51 | melwitt | oh | |
| 15:57:33 | sdague | mriedem: it's one of those things that is more fundamental | |
| 15:57:56 | sdague | I feel like I went through a weird set of poking on this the last time | |
| 15:57:58 | mriedem | The String field in ovo has a stringify method which is used for __repr__, seems that should always be doing six.text_type | |
| 15:58:03 | melwitt | so six.text_type returns a unicode string. if the env doesn't support unicode, then how does it help? | |
| 15:58:10 | sdague | right, like melwitt said | |
| 15:58:33 | sdague | stuff gets super borky when you are in a non utf8 env | |
| 15:58:42 | melwitt | it seems like it would just do the same thing, but I dunno | |
| 15:58:48 | clarkb | C.utf8 is the locale I think people should be using based on what is built into libcs | |
| 15:59:20 | sdague | clarkb: well, that has a different issue in that "nobody" uses that except the dib images for infra | |
| 15:59:47 | clarkb | sdague: because its relatively new but aiui its what things are switching to? | |
| 15:59:56 | sdague | clarkb: are they? | |
| 16:00:01 | clarkb | ya fedora was aiui | |
| 16:00:10 | sdague | ubuntu? | |
| 16:00:10 | clarkb | which should mean the rest of the red hat world is too? | |
| 16:00:17 | mriedem | melwitt: maybe you're right, since it looks like the base __repr__ in ovo does encode it if on py27 https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L318 | |
| 16:00:26 | clarkb | ubuntu already had it but being desktop first I'm not sure if they will hcnage the default | |
| 16:00:42 | sdague | anyway, lets see if the old tried and true en_US.utf8 works | |
| 16:00:46 | clarkb | the idea behind C.utf8 is have the "sanity" of C (sorting etc) while supporting utf8 too | |
| 16:02:22 | melwitt | fwiw I get the error when I try the same example C.utf8 $ LC_ALL=C.utf8 python -c "a = u'\u00CD\u00F1st\u00E1\u00F1c\u00E9'; print a" | |
| 16:04:12 | clarkb | melwitt: what error? (that works for me locally) | |
| 16:04:35 | clarkb | I get "Íñstáñcé" | |
| 16:04:39 | jaypipes | cdent: yay, your request for additional functional tests identified an issue with the WHERE condition on shared providers... the difference of where a single parentheses is makes a world of difference :) | |
| 16:04:54 | melwitt | clarkb: hm, interesting. the error from the bug "UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)" | |
| 16:05:35 | clarkb | melwitt: and if you change it to print a.encode('utf8') I assume that works? | |
| 16:06:24 | clarkb | does locale -a show C.utf8 as being present locally? | |
| 16:06:25 | mriedem | clarkb: it does | |
| 16:06:41 | melwitt | clarkb: yeah, with the encode it works. I wonder if it depends on which version of python? | |
| 16:06:52 | mriedem | melwitt: apparently it does https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L318 | |
| 16:07:03 | mriedem | the problem is in ^ we do the %s replace before trying to encode it | |
| 16:07:07 | mriedem | and we blow up already | |
| 16:07:11 | stvnoyes | johnthetubaguy: Hi john, I updated one of the multiattach reviews to address your comments- https://review.openstack.org/#/c/456877/ pls take a look when you get a chance. also related review here - https://review.openstack.org/#/c/456851/ thx | |
| 16:07:26 | clarkb | mriedem: melwitt I think it either depends on locale locales (see locale -a) or the build of python and how it detects the locale? | |
| 16:07:35 | clarkb | I have python 2.7.13 | |
| 16:08:04 | melwitt | okay, I have C.utf8 in locale -a | |
| 16:08:16 | melwitt | er, C.UTF-8 | |
| 16:08:36 | melwitt | so it works when I use that | |
| 16:08:51 | melwitt | with the caps and the hyphen | |
| 16:12:24 | sfinucan | melwitt: You tried 'PYTHONIOENCODING=UTF-8 python ...'? | |
| 16:13:12 | melwitt | sfinucan: no, just setting LC_ALL=C.UTF-8 etc | |
| 16:14:18 | sfinucan | melwitt: I think that should fix the issue. Someone reported a similar things for pwclient (part of Patchwork) a while back https://lists.ozlabs.org/pipermail/patchwork/2017-April/004214.html | |
| 16:14:52 | sfinucan | the other "workarounds" are hacky as can be. Better just set the envvar | |
| 16:18:31 | sdague | clarkb: there is no C.UTF-8 on base centos 7 | |
| 16:19:14 | melwitt | sdague, clarkb: trying C.UTF-8 https://review.openstack.org/#/c/461840 | |
| 16:19:29 | melwitt | sdague: but what you just said means it's not going to work for centos 7 | |
| 16:19:57 | sdague | melwitt: yeh, lets just use en_US.utf8, we know that works | |
| 16:19:58 | clarkb | sdague: is ther C.utf8? | |
| 16:20:02 | melwitt | sdague: k | |
| 16:20:03 | sdague | clarkb: nope | |
| 16:20:05 | clarkb | sdague: thats what it is for me on suse at least | |
| 16:20:15 | sdague | C | |
| 16:20:15 | sdague | [sdague@centos7 ~]$ locale -a | grep '^C' | |