| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-02 | |||
| 15:24:57 | dansmith | thanks | |
| 15:27:47 | efried | mriedem: Not that I am aware of, swhy I asked you. | |
| 15:27:55 | mriedem | efried: ok, you can do that also right? | |
| 15:28:23 | efried | mriedem: I took a look at it last week, and I'm not sure how to fix it without sorting it on both sides (test and prod). | |
| 15:28:41 | efried | mriedem: Otherwise I would have to, like, dissect the payload and deserialize the json. | |
| 15:28:52 | mriedem | if it's a json compare we have a jsonEquals helper or something | |
| 15:29:05 | mriedem | yeah we likely have to do that | |
| 15:29:37 | mriedem | nova.test.TestCase.assertJsonEqual | |
| 15:29:50 | mriedem | if no one else is going to, i'll start on the bug and patch now | |
| 15:29:53 | efried | mriedem: IIRC (I've slept since then) it's serialized JSON embedded in another object. | |
| 15:30:14 | mriedem | i'll take a look | |
| 15:30:18 | efried | mriedem: If you've got the time for it, cool. If not, I can take it. | |
| 15:32:36 | mriedem | it saves me from having to look at my mid-year pbc results | |
| 15:32:37 | mriedem | so sure | |
| 15:32:46 | mriedem | s/look/work on/ | |
| 15:34:19 | efried | Did you miss the transition from pbc to "checkpoint"? | |
| 15:38:28 | mriedem | i explained that every time i got the "you worked at ibm so you know about pbcs" joke | |
| 15:38:37 | mriedem | "actually...." | |
| 15:40:50 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add queued for delete to instance_mappings table. https://review.openstack.org/566788 | |
| 15:40:51 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Add queued_for_delete field to InstanceMapping object https://review.openstack.org/566795 | |
| 15:40:52 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: [POC] Graceful handling of nova-list when a cell is down https://review.openstack.org/567785 | |
| 15:40:56 | openstack | Launchpad bug 1779711 in OpenStack Compute (nova) "test_pre_live_migration_volume_backed* intermittently fails serialized json compare" [Critical,Confirmed] | |
| 15:40:56 | mriedem | https://bugs.launchpad.net/nova/+bug/1779711 | |
| 15:45:44 | efried | Thanks, was about to ask so I could start tagging rechecks with it :) | |
| 15:48:12 | openstackgerrit | sahid proposed openstack/nova master: libvirt: add qemu version check when configuring mtu for network https://review.openstack.org/579611 | |
| 15:51:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use assertJsonEqual in test_pre_live_migration_volume_backed* tests https://review.openstack.org/579615 | |
| 15:51:41 | mriedem | efried: ^ | |
| 15:53:47 | efried | mriedem: Does assertJsonEqual tolerate the fact that the outermost thing isn't a JSON string yet? | |
| 15:56:00 | mriedem | doesn't have to be json strings | |
| 15:56:05 | mriedem | it handles them if they are | |
| 15:56:15 | mriedem | assertDictEqual might have also worked for this | |
| 15:56:31 | mriedem | i think we use assertJsonEqual for the versioned notification payload comparisons | |
| 15:56:36 | mriedem | because of the nesting in those | |
| 15:56:52 | mriedem | assertDictEqual kind of gives a shitty error message when it fails though | |
| 15:57:32 | efried | mriedem: Looking at the source for assertJsonEqual, I don't think it's going to work in this case. | |
| 15:58:07 | mriedem | it passes for me locally | |
| 15:58:16 | efried | sure | |
| 15:58:19 | mriedem | bauzas: i'm seeing rescue tests failing since your vgpu race fix patch merged http://logs.openstack.org/47/555947/17/check/nova-multiattach/c6f458a/logs/screen-n-cpu.txt.gz#_Jun_26_15_29_18_875732 | |
| 15:58:30 | mriedem | bauzas: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22libvirtError%3A%20failed%20to%20connect%20to%20monitor%20socket%3A%20No%20such%20process%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22&from=7d | |
| 15:58:32 | efried | the failure is intermittent | |
| 15:58:51 | efried | I would think the things usually serialize the same | |
| 15:59:07 | efried | which is how this got through in the first place | |
| 15:59:13 | mriedem | yeah let me run a few times | |
| 16:01:28 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Prevent updating an RP's parent to form a loop https://review.openstack.org/579618 | |
| 16:01:40 | lyarwood | mriedem / efried ; FWIW this is also here - https://github.com/openstack/nova/blob/0ef62de88862795cf66d13f6640b68ab9b155efb/nova/tests/unit/network/test_os_vif_util.py#L32-L38 | |
| 16:03:12 | mriedem | yeah i saw the comment about test_os_vif_util in the new tests | |
| 16:03:14 | efried | mriedem: I'm just copying the reference/actual from a failing test run. | |
| 16:03:30 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Prevent updating an RP's parent to form a loop https://review.openstack.org/579618 | |
| 16:03:53 | efried | mriedem: and it fails assertJsonEqual | |
| 16:05:18 | openstackgerrit | Corey Bryant proposed openstack/nova master: Enable connection_info refresh for new-style attachments https://review.openstack.org/579004 | |
| 16:05:51 | mriedem | oh is it connection_info_json ? | |
| 16:06:04 | mriedem | yeah must be | |
| 16:06:08 | mriedem | ok | |
| 16:06:27 | efried | mriedem: Yeah. | |
| 16:08:38 | mriedem | lyarwood: that's why test_os_vif_util doesn't fail then - no embedded serialized json | |
| 16:09:42 | efried | mriedem: This sucks a little, but it works: http://paste.openstack.org/show/724766/ | |
| 16:11:13 | mriedem | i was just going to deserialize in the test and pass those on to assertEqual as it's doing now | |
| 16:11:14 | mriedem | with a note | |
| 16:11:45 | efried | ight | |
| 16:16:35 | mriedem | i might also be able to handle this generically in assertJsonEqual | |
| 16:16:39 | mriedem | i'll try both | |
| 16:28:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle nested serialized json entries in assertJsonEqual https://review.openstack.org/579615 | |
| 16:28:57 | mriedem | efried: ok the generic one wins ^ | |
| 16:29:56 | efried | mriedem: I still don't see how that's going to help. The outermost object is not a string type. | |
| 16:30:25 | efried | nor is the first level in, which is I guess what you're targeting now. | |
| 16:32:43 | mriedem | i'm doing it in the recursion | |
| 16:33:14 | mriedem | bauzas: nvm i guess that's just something that shows up a lot in the gate | |
| 16:33:19 | efried | mriedem: Okay, yeah, I see the recursion now. | |
| 16:35:43 | mriedem | i'm pretty sure it's the greatest patch i've written in years | |
| 16:53:52 | openstackgerrit | Merged openstack/nova master: Fix missing versioned notification examples https://review.openstack.org/579436 | |
| 17:33:03 | openstackgerrit | Surya Seetharaman proposed openstack/nova-specs master: Handling a down cell https://review.openstack.org/557369 | |
| 17:52:04 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: return consumer info even when no alloc https://review.openstack.org/579654 | |
| 17:52:27 | Sundar | efried, please ping me when you can. Thanks. | |
| 17:52:47 | efried | Sundar: I'm here. What's up? | |
| 18:00:32 | openstackgerrit | Merged openstack/nova master: Remove unnecessary execute permissions of a file https://review.openstack.org/579511 | |
| 18:00:55 | Sundar | efried: Do you have a few minutes re. os-acc spec? | |
| 18:01:05 | efried | Sundar: sure | |
| 18:01:53 | efried | I'd like to understand how cyborg is going to do "discovery", actually. | |
| 18:02:36 | Sundar | Re. the idea that os-acc should operate in 3 stages (call Cyborg for prep, call plugin, and then call Cyborg again for post/cleanup), since the plugin has device/vendor-specific code, and Cyborg also has device/vendor-specific code, | |
| 18:03:00 | Sundar | the split in responsibilities, becomes unclear | |
| 18:03:41 | Sundar | If you delegate all device/vendor-specific code to the plugn, and let it either handle it or delegate to Cyborg as needed, that would be a cleaner split. What do you think? | |
| 18:03:42 | efried | It's "Cyborg also has device/vendor-specific code" that I'm confused about | |
| 18:04:23 | Sundar | Cyborg supports a system of drivers. Some drivers already exist. #link https://wiki.openstack.org/wiki/Cyborg#Pike.2FQueens_Initial_Architecture | |
| 18:04:30 | efried | ... | |
| 18:05:13 | efried | Sundar: Does this support exist on all platforms, or just kvm? | |
| 18:06:28 | efried | This is my concern. There's no way cyborg has written device discovery etc. on power. Or am I wrong? | |
| 18:07:00 | Sundar | The initial implementation is expected to be for libvirt, possibly qemu/KVM. However, based on our conversation, we could say all hypervisor/platform-specific stuff could be in the plugin. The Cyborg drivers would handle device-specific aspects | |
| 18:07:12 | Sundar | Cynorg architecture is hypervisor-neutral | |
| 18:07:20 | Sundar | * Cyborg | |
| 18:07:25 | efried | Right. I'm on board with that. | |
| 18:07:49 | efried | So we need to define the flows as if that's always the case. | |
| 18:09:07 | Sundar | Yes. Some things the plugin does (the Instance Half of the attach) are hypervisor/platform-specific. Other things (Device half) are device/vendor/platform-specific. ... | |
| 18:09:38 | Sundar | The split of roles between the plugin and Cyborg driver could be left to the plugin? | |
| 18:09:58 | efried | No, that's where we disagree. | |
| 18:11:00 | efried | The overall logic flow should live in cyborg-owned code (whether cyborg service or os-acc or whatever) so that it need only be written once. | |
| 18:11:58 | efried | The plugin should be responsible for the very granular leaf primitives that deal specifically with the platform, nothing else. | |
| 18:13:36 | Sundar | Does the 'platform' include the device-specific aspects, or hypervisor/architecture/system only? | |
| 18:14:40 | Sundar | If the latter, I am totally on board | |
| 18:15:01 | Sundar | If the former, we need to define what the plugin does vis-a-vis Cyborg driver(s) | |
| 18:15:18 | efried | I don't really know enough about the specifics of managing devices to be able to answer that, but yes, I'm hoping we can define the flow so the latter is possible. | |