Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-11
08:22:17 ameeda I found this error "ComputeHostNotFound: Compute host undercloud could not be found." in nova-compute.log
08:31:36 maciejjozefczyk ameeda: It shoudl be quite similiar to https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1554631.py
08:31:49 maciejjozefczyk about functional regression test
08:32:11 ameeda maciejjozefczyk: thanks you very much. I will check it now
08:32:47 maciejjozefczyk ameeda: I mean you need some mocking and it could be possible to check if the field is not truncated
08:33:57 ameeda maciejjozefczyk: the problem is that I am beginner with openstack and also I never write regression code, I will do my best to do that
08:34:31 maciejjozefczyk ameeda: I've never written any regression test also :D
08:34:50 maciejjozefczyk ameeda: about second question; check scheduler logs
08:35:04 ameeda maciejjozefczyk: great :D
08:35:14 ameeda maciejjozefczyk: let me check it now
08:35:38 maciejjozefczyk ameeda: Do understand it well I recommend to move log_level to debug and then restart scheduler; you'll find which filter removes the host from list
08:37:56 ameeda let me see how to change log_level :$
08:48:54 openstackgerrit Silvan Kaiser proposed openstack/nova master: Added mount fstype based validation of Quobyte mounts https://review.openstack.org/522245
08:56:13 maciejjozefczyk ameeda: /etc/nova/nova.conf - add debug=True
08:57:32 ameeda maciejjozefczyk: yes I did that, and I restart the services and I need to empty log files contents
09:01:43 bauzas good morning Novaers
09:01:57 ameeda Morning :)
09:02:10 ameeda maciejjozefczyk: I will start openstack deploy.
09:13:30 kashyap mdbooth: Hi, when you're about: Given this — https://review.openstack.org/#/c/505673/ (which adds the '--force-share' option to Nova Git master). For operators that are running already released version (e.g. Pike), updating to QEMU 2.10, would there be any impact?
09:13:54 kashyap Or we'd be expecting them to _not_ upgrade as each Nova release comes with its specific version cap of libvirt & QEMU?
09:16:58 kashyap Oh, it's actually cherry-picked to Pike
09:18:55 kashyap But not to Ocata (because it's in Phase-II).
09:31:52 mdbooth kashyap: I suspect there would be an impact.
09:32:13 mdbooth I think downstreams will have to backport that as required.
09:32:22 kashyap mdbooth: Yeah, was thinking so. So for Ocata and Newton users (https://releases.openstack.org/) who upgrade to 2.10 QEMU will see problems
09:32:25 kashyap Yeah
09:32:37 mdbooth kashyap: Yep.
09:32:51 kashyap The Pike backport was already done to alleviate an Ubuntu user running 2.10 -- https://review.openstack.org/#/c/509774/
09:36:37 redondo-mk Morning. Question...does anyone know some fast/simple way to estimate available capacity in terms of number of instances if you want to estimate that for specific flavor?
10:06:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Default some flavor fields loaded from instance https://review.openstack.org/529194
10:07:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Default some flavor fields loaded from instance https://review.openstack.org/529194
10:12:16 yjk_ Hi, I am currently on Newton release. (I am new to openstack) I am facing the following issue: - Event notifications generated by nova do not show the actual user who initiated the event. It rather shows the VM/object owner. For Example, If a "test-tenant" has two users an admin "test-admin" and a SSO user "test-ssu". If "test-admin" reboots a VM created by "test-ssu", event notification shows "test-admin" rather than "tes
10:12:35 yjk_ This I believe is because while generating the event notification payload, information from instance is used instead of context information. Code wise, in this line https://github.com/openstack/nova/blob/808d36475103e373f1deb3344b6829ce68d6cdd5/nova/notifications/base.py#L432 Here we use: user_id=instance.user_id Should'nt we use, user that has come from context, something like user_id=context.user_id Just wanted to know co
10:16:07 bauzas mmm, I'm slapped by an InventoryInUse exception when I start testing VGPU allocations
10:16:20 bauzas jianghuaw_: have you faced the same ?
10:16:20 gibi yjk_: interesting finding.
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 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: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: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 purplerbot <bauzas> cdent is off, edleafe, jaypipes and efried aren't there yet [2018-01-11 10:21:54.269899] [n 3csz]
11:03:17 cdent bauzas: I'm here now (re [t 3csz] ). What's up?
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

Earlier   Later