| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-19 | |||
| 18:15:49 | efried | aspiers: Done, lmk if there are any stragglers not in the series that you'd like similarly tagged. | |
| 18:15:57 | aspiers | efried: yeah, I think 644554 could maybe merge pre-Stein without doing harm | |
| 18:16:05 | aspiers | sean-k-mooney: reading | |
| 18:16:05 | efried | agree | |
| 18:16:21 | efried | aspiers: if you can get that efried guy to approve it. | |
| 18:16:25 | aspiers | :) | |
| 18:16:33 | aspiers | efried: sounds like a tall order | |
| 18:17:19 | efried | aspiers: I almost did a full rewrite of that method, but I'll settle for nixing backslashes. | |
| 18:18:11 | aspiers | hrm, nix them how? | |
| 18:18:57 | efried | aspiers: Use parens, or use an if, or... | |
| 18:19:29 | aspiers | OK | |
| 18:20:04 | efried | it's just a style rule that nova likes to follow. I'm pretty sure there was a time I didn't care, but now I'm brainwashed. | |
| 18:20:09 | aspiers | sure | |
| 18:22:50 | aspiers | sean-k-mooney: seems like a key question is whether mlock(2) really is enough for SEV or not | |
| 18:26:01 | aspiers | sean-k-mooney, bbobrov: I guess there's also #libvirt | |
| 18:30:16 | sean-k-mooney | aspiers: i think its calling https://linux.die.net/man/2/setrlimit but yes let use know what they determin | |
| 18:33:24 | sean-k-mooney | but as i said before im pretry sure hard_limit is not actully locking the memory its just limiting how much memory can be locked by an unprivalaged process | |
| 18:33:58 | aspiers | sean-k-mooney: yes, I think it needs the combination of setrlimit and mlock | |
| 18:35:18 | sean-k-mooney | which https://github.com/AMDESE/AMDSEV/blob/master/xmls/sample.xml does not do :) | |
| 18:35:44 | sean-k-mooney | anyway im going to grab something to eat | |
| 18:35:49 | sean-k-mooney | be back in a bit | |
| 18:35:57 | aspiers | OK, me too. Cheers for the help! | |
| 18:49:28 | openstackgerrit | Lance Bragstad proposed openstack/nova master: Give the policy vision document a facelift https://review.openstack.org/644615 | |
| 19:30:02 | sean-k-mooney | /away until noon gmt | |
| 19:30:19 | sean-k-mooney | extra space .... | |
| 19:45:54 | spbarbieri | I provision a server with a block_device that specifies a volume to be used as the boot volume. I'd like to use the REST API to determine if a block_device was used to boot the instance, and if so, which attached volume is the boot volume for the server. The "server details" api returns an empty "image" so I guess I can assume it used a volume as the boot device, but I don't know how to determine which attached volume is t | |
| 19:50:58 | artom | spbarbieri, you can list volume attachments with https://developer.openstack.org/api-ref/compute/?expanded=list-volume-attachments-for-an-instance-detail,show-a-detail-of-a-volume-attachment-detail#list-volume-attachments-for-an-instance, but that wouldn't tell you whether one was used for boot | |
| 19:58:45 | spbarbieri | Thanks for the pointer. When creating the server I can specify "block_device_mapping_v2.delete_on_termination". This is saved somewhere because my volume is deleted on server termination. I was hoping that the "this is the boot device" was saved there as well. But, I couldn't find it in any of the server/volume/volume_attach apis. | |
| 20:05:47 | artom | spbarbieri, I *think* boot_index is what you're looking for, but it doesn't look like we expose it anywhere in the API | |
| 20:06:03 | artom | spbarbieri, you can also tag with 'boot' as a workaround | |
| 20:14:22 | spbarbieri | yeah, boot_index would be perfect. I couldn't find it anywhere either. I'm actually trying to do this after the fact. I have a running server and I want to know which volume was used as the boot drive. I only have access to the REST API...sounds like a MacGyver episode...find the boot drive using a paperclip and some duct tape | |
| 20:23:05 | openstackgerrit | Merged openstack/nova master: Use assertXmlEqual() helper for all XML comparison tests https://review.openstack.org/641852 | |
| 20:23:13 | openstackgerrit | Merged openstack/nova stable/rocky: Allow utime call to fail on qcow2 image base file https://review.openstack.org/643011 | |
| 20:24:00 | mriedem | spbarbieri: that's eventually going to show up in the API here https://review.openstack.org/#/c/623981/24 | |
| 20:24:13 | mriedem | e.g. https://review.openstack.org/#/c/623981/24/doc/api_samples/os-volumes/v2.72/volume-attachment-detail-resp.json | |
| 20:25:56 | mriedem | if you're an admin, you could also see the OS-EXT-SRV-ATTR:root_device_name parameter in the response from the GET /servers/{server_id} API | |
| 20:26:21 | mriedem | and match that to the volume with the same device name, although those aren't guaranteed to be where the root volume is mounted in the guest | |
| 20:27:58 | spbarbieri | Thanks for the pointer to the volume-attach details. That will be helpful. I'm running against my local devstack, as admin, and I don't get that returned. I'm calling compute/v2.1/servers/{id}. | |
| 20:55:06 | melwitt | spbarbieri: are you using novaclient or openstackclient? if the latter, you need to pass the necessary compute API microversion to see the volume-attach info. i.e. --os-compute-api-version 2.3 (see https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-kilo) | |
| 20:55:35 | melwitt | s/volume-attach info/root_device_name/ | |
| 20:57:51 | spbarbieri | melwitt: I'm using Postman with direct REST API calls | |
| 21:00:28 | melwitt | spbarbieri: OK, see this doc on how to specify compute API microversion with the HTTP header https://developer.openstack.org/api-guide/compute/microversions.html#client-interaction | |
| 21:04:41 | spbarbieri | melwitt: Yes! Thanks. Adding that header works. I guess now I can match the root_device_name against all of the attached volumes to find a match. Does that seem reasonable? | |
| 21:06:24 | melwitt | spbarbieri: I think so, based on what mriedem said earlier | |
| 21:07:07 | spbarbieri | melwitt: Thank you for the help. | |
| 21:07:18 | melwitt | np, good luck | |
| 21:58:27 | openstackgerrit | melanie witt proposed openstack/nova master: Add a prelude release note for the 19.0.0 Stein GA https://review.openstack.org/644412 | |
| 22:05:13 | efried | melwitt: it's like VOIP in the '90s. | |
| 22:05:18 | efried | or, you know, skype today. | |
| 22:05:24 | melwitt | haha, yeah | |
| 22:20:05 | mriedem | melwitt: efried: cdent: dansmith: also dumped comments in the prelude https://review.openstack.org/#/c/644412/ about vgpu | |
| 22:20:12 | mriedem | i'd either remove that or really dumb it down | |
| 22:21:00 | melwitt | mriedem: thanks | |
| 22:21:30 | efried | mriedem: The part I was concerned about: | |
| 22:21:41 | efried | admins will sometimes list resource providers | |
| 22:21:48 | mriedem | the vcenter driver also supports live migration, that's a long-standing thing that might be worth mentioning | |
| 22:21:50 | efried | Now they're gonna see two instead of one for some hosts | |
| 22:22:02 | efried | that's a user-facing manifestation of the nrp-for-vgpus thing. | |
| 22:22:12 | efried | that's the only reason I think it's worth mentioning | |
| 22:22:20 | melwitt | mriedem: ack | |
| 22:22:23 | efried | otherwise I agree there would be no reason to talk about it. | |
| 22:22:46 | efried | "We did this thing, so don't be surprised if you see two resource providers for a libvirt host with VGPUs." | |
| 22:22:58 | melwitt | I see, yeah | |
| 22:23:33 | mriedem | there is an upgrade release note for it right? so as long as we can really distill the prelude comment on that to something short and sweet | |
| 22:24:06 | efried | sorry I've been entirely ineffectual phrasing that :( I've been trying to nail down the zillion UT failures that happen when you change how ksa is mocked. Different headspace. | |
| 22:24:08 | melwitt | there is an upgrade note, but it doesn't really spell out what an admin would see as a change when they list RPs | |
| 22:24:18 | mriedem | "Upon restarting nova-compute services using the libvirt driver which expose VGPU inventory, the inventory will be moved from the root compute node resource provider to a child resource provider. See the upgrade notes for details." | |
| 22:24:40 | efried | wfm | |
| 22:24:48 | melwitt | yeah, that sounds good | |
| 22:25:16 | mriedem | how about, ""Upon restarting nova-compute services using the libvirt driver which expose VGPU inventory, the inventory will be moved from the root compute node resource provider to a child resource provider. As a result, when listing resource providers, you may see two for the same compute node where there was one before. See the upgrade notes for details." | |
| 22:25:27 | efried | even better | |
| 22:25:30 | melwitt | thumbs up | |
| 22:29:28 | openstackgerrit | Adam Spiers proposed openstack/nova master: Move libvirt calculation of machine type to utils.py https://review.openstack.org/644554 | |
| 22:34:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Address old TODO in claim_resources_on_destination https://review.openstack.org/644596 | |
| 22:40:07 | openstackgerrit | melanie witt proposed openstack/nova master: Add a prelude release note for the 19.0.0 Stein GA https://review.openstack.org/644412 | |
| 22:53:23 | openstackgerrit | melanie witt proposed openstack/nova master: Add known issue for minimum bandwidth resource leak https://review.openstack.org/644694 | |
| 22:55:03 | melwitt | mriedem: gibi recommended the above is not an RC blocker, but I thought it might help to add a known issue reno about it ^ | |
| 23:04:18 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: Use openstacksdk for placement https://review.openstack.org/643664 | |
| 23:04:18 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: Use SDK instead of ironicclient for node.get https://review.openstack.org/642899 | |
| 23:04:19 | efried | dustinc: Warning: update here ^ | |
| 23:04:36 | dustinc | thanks, I'll check it | |
| 23:04:38 | efried | you will need to refetch and put your changes onto the new commit | |
| 23:04:49 | dustinc | was just working on sdk_wrapper.py | |
| 23:04:57 | efried | easiest way if you haven't already committed locally would be to stash, review -d, and restore | |
| 23:05:05 | efried | dustinc: But we don't need sdk_wrapper.py | |
| 23:05:09 | efried | do we? | |
| 23:06:06 | dustinc | I thought we do...maybe we need to sync up on CONF tomorrow...I thought we needed to read everything and pass it to the SDK? | |
| 23:06:43 | efried | dustinc: Oh, that's done already :) | |
| 23:07:01 | dustinc | ok, I will stash my work and check yours out then I am going offline shortly | |
| 23:07:07 | dustinc | let's sync back up tomorrow | |
| 23:07:29 | efried | dustinc: See the predecessor patch at https://review.openstack.org/#/c/643664/5/nova/utils.py@1239 | |
| 23:08:11 | efried | dustinc: So the only change needed to have ironic make use of that was here: https://review.openstack.org/#/c/642899/16/nova/virt/ironic/driver.py@188 | |
| 23:08:31 | efried | dustinc: And tbc, this works, which you can tell by looking at the CI results, if you know what you're looking for: | |
| 23:08:55 | efried | The job called ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa only succeeds if ^ is copacetic | |
| 23:09:08 | efried | Here's the last run (before the latest rebase): http://logs.openstack.org/99/642899/15/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/c032d49/ | |
| 23:09:14 | efried | http://logs.openstack.org/99/642899/15/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/c032d49/testr_results.html.gz | |
| 23:09:42 | efried | The other red stuff in the CI report is the unit and functional tests - for those, it's the actual tests that need to be fixed, not the code. | |
| 23:09:58 | efried | and most of the test fixage needs to happen in the predecessor patch - which is what I've been working on. | |
| 23:10:11 | efried | made a little progress today, but definitely didn't finish. | |
| 23:10:16 | efried | a couple of serious mysteries in there still. | |