| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-19 | |||
| 14:56:27 | openstackgerrit | Dongcan Ye proposed openstack/nova master: libvirt: Check the guest support UEFI https://review.opendev.org/685678 | |
| 15:07:50 | lyarwood | stephenfin: ack thanks, I'll reply shortly | |
| 15:20:35 | dansmith | sean-k-mooney: so looking into my failures from yesterday, I'm actually getting an error from placement: | |
| 15:20:52 | dansmith | sean-k-mooney: "There is more than one numbered request group in the allocation candidate query but the flavor did not specify any group policy. This query would fail in placement due to the missing group policy." | |
| 15:20:54 | dansmith | efried: ^ | |
| 15:21:38 | dansmith | my flavor is pretty vanilla with the exception of an accel:device_profile key | |
| 15:21:39 | efried | interesting; there should be gibi code defaulting the group_policy in this case. Perhaps the dp groups are being added after that. | |
| 15:22:04 | gibi | hm hm | |
| 15:22:27 | dansmith | but it sounds like it works (past this point) for sean-k-mooney and was working in the tempest job last I looked | |
| 15:22:27 | gibi | the defaulting code checks what groups are coming from the flavor and what are from the ports | |
| 15:24:01 | gibi | we only default to none if the flavor does not specify groups | |
| 15:24:05 | efried | dansmith: oh, is that warning actually preceding a failure? | |
| 15:24:48 | dansmith | efried: yeah, "got no acs", but I guess I thought it was saying "expect no results shortly" | |
| 15:24:49 | efried | sorry, I'm interleaving. Sounds like this is working as designed, defaulting the group_policy to 'none'. | |
| 15:24:59 | dansmith | ahhh | |
| 15:25:10 | dansmith | I see the real error, it was hidden in the json: | |
| 15:25:17 | dansmith | Invalid resource class in resources parameter: No such resource class CUSTOM_ACCELERATOR_XYZ | |
| 15:25:26 | dansmith | duh sorry | |
| 15:25:59 | dansmith | I'm not sure where that comes from or what I'm supposed to do to make this work in devstack | |
| 15:26:00 | efried | would there be a better way to percolate that error up? | |
| 15:26:17 | dansmith | I would have expected it to fully configure a fake driver, compute, and traits/classes | |
| 15:26:18 | efried | dansmith: I think ordinarily cyborg would create the resource class. In devstack you can create it manually. | |
| 15:26:35 | efried | yeah, good point, the "fake driver" should probably do it. | |
| 15:26:51 | dansmith | I'm not sure where "CUSTOM_ACCELERATOR_XYZ" comes from either | |
| 15:27:01 | efried | That would be in the device profile. | |
| 15:27:05 | dansmith | from cyborg I guess, stating what the resources for the profile should be? | |
| 15:27:07 | dansmith | yeah, | |
| 15:27:12 | dansmith | so ... seems like it should have done more | |
| 15:27:20 | efried | agree | |
| 15:27:57 | dansmith | efried: I was asking sean-k-mooney this yesterday, but will the fake driver expose the inventory for me as well or do I need to hack up some of that? | |
| 15:29:01 | efried | dansmith: I don't know what it *does* do, but I feel like ultimately it *should* do all of that. | |
| 15:29:16 | gibi | for me the cyborg fake driver created FPGA rc and inventory with a CUSTOM_FAKE_DEVICE trait | |
| 15:29:19 | dansmith | yeah, looking for the former | |
| 15:29:59 | dansmith | now I get complaints about two traits that don't exist, so I guess I need to create those too? | |
| 15:31:02 | gibi | dansmith: can it be that you need to create a device profile that asks for FPGA resource and some fake device ? | |
| 15:31:24 | dansmith | gibi: I dunno, I was expecting this to all kinda be done for me in devstack, so I'm not sure what I'm expected to do | |
| 15:31:31 | dansmith | gibi: did you get it working? | |
| 15:31:45 | gibi | dansmith: the device profile Sundar's script describes does not match with what the fake driver provides | |
| 15:32:20 | gibi | dansmith: I was able to stack a devstack but did not created any device profile yet to consume | |
| 15:32:34 | dansmith | yeah, I'm right about there myself | |
| 15:33:02 | gibi | dansmith: I think the mistmatch is in http://paste.openstack.org/show/789709/ Sundar provided. Those examples are not aligned with the fake driver | |
| 15:33:45 | dansmith | okay | |
| 15:33:54 | gibi | we nead sean-k-mooney to show us what kind of device profile he uses | |
| 15:34:11 | dansmith | yeah he said he was going to do that this morning I think | |
| 15:34:51 | gibi | sorry I have to leave for today :/ I will read back tomorrow | |
| 15:34:56 | dansmith | o/ | |
| 15:35:03 | gibi | o/ | |
| 15:38:01 | dansmith | it also seems like there is a bunch in that "script" that could/should be replaced with client calls | |
| 15:38:06 | dansmith | instead of curl'ing everything | |
| 15:39:11 | openstackgerrit | Dongcan Ye proposed openstack/nova master: libvirt: Check the guest support UEFI https://review.opendev.org/685678 | |
| 15:48:13 | dansmith | efried: is there any way in the placement osc client to tell what providers are parent/child of each other? | |
| 15:48:47 | efried | dansmith: Almost sure you can see parent RP IDs, but there's not going to be like a tree view or anything. | |
| 15:49:01 | dansmith | do I need a microversion for that? | |
| 15:49:05 | dansmith | in rp show, I don't see anything | |
| 15:49:37 | dansmith | ah yeah, picked a random higher microversion and I see parent_uuid | |
| 15:49:46 | efried | dansmith: there's a --in-tree | |
| 15:50:09 | dansmith | so, the cyborg fake driver is creating a RP peer to the compute node RP, not in a tree | |
| 15:50:36 | efried | oops :P | |
| 15:50:43 | dansmith | I've been kinda punting on looking at how these are modeled, but... is that how it's supposed to be? are we using aggregates to associate those? | |
| 15:50:50 | efried | (I would set OS_PLACEMENT_API_VERSION=1.36 so you don't have to worry about it anymore) | |
| 15:51:05 | efried | No, it's supposed to be a child of the compute node | |
| 15:51:18 | dansmith | okay | |
| 15:51:19 | efried | unless something drastic changed about the design. | |
| 15:51:21 | dansmith | thought so | |
| 15:52:11 | dansmith | efried: btw, Invalid placement client version '1.36'. must be one of: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22, 1.28 | |
| 15:52:11 | dansmith | dan@guaranine:~$ | |
| 15:53:00 | efried | That's an odd max version, middle of rocky. | |
| 15:53:30 | efried | oh, unless the osc commands individually cap, which they very well might :( | |
| 15:53:48 | dansmith | ugh, osc version handling sucks so bad | |
| 15:53:50 | openstackgerrit | Lee Yarwood proposed openstack/nova master: images: Move qemu-img info calls into privsep https://review.opendev.org/706897 | |
| 15:53:50 | openstackgerrit | Lee Yarwood proposed openstack/nova master: images: Allow the output format of qemu-img info to be controlled https://review.opendev.org/706898 | |
| 15:53:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: virt: Pass request context to extend_volume https://review.opendev.org/706899 | |
| 15:53:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Correctly resize encrypted LUKSv1 volumes https://review.opendev.org/706900 | |
| 15:53:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM - Test TEMPEST_EXTEND_ATTACHED_ENCRYPTED_VOLUME https://review.opendev.org/707593 | |
| 15:53:53 | efried | so, never mind, that env var isn't helpful. Yes, agree. | |
| 15:54:28 | dansmith | every time I have to tell people to specify a specific version to do some thing I die a little inside | |
| 15:54:30 | efried | I'm sure it came from a place of, "This command has only been coded to handle up to microversion X, so using anything higher might blow it up, so let's cap it" | |
| 15:54:37 | dansmith | yeah | |
| 15:55:02 | dansmith | and that's fine, but I should be able to specify a max, or have it use its own max when in CLI mode like we do in nova | |
| 15:55:19 | efried | right, you should be able to say 'latest' and have it do the latter. | |
| 15:55:29 | dansmith | so, | |
| 15:55:44 | dansmith | it looks like the fake driver just exports devices and something in cyborg itself is what creates the providers | |
| 15:56:20 | dansmith | which really shouldn't happen without a parent, AFAICT, so I guess cyborg itself has a bug, both in how it is creating the provider, and that it is agreeing to create one as a root | |
| 16:10:35 | sean-k-mooney | dansmith: you mean in how the cyborg agent on the compute node does an rpc call to the conductor to create and update then placment RP form a perodic task | |
| 16:10:53 | sean-k-mooney | because yse i think that is also an architural bug | |
| 16:11:06 | dansmith | not sure I parsed that | |
| 16:11:24 | dansmith | sean-k-mooney: there should be an RP created by cyborg, which is a child of the compute node provider right? | |
| 16:11:27 | sean-k-mooney | the cyborg agents dont call placement to create the RPs or update them | |
| 16:11:33 | sean-k-mooney | yes | |
| 16:11:56 | dansmith | sean-k-mooney: in my stack, cyborg has created a root provider called "FakeDevice", not child under the compute node | |
| 16:12:10 | sean-k-mooney | in my case its a child | |
| 16:12:35 | dansmith | okay, not sure how that got screwed up for me, but this is basically a virgin stack | |
| 16:13:13 | sean-k-mooney | am it could be down to the oder in which they started | |
| 16:13:23 | sean-k-mooney | or if the config name is not correct in the cyborg config | |
| 16:13:33 | dansmith | that's a bug then, | |
| 16:13:34 | dansmith | because it shouldn't create it as a root if it doesn't find the parent | |
| 16:13:42 | sean-k-mooney | ya | |
| 16:14:03 | sean-k-mooney | it should likely fail to start the agent and complain loudly in the log | |
| 16:14:09 | dansmith | yes | |
| 16:14:22 | sean-k-mooney | but it think that is a sideffect fo the fact the agentd dont create or manage the RPs | |