Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-07
15:01:19 efried thx
15:01:59 jaypipes efried: one other nice thing about NoDBTestCase is that if any of the test code *does* touch the DB, there is a poison fixture that will blow up, telling the developer that they are stating the test code doesn't touch the DB, but in fact, does touch the DB.
15:02:29 efried jaypipes I really *hope* our virt driver code doesn't touch the DB directly.
15:02:47 jaypipes efried: every once in a while, that poison fixture has been a friend to me identifying places where I had no idea we were touching the DB ;)
15:02:48 efried Though actually I think I saw a case of it the other day...
15:04:04 efried jaypipes https://review.openstack.org/#/c/422512/25/nova/virt/powervm/tasks/network.py@155 <= that's a DB touch, nah?
15:04:18 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: config drive https://review.openstack.org/409404
15:04:24 esberglu jaypipes: Done. tx
15:04:32 jaypipes efried: yes, it is. :)
15:05:22 jaypipes esberglu: cool, thanks.
15:10:29 jaypipes alex_xu: you around?
15:10:35 snasir Hi, was hoping if anyone could kindly help me understand how does nova differentiate between a baremetal instance vs a VM when launched with nova boot ? Is it the scheduler filters that determine that or is it the scheduler_host_manager ? Thanks
15:11:05 jaypipes alex_xu: I'm sorry, but I'm not understanding which comment you are referring to in your last review response on https://review.openstack.org/#/c/516778/. Could you elaborate please? Thanks!
15:25:21 jaypipes snasir: good question. there is a property on the image called hypervisor_type='baremetal' that will trigger the ironic host manager to pick the Ironic baremetal node to deploy to.
15:27:45 snasir javpipes: Oh so does that mean, that I can deploy baremetal nodes even if i dont set scheduler_host_manager=ironic_host_manager ? Is the regular host_manager smart to determine that
15:28:08 snasir jaypipes: Oh so does that mean, that I can deploy baremetal nodes even if i dont set scheduler_host_manager=ironic_host_manager ? Is the regular host_manager smart to determine that
15:28:37 jaypipes snasir: no, you still need to do the ironic_host_manager thing unfortunately. it's a giant mess.
15:29:42 jaypipes snasir: I don't know why it's still like that :(
15:30:01 jaypipes snasir: we really should just remove the ironic_host_manager entirely, IMHO
15:30:30 snasir jaypipes: Ok Basically I'm trying to figure out if I can share nova services to spawn both BM nodes and VMs. I know I have to have two nova-computes running (with their respective drivers), and looks like I'll need two nova-schedulers running too with their respective host_managers... Am i correct in saying that ?
15:34:29 jaypipes snasir: I believe so, yes.
15:34:58 jaypipes snasir: though I would point you to Ironic operators to get a definitive answer on that.
15:35:05 jaypipes snasir: of course, most are in Sydney :)
15:35:25 jaypipes snasir: so probably a good idea to post to the openstack@ or openstack-operators@ mailing list.
15:36:05 jaypipes snasir: I'm particularly thinking of James Penick as a possible resource for you. Usually he's on IRC as "penick", but he's in Sydney this week.
15:38:06 openstackgerrit Surya Seetharaman proposed openstack/nova master: instance_mapping/request_spec records exist even after the instances are archived https://review.openstack.org/515034
15:38:09 snasir jaypipes: I tried asking on the Ironic IRC, but couldn't get a definite answer....Thanks I'll post on @openstack.. Its too early in Sydney atm :)
15:38:21 jaypipes snasir: too late :)
15:38:43 snasir jaypipes: lol, yeah too late i meant, haha
15:47:31 efried jaypipes FYI, repeat performance at the dentist. Back in 60-90m
16:32:42 openstackgerrit C Leavett-Brown proposed openstack/nova master: Modify nova routing table to process null requests https://review.openstack.org/518119
16:34:58 jmlowe jaypipes: you around?
16:35:10 jaypipes jmlowe: I am indeed. :)
16:36:03 jmlowe My knee jerk reaction is to just add a second test to the test_update_volume_xml unit test but I suspect that isn't the right thing to do
16:36:32 jaypipes jmlowe: I think your knee-jerk reaction is good. :)
16:37:09 jaypipes jmlowe: just make sure you put a little code comment in the test saying basically "make sure we don't change the disk device address if we're live migrating"...
16:38:10 jmlowe ok, I think I have all the stuff from a live broken one, will cover virtio-scsi and rbd not just virtio-block and iscsi once I'm done
16:39:27 jmlowe not sure my reply to your comment actually made it in there, changing a device address during cold migration is bad but doesn't cause a fatal error for the operator just the user of the vm
16:40:41 jaypipes gotcha
17:18:00 jmlowe here goes, my confidence in the unit test is a little shaky
17:18:05 openstackgerrit Mike Lowe proposed openstack/nova master: live-mig: keep disk device address same https://review.openstack.org/518022
17:46:20 efried jaypipes Here's an interesting bug. I haven't fully nailed it down yet, but I think it works like this:
17:47:05 efried My non-sharing RP has one resource class. My sharing RP has three, including the same one as the non-sharing RP. I ask for all three. The candidates I get back are all effed up.
17:48:15 efried I get back three candidates. One of them is the common RC plus *one* of the others; and one of them is similar but with the *other* non-common RC (that is, two of the candidates come back with only two out of the three requested RCs)
17:48:46 efried The third candidate is the one you would expect: all three resources from the RP that has all three.
17:49:29 efried Now, I know this represents a couple things we don't support. But it seems to point to a flaw in the logic somewhere that should *never* be allowing a candidate that doesn't have all the requested resources.
17:58:41 jaypipes efried: correct. an allocation request should always contain all of the requested resources, provided by one or more resource providers.
17:59:16 efried jaypipes I'll write up a specific test case. Though it'll be pretty weird from a non-sharing-RP-is-always-the-compute-node perspective.
18:00:12 openstackgerrit Eric Fried proposed openstack/nova master: Test alloc candidates with same RC in cn & shared https://review.openstack.org/513149
18:00:46 jaypipes efried: l
18:00:49 jaypipes efried: k
18:03:42 efried jaypipes Actually, I think I was in a situation where both of the RPs were marked as sharing. (And there would be no non-sharing RPs anywhere in the db)
18:05:26 jaypipes efried: in that case, if there were no non-sharing resource providers, there should be allocation request results.
18:05:51 efried jaypipes *no* allocation request results?
18:06:39 jaypipes efried: correct. allocation requests must contain at least one non-sharing provider.
18:07:00 jaypipes efried: because you can't send a boot request to a shared storage provider...
18:07:01 efried jaypipes So I suspect some of the stuff you did in the refactor will "fix" this. I'll write it up and confirm.
18:07:14 jaypipes k
18:07:26 efried jaypipes Well, again, that's assuming we're coming out of GET /allocation_candidates wanting to do a boot :)
18:07:49 jaypipes efried: yes, that is a basic assumption of GET /allocation_candidates right now.
18:07:54 efried ack
18:08:22 openstackgerrit Eric Fried proposed openstack/nova master: Test alloc candidates with same RC in cn & shared https://review.openstack.org/513149
18:19:06 efried jaypipes Interesting. So before the refactor stack, the results are as I stated above - we have three candidates where two of them don't even have all the resources.
18:19:34 efried jaypipes After the refactor stack, the result is: we get two candidates. One has all the resources from the one RP; the other has the common resource from the other RP and the non-common resources from the first RP.
18:19:42 efried jaypipes Which is in fact how I think it *should* work - but is still "wrong" per your assertion that we should get back no results.
18:20:58 efried Soooo... I'll open a bug and comment the hell out of the test case I guess?
18:26:10 efried Dude, I added a compute RP providing one of the other resources and got back exactly the four candidates I would expect. IMO this ain't broke and we shouldn't fix it.
18:27:04 efried The compute-as-non-sharing-RP limitation will be imposed by the modeling from compute-ish consumers of placement, and shouldn't be imposed by placement itself.
19:05:43 openstackgerrit Mike Lowe proposed openstack/nova master: live-mig: keep disk device address same https://review.openstack.org/518022
19:09:12 openstackgerrit Eric Fried proposed openstack/nova master: Test allocation_candidates with only sharing RPs https://review.openstack.org/518382
19:09:18 efried jaypipes ^ thar she blows.
19:09:28 efried I got a cool bug number: 1730730
19:53:46 openstackgerrit C Leavett-Brown proposed openstack/nova master: Modify nova routing table to process null requests https://review.openstack.org/518119
19:56:56 snasir Hi, is it possible to have 2 nova-schedulers running on the same host ? One to manage baremetal nodes while the other for VMs? Can nova-api figure out which one is for what purpose if that is the case ? Thanks
20:22:27 efried jaypipes If I ask for _get_provider_ids_having_all_traits() with an empty trait list, I ought to get back... all the RPs, right?
20:32:01 efried jaypipes Okay, I see the above is accounted for by the caller. But that method is still broken for RPs that don't have any traits.
20:36:41 efried ...which again isn't a problem if it's never invoked with no traits.
20:36:45 efried Ignore me.
20:45:12 jmlowe let me ask something, should the resource_classes table in my placement db be empty?
20:46:18 efried jmlowe No
20:46:30 efried jmlowe It ought to have at least the standard classes in it.
20:46:35 efried jmlowe Wait, what version?
20:46:42 jmlowe ocata
20:46:49 efried ah. Don't know, then.
20:47:32 jmlowe I keep seeing things get way overcommitted, guessing it's trying to look up the allocations but doesn't find anything due to joining by name
20:48:50 efried jmlowe Based on https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/custom-resource-classes.html I would expect you should see the standard resource classes even in ocata.
20:48:58 jmlowe I'm guessing I can probably just create the three rows by hand if I could figure out the right name for mem cpu and disk
20:49:14 efried MEMORY_MB, VCPU, DISK_GB
20:49:20 efried But it's worrisome that those aren't there.
21:07:27 snasir Hi, I'm running into this error with nova-compute when i try to spawn baremetal nodes with nova-compute , "ERROR nova.compute.monitors.vswitch.vswitch_monitor [req-d9990173-da78-42b0-b2e7-911166c4c2f6 - - - - -] Could not get: http://localhost:9000/v1/engine/stats, error=HTTPConnectionPool"
21:07:58 snasir Can anybody tell me how to bypass or resolve this ? Is there some setting in nova.conf, that can prevent this vswitch check ? Thanks
21:31:48 mriedem andreas_s: can you disable zkvm CI from running on stable/newton changes?
21:40:37 efried jaypipes Do you have local changes to the refactor series?
21:41:27 efried jaypipes I'd like to add tests to https://review.openstack.org/#/c/517027/
21:43:47 jaypipes efried: go for it. I don't have any local changes.
21:53:35 openstackgerrit Eric Fried proposed openstack/nova master: required traits for no sharing providers https://review.openstack.org/517027
21:53:35 openstackgerrit Eric Fried proposed openstack/nova master: Add ProviderSummary.resource_class_names @property https://review.openstack.org/517646
21:53:36 openstackgerrit Eric Fried proposed openstack/nova master: handle traits with sharing providers https://review.openstack.org/517119
21:53:39 efried jaypipes Okay, added tests on both https://review.openstack.org/#/c/517027/ and https://review.openstack.org/#/c/517119/
21:53:55 efried jaypipes Also fixed alex_xu's nit on the former.

Earlier   Later