| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-25 | |||
| 20:28:05 | dansmith | I would hope that details would be the same for both | |
| 20:28:11 | dansmith | based on the internals | |
| 20:28:16 | mriedem | it's not | |
| 20:28:25 | dansmith | no, I mean, between this and my patch | |
| 20:28:32 | dansmith | mriedem: you won' | |
| 20:28:41 | dansmith | mriedem: you won't have two cells in your test with my patch right? | |
| 20:29:36 | mriedem | correct, just cell0 and cell1 | |
| 20:29:36 | dansmith | mriedem: something you might try to do is create 500 active and 500 that fail to schedule so you get them in cell0 and cell1 | |
| 20:29:40 | dansmith | and the compare those numbers | |
| 20:30:17 | mriedem | not sure how easy it would be to get them to fail to schedule w/o hacking the scheduler to just raise NoValidHost | |
| 20:30:27 | mriedem | not that that is hard | |
| 20:30:44 | dansmith | mriedem: you could create a flavor that has a billion vcpus or something right? | |
| 20:31:12 | mriedem | fake driver and noop quota driver | |
| 20:31:19 | mriedem | so i don't think that would matter | |
| 20:31:49 | mriedem | and w/o the core/ram/disk filter we don't check limits in the compute claim | |
| 20:32:05 | mriedem | although that woudn't help since then they'd be in the cell1 db | |
| 20:32:18 | mriedem | i could just stop nova-scheduler :) | |
| 20:36:12 | dansmith | mriedem: more vcpus than the compute has will make it fail | |
| 20:36:39 | dansmith | I'm just saying, I expect we might see a performance _gain_ with my stuff if you can arrange to have some instances in cell0 | |
| 20:36:50 | mriedem | true | |
| 20:36:52 | dansmith | on top of the correctness thing, since right now cell0 always sorts above | |
| 20:37:09 | mriedem | vcpus = 1000 is what's in the fake driver, so yeah | |
| 20:37:25 | mriedem | i'll create a flavor with 2000 CPUs | |
| 20:37:36 | mriedem | would need to delete 500 of these and then archive them | |
| 20:38:12 | dansmith | mriedem: remember the overcommit value | |
| 20:38:29 | dansmith | if you haven't set that then, 16x | |
| 20:39:50 | mriedem | so flavor-create -vcpu 32000 mainframe | |
| 20:39:51 | mriedem | got it | |
| 20:39:58 | dansmith | haha | |
| 20:40:13 | mriedem | it's for my HPC flavor | |
| 20:40:23 | openstackgerrit | Eric Fried proposed openstack/nova master: Get auth from context for glance endpoint https://review.openstack.org/490057 | |
| 20:41:50 | mriedem | 8.55s average for GET /servers/detail | |
| 20:41:58 | mriedem | so nearly double | |
| 20:42:47 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_certificates to REST API https://review.openstack.org/486204 | |
| 20:42:52 | dansmith | tbh, I'm surprised it's not worse than that given what I know of the internals | |
| 20:44:01 | mriedem | that reminds me of a thread i meant to pull at one point, but i thought based on microversion we could be lazy-loading other things in the server view | |
| 20:44:05 | mriedem | like tags | |
| 20:44:09 | mriedem | oh, AND, | |
| 20:44:16 | mriedem | if you have instances in error state, we'll lazy-load fault | |
| 20:44:36 | mriedem | from the api | |
| 20:44:58 | dansmith | not anymore | |
| 20:45:19 | dansmith | this set rips out the fault lazy-loading remember | |
| 20:45:24 | mriedem | https://github.com/openstack/nova/blob/29ef2474d9d6a59ae6859b5b01caad350252c23e/nova/api/openstack/compute/views/servers.py#L148 | |
| 20:45:27 | mriedem | https://github.com/openstack/nova/blob/29ef2474d9d6a59ae6859b5b01caad350252c23e/nova/api/openstack/compute/views/servers.py#L164 | |
| 20:45:31 | mriedem | yeah, | |
| 20:45:34 | mriedem | just thinking about before that | |
| 20:45:35 | dansmith | mriedem: yeah I rip that out | |
| 20:45:36 | dansmith | hard. | |
| 20:45:41 | mriedem | how about tags? | |
| 20:45:52 | dansmith | tags are joined, AFAIK | |
| 20:45:56 | mriedem | i should probably be running this with the latest microversion... | |
| 20:47:02 | dansmith | mriedem: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2229-L2229 | |
| 20:47:22 | mriedem | i'm not using filters | |
| 20:47:49 | mriedem | so if you're listing servers with details with microversion>=2.26, we lazy-load tags on all of them... | |
| 20:47:53 | mriedem | https://github.com/openstack/nova/blob/29ef2474d9d6a59ae6859b5b01caad350252c23e/nova/api/openstack/compute/views/servers.py#L164 | |
| 20:48:16 | mriedem | let me do that quick and see if i'm right | |
| 20:48:22 | jaypipes | efried: tried to answer your query in the traits spec as best I can. this stuff is icky. :) | |
| 20:48:38 | efried | jaypipes Looking... | |
| 20:48:57 | jaypipes | efried: all good questions/comments from you, btw. | |
| 20:49:01 | efried | jaypipes Generally speaking, I'm fine with whatever answer; just would like it to be stated in the spec (docs, whatever) | |
| 20:49:08 | jaypipes | totes | |
| 20:49:13 | efried | jaypipes Thanks for that. I feel like I'm being a PITA. | |
| 20:49:19 | jaypipes | no, not at all. | |
| 20:49:43 | jaypipes | I agree that more explicit is better. it's good you're raising these points. | |
| 20:50:06 | jaypipes | sshh, everybody quiet! penick has joined.. | |
| 20:53:16 | fungi | hugops as a service! | |
| 20:54:57 | jaypipes | fungi: :) | |
| 20:59:42 | mriedem | hmm, very weird, OpenStack-API-Version doesn't seem to work | |
| 20:59:44 | mriedem | sdague: ^ | |
| 20:59:58 | mriedem | i'm doing a curl request with that on a devstack i created today, it doesn't pick up the microversion | |
| 21:00:05 | mriedem | i have to use X-OpenStack-Nova-API-Version | |
| 21:00:29 | openstackgerrit | Steve Noyes proposed openstack/nova master: update live migration to use v3 cinder api https://review.openstack.org/463987 | |
| 21:03:20 | mriedem | oh nvm, i see, need to specify compute | |
| 21:03:26 | mriedem | OpenStack-API-Version: compute 2.53 | |
| 21:03:42 | dansmith | mriedem: actually, I wonder if you can create your broken instances by specifying a target host that doesn't exist? | |
| 21:03:56 | mriedem | yeah probably | |
| 21:04:09 | mriedem | i'm not running under the admin tenant... | |
| 21:04:32 | mriedem | which might have other wrinkles...like checking the host status | |
| 21:04:54 | openstackgerrit | Dan Smith proposed openstack/nova master: Pre-create migration object https://review.openstack.org/498950 | |
| 21:04:55 | openstackgerrit | Dan Smith proposed openstack/nova master: Revert allocations by migration uuid https://review.openstack.org/498949 | |
| 21:04:55 | mriedem | https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id14 | |
| 21:04:55 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor resource tracker to account for migration allocations https://review.openstack.org/506419 | |
| 21:04:56 | openstackgerrit | Dan Smith proposed openstack/nova master: Make migration uuid hold allocations for migrating instances https://review.openstack.org/506420 | |
| 21:05:05 | dansmith | jaypipes: ready for another flogging I think ^ | |
| 21:05:26 | mriedem | microversion >= 2.16 GET /servers/detail will lookup host status if you're admin | |
| 21:05:34 | mriedem | per instance | |
| 21:05:47 | jaypipes | dansmith: I'll ready my cat-o-nine-tails then | |
| 21:06:22 | dansmith | jaypipes: oooh, you know what I liiiiike | |
| 21:06:35 | jaypipes | lol | |
| 21:11:31 | mriedem | dansmith: 15.73s average to list servers with details at microversion 2.53 | |
| 21:11:46 | mriedem | double that of listing servers with microversion 2.1 | |
| 21:11:57 | dansmith | that sucks | |
| 21:12:03 | dansmith | this is all baseline still right? | |
| 21:12:13 | mriedem | ypu | |
| 21:12:15 | mriedem | *up | |
| 21:12:16 | mriedem | gdi | |
| 21:12:17 | mriedem | YES | |
| 21:12:27 | mriedem | and that's demo tenant | |
| 21:13:19 | mriedem | fuck man, looking at the code for microversion 2.16 if you're an admin, we aren't caching host status | |
| 21:15:38 | mriedem | so i think if you're an admin, listing instances from all tenants, with microversion >= 2.16, we're doing a lazy-load of instance.services on every instance | |