Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-19
11:19:13 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: Make RBD imagebackend flatten method idempotent https://review.opendev.org/708615
11:19:41 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Make RBD imagebackend flatten method idempotent https://review.opendev.org/708616
11:19:59 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Make RBD imagebackend flatten method idempotent https://review.opendev.org/708617
11:20:30 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: Make RBD imagebackend flatten method idempotent https://review.opendev.org/708615
11:24:56 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: Make RBD imagebackend flatten method idempotent https://review.opendev.org/708615
11:25:02 lyarwood gah, I need to repost some of these, sorry!
11:25:31 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Make RBD imagebackend flatten method idempotent https://review.opendev.org/708616
11:25:47 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Make RBD imagebackend flatten method idempotent https://review.opendev.org/708617
11:25:51 lyarwood okay done, lyarwood--
13:06:29 stephenfin lyarwood: Question for you at https://review.opendev.org/#/c/706897/2/nova/virt/images.py@53
13:32:10 mnaser dansmith: the backfilling issue is confirmed to be resolved, just did it against a cloud with ~450kish records in instances table
13:32:20 mnaser so it didnt try to backfill the hidden value
13:58:30 openstackgerrit Merged openstack/nova master: Absolutely-non-inheritable image properties https://review.opendev.org/708126
13:58:40 openstackgerrit Merged openstack/nova master: tests: Validate huge pages https://review.opendev.org/399653
14:34:13 bauzas stephenfin: ack for the placement audit review and thanks, will look
14:36:29 bauzas stephenfin: and I added a better explanation in https://review.opendev.org/#/c/706466/
14:36:38 bauzas that won't be in the commit msg but okay
14:44:12 dansmith mnaser: sweet, that's been backported and released now so hopefully nobody else will hit it
14:44:18 dansmith mnaser: thanks for being the front line :)
14:49:06 mnaser dansmith: yep, thanks for helping out in nailing down the root cause. I appreciate it.
14:49:16 dansmith np
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

Earlier   Later