| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-19 | |||
| 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 | dan@guaranine:~$ | |
| 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: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: Allow the output format of qemu-img info to be controlled https://review.opendev.org/706898 | |
| 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:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Correctly resize encrypted LUKSv1 volumes https://review.opendev.org/706900 | |
| 15:53:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: virt: Pass request context to extend_volume https://review.opendev.org/706899 | |
| 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 | dansmith | I don't have a hostname configured in my cyborg.conf, if that's what you mean | |
| 16:14:22 | sean-k-mooney | but it think that is a sideffect fo the fact the agentd dont create or manage the RPs | |
| 16:14:42 | dansmith | it shouldn't matter | |
| 16:14:52 | dansmith | if you need a uuid for the parent and don't find one, you should not create a root one | |
| 16:15:09 | sean-k-mooney | the [DEFAULT]/host option | |
| 16:15:18 | sean-k-mooney | yes | |
| 16:15:21 | sean-k-mooney | well | |
| 16:15:23 | sean-k-mooney | actully no | |
| 16:15:38 | sean-k-mooney | so in the case where cyborg is managning a device on a node that is not a compute node you should | |
| 16:15:45 | sean-k-mooney | there cinder like use case | |
| 16:15:46 | dansmith | sure, but not in this case | |
| 16:15:51 | sean-k-mooney | ya | |
| 16:16:02 | sean-k-mooney | im not sure they have a way to tell however | |
| 16:16:09 | dansmith | well, then *that* is broken :) | |