| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-17 | |||
| 15:43:42 | cfriesen | kashyap: what would you think of https://review.openstack.org/#/c/461456 ? The rationale being that it's defined as a realtime mask so if the user specifies "1-2" they should get vCPUs 1 and 2 as realtime. | |
| 15:45:41 | sfinucan | cfriesen: I took a look at it. Looks sensible to me. Do we document support image metadata anywhere though? | |
| 15:45:47 | sfinucan | ...or is that up to Glance to do? | |
| 15:47:40 | sfinucan | dansmith: RE: https://review.openstack.org/#/c/408242/, what would be the preferred pattern - | |
| 15:48:03 | sfinucan | hardening all the access to various InstanceNUMACell attributes to check if the attribute is set first | |
| 15:48:09 | johnthetubaguy | sfinucan: did you see the image meta object stuff? | |
| 15:48:23 | sfinucan | or always setting those attributes anywhere we create an object? | |
| 15:48:25 | johnthetubaguy | sfinucan: we should probably generate docs from that at some point | |
| 15:48:38 | cfriesen | sfinucan: not actually sure | |
| 15:48:39 | sfinucan | johnthetubaguy: To which "stuff" do you refer? :) | |
| 15:49:01 | johnthetubaguy | sfinucan: https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py | |
| 15:49:38 | sfinucan | johnthetubaguy: Oh, yeah - I knew where that was defined, alright. I meant docs that you don't need to read the code for :) | |
| 15:50:22 | johnthetubaguy | sfinucan: we should generate some docs off that I think, I suspect a few have got into the admin guides, but unsure on the details there | |
| 15:50:39 | cfriesen | sfinucane: glance has this https://docs.openstack.org/developer/glance/common-image-properties.html but there's not much there | |
| 15:50:40 | johnthetubaguy | sfinucan: its better than extra specs though... | |
| 15:51:25 | cfriesen | sfinucan: johnthetubaguy: image_meta.py just says "CPU mask indicates which vCPUs will have realtime enable" which doesn't really match the current code (hence my patch) | |
| 15:51:41 | dansmith | sfinucan: what do you mean? those patches do the right thing.. we merged one already right? | |
| 15:51:51 | openstackgerrit | Daniel Gonzalez Nothnagel proposed openstack/nova master: WIP: Get disk size of instance in separate process https://review.openstack.org/465653 | |
| 15:52:03 | sfinucan | johnthetubaguy: I'll go look for stuff now. Admin guide seems like the correct place to put them, even though we're going to move that into nova soon | |
| 15:52:55 | sfinucan | dansmith: Aye, but those patches that merged mix the two. https://review.openstack.org/gitweb?p=openstack/nova.git;a=commitdiff;h=99f3bbc1ac7ddcde36931f590b6df3811e596d8c | |
| 15:53:32 | sfinucan | dansmith: So in some cases, we've done "if ('key' in object) and object.key:" | |
| 15:53:52 | sfinucan | ...but in others, we just set the various fields to None in the tests, sidestepping the issue | |
| 15:54:15 | dansmith | sfinucan: being defensive in the code that uses those fields is the wy | |
| 15:54:17 | dansmith | *way | |
| 15:54:33 | sfinucan | OK, I'll do that so | |
| 15:54:36 | dansmith | sfinucan: i.e. the "if foo in obj and obj.foo | |
| 15:54:43 | dansmith | sfinucan: cool, thanks for picking those back up | |
| 15:54:51 | sfinucan | dansmith: no problemo | |
| 16:05:47 | mriedem_afk | rabel_b1: you can have global default quotas (limits), project-specific default quotas, and then just project-specific quotas, and i understand that the latter two are confusing, and i'm not sure if/how we treat them differently, unless you have default project limits and user-specific limits within that project | |
| 16:06:22 | mriedem | mkoderer: dgonzalez: so anytime anything hits https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7025 in the compute it locks up the entire process? | |
| 16:06:41 | mriedem | mkoderer: dgonzalez: because that method is called from a few different operations | |
| 16:08:48 | rabel_b1 | mriedem: ok, thank you very much. | |
| 16:09:36 | mriedem | dgonzalez: ah i see your patch now | |
| 16:43:59 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged nic attachment https://review.openstack.org/415622 | |
| 16:44:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete nic metadata when detaching interface https://review.openstack.org/435387 | |
| 16:44:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged volume attachment https://review.openstack.org/418100 | |
| 16:44:08 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete disk metadata when detaching volume https://review.openstack.org/435082 | |
| 16:44:15 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged volume attachment https://review.openstack.org/391941 | |
| 16:44:16 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021 | |
| 16:44:29 | openstackgerrit | sean mooney proposed openstack/nova master: do not set vcpu_pin elements when virt_type=qemu https://review.openstack.org/465160 | |
| 16:47:15 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged nic attachment https://review.openstack.org/415622 | |
| 16:47:17 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete nic metadata when detaching interface https://review.openstack.org/435387 | |
| 16:47:19 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged volume attachment https://review.openstack.org/418100 | |
| 16:47:24 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete disk metadata when detaching volume https://review.openstack.org/435082 | |
| 16:47:31 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged volume attachment https://review.openstack.org/391941 | |
| 16:47:32 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021 | |
| 16:47:36 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged nic attachment https://review.openstack.org/415520 | |
| 17:04:23 | cfriesen | where does ServerExternalEvents run? is this part of nova-api? | |
| 17:05:43 | cfriesen | bah, never mind, just noticed the full path to the file | |
| 17:11:37 | openstackgerrit | Matthew Booth proposed openstack/nova master: Add a method signature test for all virt drivers https://review.openstack.org/465676 | |
| 17:12:26 | mdbooth | Honestly I was expecting that to find things. Surprised it didn't. | |
| 17:14:15 | mdbooth | lyarwood: Added ^^^ when I noticed your change to swap_volume, also your previous reluctance to change detach_volume. This test should make those things easier. | |
| 17:20:15 | artom | mdbooth, I thought we already tested virt drivers's method signatures... Were some drivers missing from the list? | |
| 17:22:08 | mdbooth | artom: Where do we test it? | |
| 17:22:28 | mdbooth | Although that would explain why they all match :) | |
| 17:22:46 | artom | mdbooth, ah, I think they're individual tests in each driver | |
| 17:23:05 | artom | http://paste.openstack.org/show/609828/ | |
| 17:23:14 | artom | I know I remembered getting method signature errors | |
| 17:25:43 | mdbooth | That's incredibly similar to mine, except not recursive | |
| 17:25:52 | mdbooth | I needed recursive for the volume drivers | |
| 17:26:04 | mdbooth | Although I hadn't noticed that existed already | |
| 17:26:31 | mdbooth | I wonder why it doesn't have to handle wrapped methods | |
| 17:28:41 | artom | mdbooth, I agree your way is better - it doesn't depend on each driver doing their own tests correctly | |
| 17:28:52 | mdbooth | Ah... HyperV munges it. | |
| 17:29:09 | mdbooth | artom: Meh, it's only important that it's checked, tbh. | |
| 17:29:44 | artom | mdbooth, I suppose the only issue with the current tests is if a new virt driver gets added and forgets them | |
| 17:29:48 | artom | But that doesn't seem likely | |
| 17:30:12 | mdbooth | Well powervm.PowerVMDriver already wasn't added to the DriverMethodTestCase | |
| 17:30:13 | artom | Also, you've included PowerVM | |
| 17:30:17 | mdbooth | Although that case is stupid | |
| 17:30:23 | artom | Which isn't in the list I got | |
| 17:32:05 | mdbooth | artom: Can you note on the review that we already do that? I'll probably abandon it, and/or update my recursive test to use the existing method. | |
| 17:32:38 | artom | mdbooth, sure | |
| 17:32:45 | mdbooth | artom: Thanks | |
| 17:35:43 | artom | mdbooth, there. I didn't even -1 it ;) | |
| 17:38:52 | mriedem | cfriesen: did you happen to catch the sriov bug armax was asking about last night? | |
| 17:40:28 | armax | mriedem: btw talking to gyee_ it seems the issue happens in Newton still | |
| 17:43:56 | gyee_ | I am curious why we are using NopClaim if host is specified https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2771 | |
| 17:44:21 | gyee_ | does specifying a host implies force evacuate? | |
| 17:49:07 | gyee_ | meanwhile if SR-IOV is enabled, we are trying to get the PCI mapping via the migration context, which is only populated at rebuild_claim. https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2462 | |
| 17:51:31 | mriedem | https://github.com/openstack/nova/commit/dc0221d7240326a2d1b467e2a367bebb7e764e61 added that code in the compute manager about the nop claim, which implies resources were already claimed, but i'd have to dig into that | |
| 17:56:36 | mriedem | yikes, that was part of a big series https://review.openstack.org/#/q/topic:bug/1417667 | |
| 17:57:37 | gyee_ | but I don't see where the resource is being claimed, if the host is specified | |
| 17:57:53 | openstackgerrit | Gage Hugo proposed openstack/nova master: Admin API Policy contingent on is_admin_project https://review.openstack.org/384148 | |
| 17:58:00 | mriedem | gyee_: i'm also looking for that | |
| 18:03:50 | gyee_ | mriedem: I don't think that's being done. The migration_context in instance_extra table is empty if host specified, regardless if SR-IOV is enabled or not | |
| 18:06:21 | mriedem | gyee_: as far as i can tell, the only way to get the noop claim is if the user specifies the host and --force | |
| 18:07:01 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4115 | |
| 18:07:20 | mriedem | if the host is specified but force is not, then the api nulls out host when calling conductor | |
| 18:07:39 | gyee_ | I didn't use the --force option. Just merely specifying the host. | |
| 18:07:54 | mriedem | which gets to this else block https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L751 | |
| 18:08:08 | mriedem | node would eventually be set here https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L770 | |
| 18:08:15 | mriedem | and passed to compute as scheduled_node | |
| 18:08:43 | mriedem | which should get the rebuild_claim here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2769 | |
| 18:08:56 | mriedem | dansmith: do you remember anything about not doing a claim if the host is forced during evacuate? | |
| 18:09:41 | dansmith | mriedem: no | |
| 18:10:01 | dansmith | mriedem: I would think you'd get a new claim on the new compute node, and then drop the old one when the dead compute comes up a deletes the old instance | |
| 18:12:01 | mriedem | i'm not sure why we have this then https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2771 | |
| 18:12:31 | dansmith | mriedem: well for a regular rebuild | |
| 18:12:46 | mriedem | oh...yeah | |