| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-16 | |||
| 12:16:58 | efried | what gives an error? data.write or _imagedata.get? | |
| 12:17:07 | efried | presumably the former | |
| 12:17:10 | mdbooth | Yeah | |
| 12:17:40 | efried | and where does the error show up? It must not be in the py35 tox job...? | |
| 12:18:02 | mdbooth | Yeah, it was happening in the functional job | |
| 12:18:18 | efried | oooohhhh | |
| 12:18:29 | mdbooth | Although it was non-deterministic until I twigged why | |
| 12:18:29 | efried | I was blinded by the fact that the fake driver lives in the /unit/ path. | |
| 12:18:34 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Make monkey patch work in uWSGI mode https://review.openstack.org/592285 | |
| 12:18:38 | efried | but it's used for the func tests too. | |
| 12:18:45 | mdbooth | They're pretty incestuous :) | |
| 12:18:54 | efried | okay, now that I have a way to try to repro locally I can take a better look at it. | |
| 12:19:17 | efried | If you wouldn't mind enhancing the commit message, future me will be grateful. | |
| 12:19:36 | mdbooth | Maybe if you open the file binary it has to have binary data written to it? | |
| 12:19:59 | efried | Well, it makes sense that you would *want* to write binary if you're opening with 'b'. | |
| 12:20:24 | mdbooth | >>> f = open('/tmp/foo', 'wb+') | |
| 12:20:24 | mdbooth | >>> f.write('foo') | |
| 12:20:24 | mdbooth | Traceback (most recent call last): | |
| 12:20:24 | mdbooth | File "<stdin>", line 1, in <module> | |
| 12:20:24 | mdbooth | TypeError: a bytes-like object is required, not 'str' | |
| 12:20:32 | mdbooth | That's the error you get, anyway | |
| 12:20:53 | mdbooth | >>> f.write(b'foo') | |
| 12:20:53 | mdbooth | 3 | |
| 12:21:04 | efried | yeah, so they must have tightened that down in py3, eh? | |
| 12:21:24 | mdbooth | py2: | |
| 12:21:30 | mdbooth | >>> f = open('/tmp/foo', 'wb+') | |
| 12:21:30 | mdbooth | >>> f.write('foo') | |
| 12:21:30 | mdbooth | >>> f.write(b'foo') | |
| 12:21:32 | mdbooth | Both work | |
| 12:21:55 | efried | which func test would fail? | |
| 12:22:19 | efried | I try not to run full suites locally unless I need to reheat my coffee. | |
| 12:22:50 | mdbooth | So... the following functional test would fail non-deterministically depending on whether or not fake image service gave it an image with a kernel and ramdisk or not | |
| 12:23:38 | efried | We have a test that sometimes uses one kind of image and sometimes another, nondeterministically?? | |
| 12:23:52 | mdbooth | efried: Yep. A few :) | |
| 12:24:16 | efried | that's... I can't... but WHY? | |
| 12:24:25 | mdbooth | I felt really good about myself for find that this morning :) | |
| 12:24:50 | mdbooth | efried: non-deterministic dict ordering | |
| 12:25:40 | efried | ...because the reward for good work is... | |
| 12:26:59 | mdbooth | efried: It's not relevant to my bug, or I would have. I was just tripping over it. | |
| 12:27:19 | efried | I was about to say: assume the topic bug isn't really related, so this should be tagged with the py3-first tag (whatever that tag is) | |
| 12:28:50 | efried | btw, I recently discovered with cdent's guidance that you can avoid gerrit re-topic'ing your whole series by using git-review -T (available only in recent versions of git-review) | |
| 12:29:07 | mdbooth | I mean the non-deterministic images, that is. My patch just needs a functioning image service in order to boot. kernel vs non-kernel is irrelevant, except that it caused a bug. | |
| 12:29:39 | mdbooth | I don't really use topics, tbh | |
| 12:30:32 | mdbooth | I've always found it more useful to use the fact that gerrit displays a series in dependency order in 'Related Changes' | |
| 12:30:51 | efried | um. For misc random patch that's fine, but when they're associated with a bug, blueprint, or initiative (like mox removal or py3 first), it's useful. | |
| 12:31:22 | efried | Well, yeah, on that note, in this case the fix really doesn't need to be in that series at all, does it? | |
| 12:31:48 | mdbooth | It does, because the functional test which follows it was tripping up on it | |
| 12:31:58 | mdbooth | non-deterministically | |
| 12:32:00 | efried | but only in py3, which isn't set up in the gate yet? | |
| 12:32:13 | mdbooth | Yeah, we run functional on py3 | |
| 12:32:20 | efried | "we" do? | |
| 12:32:23 | efried | looking again... | |
| 12:32:44 | efried | oic | |
| 12:32:49 | mdbooth | http://logs.openstack.org/33/591733/4/check/nova-tox-functional-py35/d9266d8/ | |
| 12:33:40 | efried | Okay; I was looking at that yesterday (for an unrelated reason) and totally missed it :( | |
| 12:33:59 | efried | hmph | |
| 12:34:11 | mdbooth | I didn't know either until I starting writing this test :) | |
| 12:34:36 | mdbooth | efried: Here's the failure in the gate, btw: | |
| 12:34:41 | efried | anyway, you never got around to telling me which func test fails. I'm getting now that it's one you're introducing in your series... | |
| 12:34:42 | mdbooth | http://logs.openstack.org/33/591733/2/check/nova-tox-functional-py35/c3d298a/job-output.txt.gz | |
| 12:34:52 | efried | ...not an existing one | |
| 12:34:54 | mdbooth | 2018-08-15 14:21:38.077216 | |
| 12:35:55 | kosamara | Hi efried. I'm revising the YAML format to include keys that any driver understands. Some keys like vendor_id make sense to many drivere; however, they might expect different values for them. | |
| 12:36:03 | mdbooth | Anything exercising that in py3 will hit it, because it's basically a syntax error. Seems nothing was previously. | |
| 12:36:16 | efried | Right, my point. | |
| 12:36:26 | kosamara | Eg PowerVM -> \X{4}, libvirt -> \x{4} | |
| 12:37:24 | kosamara | I would like to say that the value format is the driver's responsibility as well, but there needs to be a common schema. | |
| 12:37:27 | efried | kosamara: Those values come from the hardware and their form (32-bit integer) is ordained by a standard. | |
| 12:37:55 | mdbooth | Ooh, timestamps are clicky: http://logs.openstack.org/33/591733/2/check/nova-tox-functional-py35/c3d298a/job-output.txt.gz#_2018-08-15_14_21_38_077216 | |
| 12:38:19 | kosamara | Let me double check | |
| 12:39:38 | efried | kosamara: we could ask for it to be represented as an integer via the schema, so you could do 0xC001, 0xc001, 0140001 (octal), 49153 (decimal), etc. | |
| 12:40:18 | kosamara | efried: libvirt reports \x{4} | |
| 12:41:39 | kosamara | efried: solves the problem, but sounds confusing for the operator | |
| 12:42:11 | efried | kosamara: I agree. | |
| 12:42:18 | kosamara | efried: I would prefer to dictate an arbitrary format \X{4} and then it will be the driver's responsibility to normalize it. | |
| 12:43:35 | efried | kosamara: I'm fine with that. Note that yaml tries to outsmart you on this, though. It interprets e.g. C001 (without quotes) as a string, but 4321 (without quotes) as an integer base 10. | |
| 12:44:05 | efried | kosamara: So we should document that these hex values be quoted. | |
| 12:46:25 | efried | mdbooth: Is your test case really valid if it's trying to fetch a nonexistent image? Maybe we're better off fixing the fake by taking off the default to .get() to force the test author to set it up. | |
| 12:47:11 | efried | kosamara: Hm, which makes me wonder whether I did my schema validation correctly in https://review.openstack.org/#/c/579289/ | |
| 12:47:34 | efried | because I remember running across this problem. | |
| 12:47:59 | efried | but now I can't remember if the test failed because 4321 got interpreted as an int or because it failed schema validation because not a string. | |
| 12:48:10 | efried | I would hope the latter. Need to add a test. | |
| 13:04:14 | kosamara | efried: nice, thanks for the tip! | |
| 13:07:09 | mdbooth | efried: My test case isn't concerned with images. | |
| 13:07:20 | mdbooth | efried: Except that it needs to boot an instance which has disks. | |
| 13:17:19 | efried | mdbooth: I can fix the commit message and +2. | |
| 13:19:44 | openstackgerrit | Eric Fried proposed openstack/nova master: Py3 fix in fake image service https://review.openstack.org/592056 | |
| 13:20:46 | efried | mdbooth: Done ^ | |
| 13:21:29 | tobias-urdin | have a weird issue, i have some instances stuck in building (scheduling) state which show up in dashboard and with api, but server show throws NotFound exception so I cant remove them, anyubody? i've restarted nova-api, scheduler and conductors. | |
| 13:24:24 | mdbooth | efried: Thanks | |
| 13:24:43 | openstackgerrit | Matthew Booth proposed openstack/nova master: Add regression test for bug 1550919 https://review.openstack.org/591733 | |
| 13:24:43 | openstack | bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9) | |
| 13:25:27 | openstackgerrit | Matthew Booth proposed openstack/nova master: Don't delete disks on shared storage during evacuate https://review.openstack.org/578846 | |
| 13:53:35 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Making instance listing skipping down cells configurable https://review.openstack.org/592428 | |
| 13:55:52 | tssurya | mriedem: ^ | |
| 13:59:40 | kosamara | efried: What does PowerVM want to do, if the YAML it parses includes identification keys it doesn't understand? | |
| 14:00:31 | efried | kosamara: Not sure. | |
| 14:00:39 | efried | kosamara: Options: ignore, log, error. | |
| 14:00:50 | kosamara | efried: I'm tending towards making it an error in libvirt, with the assumption that the operator has made an oversight and will be baffled to see his devices not recognized if it's just ignored. | |
| 14:00:58 | efried | Right | |