| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-25 | |||
| 11:57:06 | aspiers | it's fine if it says "this is *probably* what happened" | |
| 11:57:12 | aspiers | if that's the most likely thing | |
| 11:57:16 | sean-k-mooney | then we can simply state we are skiping the arch and not say way | |
| 11:57:23 | sean-k-mooney | *why | |
| 11:57:36 | aspiers | if that's the most likely thing it's better to expose the guess | |
| 11:57:47 | aspiers | since that's potentially more helpful to the operator/dev than not guessing | |
| 11:57:52 | aspiers | as long as it's not misleading | |
| 11:57:54 | sean-k-mooney | e.g. Skipping arch: becasue libvirt raised an error, check you libvirt logs for more info | |
| 11:57:58 | aspiers | think of it from the operator perspective | |
| 11:58:08 | aspiers | no the libvirt logs might not reveal anything | |
| 11:58:11 | sean-k-mooney | aspiers: this is never ment to be read by operators | |
| 11:58:13 | aspiers | if it was incompatible | |
| 11:58:22 | sean-k-mooney | that is why its at debug level | |
| 11:58:29 | aspiers | if you don't believe operators read DEBUG you live in a different universe ... | |
| 11:58:31 | aspiers | :) | |
| 11:58:42 | sean-k-mooney | they might but this is not intened for them | |
| 11:58:49 | aspiers | anyway it doesn't matter who is reading it | |
| 11:58:58 | sean-k-mooney | are you ok with the message i suggested above | |
| 11:59:00 | aspiers | the point is that the message needs to be a) not misleading b) as helpful as possible | |
| 11:59:30 | aspiers | OK I will paste a suggested message here, 1 sec | |
| 11:59:58 | sean-k-mooney | "Skipping arch: %s becasue libvirt raised an error, check you libvirt logs for more info." | |
| 12:00:03 | aspiers | nope | |
| 12:00:11 | aspiers | like I said libvirt logs might not help | |
| 12:00:32 | aspiers | and in this case we know we might be able to help by guessing the likely cause | |
| 12:00:49 | sean-k-mooney | you said you dont want it to be missleading | |
| 12:00:57 | aspiers | yes that is a) | |
| 12:01:01 | aspiers | but also b) | |
| 12:01:28 | sean-k-mooney | the current error message is our best guess at why the error was raised | |
| 12:01:41 | aspiers | Yes but it's not honest that it's a guess | |
| 12:01:48 | aspiers | This is better: "Failed to retrieve domain caps from libvirt for arch %s; maybe incompatible with virt_type %s / machine_type %s?" | |
| 12:02:04 | sean-k-mooney | it is honest it was a summary of the error message | |
| 12:02:15 | sean-k-mooney | we could just print the error message we get back from libvirt | |
| 12:02:31 | aspiers | Yes good idea | |
| 12:02:52 | aspiers | This is better: "Failed to retrieve domain caps from libvirt for arch %(arch)s (%(error)s); maybe incompatible with virt_type %(virt_type)s / machine_type %(mach_type)s?" | |
| 12:02:55 | sean-k-mooney | i wanted to avoid the stack trace but we should be able to just get the message | |
| 12:03:09 | aspiers | that last one includes the libvirt error message ^^^ | |
| 12:03:34 | sean-k-mooney | i would not put the error in the middel | |
| 12:03:38 | sean-k-mooney | i would put it at the end | |
| 12:04:02 | sean-k-mooney | i guess its not that long | |
| 12:04:04 | sean-k-mooney | http://paste.openstack.org/show/754776/ | |
| 12:04:14 | sean-k-mooney | its invalid argument: KVM is not supported by '/usr/bin/qemu-system-alpha' on this host | |
| 12:04:38 | sean-k-mooney | at least in the case where the virt type is the issue | |
| 12:04:48 | aspiers | OK good point | |
| 12:05:19 | aspiers | "Failed to retrieve domain caps from libvirt for arch %(arch)s; maybe incompatible with virt_type %(virt_type)s / machine_type %(mach_type)s? libvirt error was: %(error)s" | |
| 12:05:34 | sean-k-mooney | ya im fine with that | |
| 12:05:37 | aspiers | or actually | |
| 12:05:47 | aspiers | since the libvirt error is already helpful enough | |
| 12:06:04 | aspiers | "Failed to retrieve domain caps from libvirt for arch %(arch)s / virt_type %(virt_type)s / machine_type %(mach_type)s; libvirt error was: %(error)s" | |
| 12:06:26 | sean-k-mooney | sure we dont need to make it a question | |
| 12:06:38 | sean-k-mooney | since the lbvirt error states what the issue was | |
| 12:07:11 | kashyap | aspiers: Can't we do a check to determine the arch to 'virt_type' compatibility? | |
| 12:07:22 | sean-k-mooney | no | |
| 12:07:24 | aspiers | sean-k-mooney: exactly, I removed the question mark | |
| 12:07:26 | sean-k-mooney | that is libvirt job | |
| 12:07:32 | aspiers | kashyap: I agree with sean-k-mooney here | |
| 12:07:46 | aspiers | nova shouldn't know about that | |
| 12:07:50 | kashyap | sean-k-mooney: I meant, _using_ libvirt's reported results, of course | |
| 12:07:56 | kashyap | aspiers: Yeah, just thinking out loud | |
| 12:08:04 | kashyap | I agree that Nova sholdn't know about it | |
| 12:08:11 | sean-k-mooney | right if kvm ever adds support for accleration of non ntaive instruction i dont want to need to modify nova | |
| 12:08:20 | aspiers | so nova is not checking compatibility, it's just trying to get dom caps | |
| 12:08:32 | kashyap | aspiers: typo: "caps" --> "capabilities" | |
| 12:08:37 | aspiers | if that fails we report the error from libvirt plus details of the API parameters | |
| 12:08:49 | aspiers | kashyap: my wrists hurt so I am trying to reduce typing :-p | |
| 12:08:59 | aspiers | typos in IRC are allowed! | |
| 12:09:01 | aspiers | just not in code | |
| 12:09:02 | kashyap | aspiers: No-no, in the _error_ message I mean | |
| 12:09:07 | aspiers | oh :) | |
| 12:09:12 | aspiers | ok sure | |
| 12:09:18 | kashyap | Of course, it's fine here ;-) I'm not _that_ pedantic | |
| 12:09:22 | aspiers | "Failed to retrieve domain capabilities from libvirt for arch %(arch)s / virt_type %(virt_type)s / machine_type %(mach_type)s; libvirt error was: %(error)s" | |
| 12:09:37 | kashyap | aspiers: Yes, sounds clear and truthful | |
| 12:09:42 | aspiers | kashyap: haha well I am sometimes so I wasn't ruling out that you might be too ;-) | |
| 12:09:44 | sean-k-mooney | ya that looks fine | |
| 12:09:57 | aspiers | sean-k-mooney: OK want me to change it or you? | |
| 12:10:06 | sean-k-mooney | sure | |
| 12:10:14 | sean-k-mooney | i am about to grab lunch | |
| 12:10:16 | aspiers | sure == me? :) | |
| 12:10:20 | aspiers | OK | |
| 12:10:23 | aspiers | before you go | |
| 12:10:24 | sean-k-mooney | if you havent by the time i get back ill do it | |
| 12:10:27 | aspiers | I have some semi-exciting news | |
| 12:10:31 | aspiers | check this out | |
| 12:10:33 | sean-k-mooney | oh? | |
| 12:10:40 | aspiers | Jul 25 01:29:37 della5s17 nova-compute[6543]: DEBUG nova.scheduler.client.report [None req-ce6afb17-2d5f-489a-bfda-667053513883 None None] Inventory has not changed for provider 54d4029e-c36b-4bd3-b922-ab4cdefba128 based on inventory data: {u'VCPU': {u'allocation_ratio': 16.0, u'total': 128, u'reserved': 0, u'step_size': 1, u'min_unit': 1, u'max_unit': 128}, u'MEMORY_MB': {u'allocation_ratio': 1.5, | |
| 12:10:42 | aspiers | u'total': 128452, u'reserved': 512, u'step_size': 1, u'min_unit': 1, u'max_unit': 128452}, u'DISK_GB': {u'allocation_ratio': 1.0, u'total': 95, u'reserved': 0, u'step_size': 1, u'min_unit': 1, u'max_unit': 95}, u'MEM_ENCRYPTION_CONTEXT': {u'allocation_ratio': 1.0, u'total': 2147483647, u'reserved': 0, u'step_size': 1, u'min_unit': 1, u'max_unit': 2147483647}} {{(pid=6543) set_inventory_for_provider | |
| 12:10:44 | aspiers | /opt/stack/nova/nova/scheduler/client/report.py:912}} | |
| 12:10:46 | aspiers | oops, sorry for linebreaks | |
| 12:10:50 | aspiers | that's from a real SEV system | |
| 12:11:03 | aspiers | total is "infinite" cos I didn't configure the nova.conf option yet | |
| 12:11:11 | aspiers | I'm gonna set to 16 now | |
| 12:11:16 | sean-k-mooney | cool | |
| 12:11:32 | kashyap | aspiers: Hehe | |
| 12:11:53 | sean-k-mooney | i also reached a milestone yesterday where i fully tested the vPMU feature and image metadata prefilter stuff i have been working on | |
| 12:12:10 | aspiers | nice! | |
| 12:12:12 | aspiers | also | |
| 12:12:15 | aspiers | Jul 25 01:24:29 della5s17 nova-compute[6543]: DEBUG nova.scheduler.client.report [None req-ce6afb17-2d5f-489a-bfda-667053513883 None None] Refreshing trait associations for resource provider 54d4029e-c36b-4bd3-b922-ab4cdefba128, traits: | |
| 12:12:16 | aspiers | HW_CPU_X86_SSE,COMPUTE_IMAGE_TYPE_ISO,COMPUTE_NET_ATTACH_INTERFACE,COMPUTE_NET_ATTACH_INTERFACE_WITH_TAG,HW_CPU_X86_AMD_SEV,COMPUTE_IMAGE_TYPE_AKI,COMPUTE_IMAGE_TYPE_ARI,COMPUTE_IMAGE_TYPE_QCOW2,COMPUTE_TRUSTED_CERTS,HW_CPU_X86_SVM,COMPUTE_DEVICE_TAGGING,COMPUTE_VOLUME_ATTACH_WITH_TAG,COMPUTE_VOLUME_MULTI_ATTACH,HW_CPU_X86_SSE2,COMPUTE_IMAGE_TYPE_AMI,COMPUTE_VOLUME_EXTEND,HW_CPU_X86_MMX,COMPUTE_IMAGE_ | |
| 12:12:18 | aspiers | TYPE_RAW {{(pid=6543) _refresh_associations /opt/stack/nova/nova/scheduler/client/report.py:796}} | |
| 12:12:18 | sean-k-mooney | it was really nice to see the traits showing up in placmenet for the prefilter and the transform happening | |