| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-02 | |||
| 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. | |
| 18:16:24 | Sundar | Great. OK, how about this? Let's go with the 3-stage flow for os-acc: prep by calling Cyborg, call plugin, and finish by calling Cyborg. All device-specific aspects are left to the 1st and 3rd steps, to be done by a Cyborg driver. | |
| 18:16:45 | Sundar | All hypervisor/platform/system/arch-dependent steps are for the plugin | |
| 18:17:20 | efried | Yes. BUT it might not be as simple as three stages, I'm not sure. | |
| 18:18:07 | efried | let me walk through a (hypothetical) example to show you what I mean... | |
| 18:18:56 | efried | hold a minute... | |
| 18:22:15 | efried | Sundar: Okay, sorry about that - was finishing up a soooper messy lunch, typing with one hand. I'm back to full speed now. | |
| 18:22:28 | efried | So here's the example: I want to program and attach an FPGA | |
| 18:23:08 | efried | Cyborg can do the programming, but in order to do so, it needs to be supplied with a file-like that's piped to the device. | |
| 18:23:18 | efried | (Again, no idea how realistic this is, but go with me for a bit here) | |
| 18:23:57 | efried | The user says "program the device with bitstream from image XYZ" | |
| 18:24:11 | efried | Cyborg calls the plugin and says "give me a file-like so I can program". | |
| 18:24:36 | efried | On libvirt, maybe the plugin just does f = open("/path/to/special_file") and gives back f. | |
| 18:24:49 | efried | On Power, we probably have to attach the device to the management partition and then do ^ | |
| 18:25:18 | efried | On Windows, gods forbid, who knows what happens, but it'd be like D:\path\to\special_file anyway... | |
| 18:25:36 | efried | So then control goes back to cyborg, which goes and happily flashes the device. | |
| 18:25:59 | efried | Now there has to be a "close/cleanup" step. Cyborg calls the plugin and says, "Okay, I'm done". | |
| 18:26:30 | efried | On libvirt, in this example, it's just close(f). On Power, close(f) and detach the device from the management partition. On Windows.... who knows, whatever. | |
| 18:27:47 | efried | Sundar: Now, I don't know where this fits in the overall "plug" flow. Does it happen before or after we attach the thing to the VM? I would assume before. | |
| 18:28:00 | efried | Except if there's a flow where we program the thing while it's already attached; I don't even know how that would work. | |
| 18:28:00 | Sundar | We already have provisions for programming from Cyborg drivers (not yet implemented fully). Re. "a file-like that's piped to the device", the bitstreams will reside in Glance and will be accessed via image UUID. | |
| 18:28:16 | efried | Sundar: Right, that's where the data comes *from*, but how does it get *to* the device? | |
| 18:28:36 | efried | The glance side is the source of the data. You need a sink. | |
| 18:29:29 | Sundar | The Cyborg FPGA driver knows what to do. Anyway, you will have a vendor stack -- like OPAE kernel drivers for Intel FPGAs, Xilinx stack etc. | |
| 18:29:29 | efried | Or maybe what you're saying is the program_fpga plugin method will be given the source handle and be responsible for pushing the data from that handle to the device. | |
| 18:29:32 | efried | That would be fine too. | |
| 18:29:49 | Sundar | The Cyborg FPGA driver knows how to interface with the vendor-specific stack | |
| 18:30:07 | efried | vendor-specific, sure, but on all platforms? That's the part I'm doubting. | |