| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-21 | |||
| 14:40:41 | bauwser | mriedem: I think the consensus looks good by me | |
| 14:40:53 | mriedem | reschedules are possible in a single-cell deployment | |
| 14:40:54 | bauwser | that's my "either" possibiltyu | |
| 14:41:05 | mriedem | but i don't think we should rely on them | |
| 14:41:09 | bauwser | okay | |
| 14:41:11 | mriedem | when designing things | |
| 14:41:34 | mriedem | dan proposed adding a config option to disable reschedules so you never have upcalls, regardless of deployment | |
| 14:41:44 | bauwser | so it leaves the idea to modify inventories to add more "something" for decrementing the "left" value | |
| 14:42:25 | bauwser | amending 'reserved' could be that "something" which wouldn't need to add a new DB fiedl | |
| 14:42:50 | mriedem | correct, that's what most people wanted the other day | |
| 14:42:58 | bauwser | mriedem: yup, and I +2d that change for the instance scheduler RPC call | |
| 14:43:06 | mriedem | it sucks for the operator because they have to configure reserved amounts, | |
| 14:43:13 | mriedem | unless we can come up with a scheme to automate it | |
| 14:43:14 | bauwser | mriedem: okay, if so, I think I can amend that spec | |
| 14:43:44 | bauwser | mriedem: I was rather thinking to have the inventory be modified by the RT to augment it by the sum of overhead for each instance | |
| 14:43:46 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova master: Remove fstype param from ploop init https://review.openstack.org/444970 | |
| 14:43:53 | bauwser | snap | |
| 14:44:01 | bauwser | to have the inventory.reserved value | |
| 14:44:02 | cfriesen | question...has nova ever considered setting the virtual disk logical/physical block size based on the host disk block size? currently the guest sees 512 even for disks with 4K block size, which potentially leads to extra read-modify-write overhead | |
| 14:44:40 | leakypipes | mriedem: k, on it. | |
| 14:46:23 | bauwser | leakypipes: mriedem: okay, I think then I have enough to amend the spec | |
| 14:46:44 | bauwser | I'll try to provide a new rev' by today EOB or Monday | |
| 14:46:44 | leakypipes | bauwser: coolio. | |
| 14:46:55 | mriedem | bauwser: so rather than add overheads to allocations, you want to add overhead to inventory.reserved during each build? | |
| 14:47:28 | mriedem | that could still get you in a 409 situation where we have to fail the build | |
| 14:47:31 | bauwser | leakypipes: do you agree with my idea to augment in the RT the reserved value given by the driver.get_inventory() method by the number of instance.overhead we have ? | |
| 14:48:19 | mriedem | we had talked about just a configurable value that get_inventory() would provide and isn't per-instance | |
| 14:48:47 | figleaf | I don't like treating reserved like an allocation - it should be set when the RP is created, and that's it | |
| 14:48:49 | leakypipes | bauwser: hmm, I must have missed that. lemme have another look at the spec | |
| 14:48:58 | bauwser | leakypipes: that's not yet in the spec | |
| 14:48:59 | mriedem | leakypipes: it's new as of bauwser today | |
| 14:49:02 | leakypipes | oh | |
| 14:49:05 | mriedem | last 5 minutes | |
| 14:49:13 | figleaf | it's sort of in my last comment on the spec | |
| 14:49:17 | leakypipes | no wonder I missed it then :) | |
| 14:49:22 | bauwser | I'm trying to explain that we find nodes based on what we ask vs. what we have as free | |
| 14:49:32 | bauwser | so, what we ask is the flavor | |
| 14:49:44 | bauwser | what we have is the inventory minus the allocations | |
| 14:49:48 | leakypipes | bauwser: sorry, lemme read back up. I just got back from breakfast :) | |
| 14:50:04 | bauwser | I'm trying to explain it another way | |
| 14:50:27 | bauwser | given we ask for the flavor size | |
| 14:50:34 | mriedem | reserved to me means static reserved, via config from the operator, something that nova doesn't mess with automatically | |
| 14:50:49 | bauwser | and we compare it to each node by doing (total - reserved - sum(allocations)) | |
| 14:51:00 | figleaf | mriedem: exactly | |
| 14:51:15 | bauwser | I'm seeing some way to say (total - reserved - sum(allocations) - sum(overhead)) | |
| 14:51:26 | figleaf | for a hypervisor, it's the "cost of doing business" | |
| 14:51:32 | mriedem | worst case scenario is you don't modify reserved at all and run the risk of over-consuming your resources on the host | |
| 14:51:47 | bauwser | my proposal being "reserved" and sum(overhead) is purely related to the hypervisor | |
| 14:51:48 | mriedem | for ram and disk it could be a small overhead | |
| 14:51:54 | mriedem | that you didn't account for in capacity planning | |
| 14:52:04 | figleaf | the amount of resource that a provider cannot offer | |
| 14:52:20 | bauwser | I think we all know why we have that "reserved "field | |
| 14:52:48 | bauwser | I'm just trying to see how we can consider overheads to be part of something sent to placement | |
| 14:53:12 | bauwser | because the more I think, the more I'm -1 to amending allocations if we consider allocations as the basement for quotas | |
| 14:53:14 | figleaf | if we do, then we should use it accordingly. "Overhead" is nothing except resources that the HV needs to do its job | |
| 14:53:41 | mriedem | alex_xu: since we print "Instance UUID" in the nova migration-list output, i guess --instance-uuid is ok | |
| 14:53:50 | bauwser | the other way would require a new 'overhead' table that would be per consumer id | |
| 14:54:05 | mriedem | bauwser: i think we already shot own the idea of updating allocations to account for overhead | |
| 14:54:05 | bauwser | exactly like allocations is | |
| 14:54:14 | bauwser | mriedem: \o/ glad to hear | |
| 14:54:21 | bauwser | mriedem: so, if we say it's not allocations | |
| 14:54:41 | mriedem | it's rp.inventory.reserved | |
| 14:54:41 | bauwser | and if we don't want to touch 'reserved', then how could we send that amount to placement ? | |
| 14:54:48 | mriedem | it is via reserved | |
| 14:54:49 | bauwser | mriedem: right | |
| 14:55:01 | mriedem | the question is, is it static via config, or do you adjust it dynamically | |
| 14:55:10 | figleaf | Configure when creating the RP, and be done with it | |
| 14:55:11 | mriedem | which is what i thought you were talking about doing, the latter | |
| 14:55:16 | bauwser | so, why are people arguing with my idea to automatically augment that rp.inventory.reserved by the sum(overhead) ? | |
| 14:55:21 | mriedem | the simplest solution is config like figleaf says | |
| 14:55:35 | bauwser | mriedem: remember the libvirt overheads | |
| 14:55:46 | bauwser | and see how it is linear per instances | |
| 14:56:05 | mriedem | i realize that the overhead is per instance | |
| 14:56:19 | bauwser | FWIW, my Red Hat infrastructure gladly crashed so I'm really 100% committed to upstream :p | |
| 14:56:24 | figleaf | bauwser: so figure out what the max number of instances that will cover 90% of the hosts, and use that | |
| 14:56:32 | leakypipes | mriedem, bauwser, figleaf (and anyone else who wants to settle the overheads discussion): https://hangouts.google.com/hangouts/_/ejhj37l6u5fkhonhnn23in2vome | |
| 14:56:35 | lyarwood | bauwser: who needs DNS anyway? | |
| 14:56:40 | bauwser | figleaf: how could you be ? it's depending on the number of flavors the users ask ? | |
| 14:56:45 | mriedem | and yes we could technically adjust the inventory.reserved based on the sum of all instance overheads, but i think that would be a surprise to operators that nova is automatically adjusting and increasing the reserved amount of inventory even though they set a static config value for it | |
| 14:56:53 | alex_xu | mriedem: ok, got it | |
| 14:56:59 | bauwser | lyarwood: you're right, it's totally useless | |
| 14:57:42 | bauwser | mriedem: if we allow them to see the values thru the REST API, I agree | |
| 14:57:52 | figleaf | leakypipes: gimme a minute | |
| 14:57:55 | mriedem | bauwser: which we do | |
| 14:57:57 | bauwser | mriedem: but for the moment, we never intended to do so | |
| 14:58:02 | mriedem | huh/ | |
| 14:58:04 | mriedem | ? | |
| 14:58:30 | bauwser | mriedem: I thought we said the REST API is not yet consumable by end-users ? | |
| 14:58:46 | mriedem | bauwser: jump on the hangout if you can | |
| 14:59:02 | openstackgerrit | Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710 | |
| 14:59:31 | bauwser | mriedem: "I live for obeying orders" (again, French comics named 'Leonard') | |
| 15:02:51 | openstackgerrit | Monty Taylor proposed openstack/python-novaclient master: Remove direct dependency on requests https://review.openstack.org/458868 | |
| 15:04:09 | lyarwood | ildikov / stvnoyes ; just getting around to the cinderv3 patches now, am I okay to work on the swap_volume change? https://review.openstack.org/#/c/456971/ | |
| 15:05:32 | ildikov | lyarwood: it should be ok, stvnoyes took https://review.openstack.org/#/c/456877/ yesterday | |
| 15:06:01 | lyarwood | ildikov: kk thanks | |
| 15:06:13 | ildikov | lyarwood: this one is on its way to get merged: https://review.openstack.org/438750 , so I should rebase the chain though | |
| 15:08:54 | ildikov | lyarwood: also this one is not in the chain and needs some love too if you don't want to deal with the patch in the middle of the chain: https://review.openstack.org/#/c/456851/ | |
| 15:16:02 | bauwser | leakypipes: mriedem: figleaf: thanks for helping me, always appreciated. :) | |
| 15:16:17 | bauwser | you just missed my new co-worker's face | |
| 15:16:27 | mriedem | dogs psh | |