| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-11 | |||
| 10:16:07 | bauzas | mmm, I'm slapped by an InventoryInUse exception when I start testing VGPU allocations | |
| 10:16:20 | gibi | yjk_: interesting finding. | |
| 10:16:20 | bauzas | jianghuaw_: have you faced the same ? | |
| 10:16:53 | bauzas | jianghuaw_: I had an exception when I started a new instance, so I destroyed it (it was in ERROR state) | |
| 10:17:08 | bauzas | but since now, every inventory update leads to InventoryInUse thingy | |
| 10:17:42 | gibi | yjk_: do you see the same problem for versioned notifications? | |
| 10:19:34 | jianghuaw_ | bauzas, I don't have the issue at the moment. Is the exception reported when deleting inventory? | |
| 10:20:09 | jianghuaw_ | Is it the first instance booted with a vgpu? | |
| 10:20:11 | gibi | yjk_: anyhow could you please file a bug about it? | |
| 10:20:13 | bauzas | jianghuaw_: no, the story is more like that : | |
| 10:20:22 | bauzas | Jan 11 05:10:18 virtlab606.virt.lab.eng.bos.redhat.com nova-compute[80886]: INFO nova.scheduler.client.report [None req-4fdc9878-61e9-4b2f-8e92-1913486f0c9a demo admin] [req-b7b27fd5-31f8-43da-9d52-c2066d0b7af2] Inventory update conflict for e4304148-2f21-417b-bf78-9f3bc90f0ec7 with generation ID 7 | |
| 10:20:33 | bauzas | because of the generation bit | |
| 10:21:08 | bauzas | that would lead to deleting the inventory as it's planned *but* the scheduler client is checking whether that inventory is in use - and yes, it's the case | |
| 10:21:15 | bauzas | because I have 3 fully functional VMs | |
| 10:21:27 | bauzas | with VGPU allocations to them | |
| 10:21:54 | bauzas | cdent is off, edleafe, jaypipes and efried aren't there yet | |
| 10:21:57 | jianghuaw_ | Ah, then it should be a bug. | |
| 10:22:03 | bauzas | so I dunno who could help me | |
| 10:22:09 | bauzas | yes, this is a bug I guess | |
| 10:23:16 | jianghuaw_ | Is it in a single compute node env or multiple nodes? | |
| 10:23:49 | bauzas | single one | |
| 10:24:14 | bauzas | so, it tries to update with generation=8 but the RP already has generation=8 so I guess it's the problem | |
| 10:27:55 | gibi | yjk_: the code you linked above has a comment "Owner properties" so I think the original intention was to include the user id of the owner of the VM there | |
| 10:28:31 | gibi | yjk_: but still I can understand the need to know the user id of the user who initiated the action | |
| 10:29:04 | jianghuaw_ | bauzas, checking in my side. May you share me your procedure? Just boots 3 VMs with vGPU in sequence? And met the exception as the 3rd vm boots up? | |
| 10:29:04 | gibi | yjk_: I think we can add that as a separate field, so both the owner and the action initiator is available in the notification | |
| 10:29:33 | bauzas | jianghuaw_: #1 just create a new instance using a VGPU allocation | |
| 10:30:02 | bauzas | #2 then, make sure you'll get an exception (and the instance being in ERROR) for a second instance asking for the same VGPU class | |
| 10:30:12 | bauzas | #3 restart nova-compute | |
| 10:30:28 | bauzas | #4 you'll see that InventoryInUse exception then | |
| 10:30:45 | yjk_ | @gibi: That sounds good. | |
| 10:31:24 | jianghuaw_ | bauzas, for #2 how did you trigger the exception? | |
| 10:33:32 | jianghuaw_ | or what's the exception met in #2? | |
| 10:35:36 | bauzas | jianghuaw_: it was just an exception raised by privsep when I was trying to create a new mdev | |
| 10:35:47 | bauzas | jianghuaw_: but I guess any exception raised by the virt driver is fine | |
| 10:36:06 | bauzas | I'll need to disappear for 2 hours | |
| 10:36:16 | jianghuaw_ | yep, understood. | |
| 10:39:02 | yjk_ | Thanks for the reply gibi. | |
| 10:39:35 | yjk_ | I have another query. | |
| 10:39:47 | yjk_ | I have an openstack Newton setup with 3 compute nodes. I have booted VMs from a bootable volume. Setup uses iSCSI disk shared between computes. Whenever, I try nova evacuate, it fails with an ERROR: FailedISCSITargetPortalLogin: Could not login to any iSCSI portal It seems that "connect_volume" call on the new host fails because it is not able to authenticate with iSCSI. | |
| 10:40:02 | yjk_ | I believe it (whoever responsible) creates isci credentials when volume attach is initiated from a host. During migration, it should cleanly update the credentials so new host can access. | |
| 10:41:23 | yjk_ | Any ideas on what may be causing this issue? | |
| 11:02:18 | jianghuaw_ | bauzas, I've tried several ways to trigger the exception in #2 but I didn't see the issue " Inventory update conflict " on my side. | |
| 11:03:17 | cdent | bauzas: I'm here now (re [t 3csz] ). What's up? | |
| 11:03:17 | purplerbot | <bauzas> cdent is off, edleafe, jaypipes and efried aren't there yet [2018-01-11 10:21:54.269899] [n 3csz] | |
| 11:04:23 | yjk_ | Compute host logs where the VM was getting migrated (evacuated) to are available on http://paste.openstack.org/show/642545/. Your help would be really appreciated. Thanks | |
| 11:06:11 | bauzas | jianghuaw_: cdent: nevermind, I found the root cause : PEBKAC | |
| 11:06:29 | bauzas | lemme tell you the story tho | |
| 11:06:46 | bauzas | so, in my changes, I said that the min version for mdevs is 3.4.0 | |
| 11:06:48 | jianghuaw_ | listening | |
| 11:07:03 | bauzas | but for RHEL7.4, it's 3.2.0 | |
| 11:07:16 | bauzas | so I directly modified the version in the libvirt driver | |
| 11:07:54 | bauzas | after that, I had a problem (for the #2 exception) so I just rebased my git repo into a separate change | |
| 11:08:06 | bauzas | but then the min version was 3.4.0 again | |
| 11:08:39 | bauzas | so when looking at the inventory, it wasn't supporting mdevs, so the scheduler client tried to delete the inventory | |
| 11:08:47 | bauzas | hence the problem | |
| 11:08:50 | cdent | ah | |
| 11:09:02 | cdent | I can see how that would have been hard to uncover :( | |
| 11:09:38 | bauzas | the problem with VGPU resource classes is that we only use them if needed | |
| 11:10:07 | bauzas | so when you want to stop supporting it, then it would be problme | |
| 11:10:31 | bauzas | we don't have the other problem for other standard RCs | |
| 11:10:43 | bauzas | but it *could* be a problem later | |
| 11:10:52 | bauzas | at least with nested RPs | |
| 11:11:11 | bauzas | I totally understand why we provide that exception | |
| 11:11:23 | bauzas | but maybe it could be a confusion for operatoes | |
| 11:12:55 | cdent | I suspect we're going to find a lot if interesting bits of a confusion as we start using the stuff for real. Which I hope we can start doing sooner than later. | |
| 11:13:20 | bauzas | anyway, thanks for your help | |
| 11:13:51 | bauzas | I'm just punting my thoughts, just keeping it in my mind | |
| 11:14:16 | bauzas | food for thoughts, that's it | |
| 11:14:18 | jianghuaw_ | bauzas, understood. thanks for the sharing. | |
| 11:20:17 | mdbooth | bauzas: Is 'allocations' persisted anywhere? That is, can we recall it after spawn e.g. during live migration/reboot/rescue? | |
| 11:27:33 | bauzas | mdbooth: you mean where are persisted 'allocations' ? in the API DB | |
| 11:28:14 | bauzas | I'm just amazed to see a feature working with new inventory classes :è) | |
| 11:28:16 | bauzas | :-) | |
| 11:28:34 | bauzas | the era of tech debt is just behind us now, huzzah \o/ | |
| 11:28:48 | gibi | yjk_: I filed a bp about your notification ehancement https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications | |
| 11:28:59 | bauzas | PCIManager, trust me, you're going to have a bad day ! | |
| 11:31:55 | cdent | mdbooth: they are recalled during migration | |
| 11:57:54 | mdbooth | cdent: Do you have a pointer? | |
| 11:58:06 | cdent | mdbooth: yeah, just a sec | |
| 11:59:01 | mdbooth | locations = self.reportclient.get_allocations_for_consumer( | |
| 11:59:02 | mdbooth | instance.uuid) | |
| 11:59:02 | mdbooth | ^^^ ? | |
| 11:59:20 | mdbooth | s/locations/allocations/ | |
| 11:59:21 | cdent | I was thinking of https://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L129 | |
| 11:59:41 | cdent | which calls replace_allocation_with_migration | |
| 12:00:50 | mdbooth | cdent: Does an instance have 2 sets of allocations during a migration, btw? | |
| 12:01:24 | cdent | yes, but one of them is identified by the uuid of the migration (in queens). For a while there were two, both identified by the instance | |
| 12:01:46 | mdbooth | cdent: Thanks | |
| 12:23:21 | yjk | Hi gibi, I have opened an openstack bug. Please check https://bugs.launchpad.net/nova/+bug/1742674 | |
| 12:23:22 | openstack | Launchpad bug 1742674 in OpenStack Compute (nova) "[Newton] Nova notifications do not show the user which initiates the event." [Undecided,New] | |
| 12:29:03 | gibi | yjk: I think it needs to be handled as a new feature, hence the blueprint I opened | |
| 12:29:41 | gibi | yjk: if you have time to work on such a feature I can help you | |
| 12:33:44 | yjk | gibi: I though you had asked me to open an openstack bug. That is why opened a bug. | |
| 12:35:08 | gibi | yjk: yes, but then based on the code comment I realized that it was the original intention to send the owner's user_id | |
| 12:35:30 | gibi | yjk: so I think we should add a separate field for the user id of the user that called the action | |
| 12:35:42 | gibi | yjk: and that will be more like a new feature than a bugfix | |
| 12:36:35 | yjk | gibi: I though you had asked me to open an openstack bug. That is why opened a bug. | |
| 12:38:12 | gibi | yjk: yes, first I thought that it is a bug then I realzied that it is more like a new feature | |
| 12:38:17 | gibi | yjk: sorry for the confusion | |