Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-21
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
15:17:50 mriedem now what did i say i was going to do an hour ago...
15:18:08 bauwser mriedem: dansmith: soooo we can assume to modify a DB migration script like this https://review.openstack.org/#/c/458668/1 ?
15:18:29 bauwser mriedem: are you then planning to do a .y release for ^ ?
15:18:48 mriedem bauwser: x
15:18:50 mriedem major version bump
15:18:51 bauwser mriedem: or would it still be a .z given it's a mitaka>newton migration script
15:18:53 mriedem to f over red hat
15:19:07 mriedem if there was a w, i'd use that
15:19:15 mriedem epoch
15:19:43 mriedem it's a bug fix
15:19:45 mriedem not a new migration
15:19:47 mriedem so it's a patch release
15:19:51 mriedem .z
15:19:52 dansmith bauwser: can we assume what now?
15:20:08 dansmith bauwser: you're asking if it's okay to make that change?
15:20:28 mriedem we don't have to worry about people with the bug getting past that migration,
15:20:33 mriedem because they'd be blocked on it
15:20:34 mriedem hence the fix
15:20:43 dansmith ....right
15:21:02 mriedem i.e. swebster_'s migration to newton was blocked on that migration
15:21:27 dansmith yeah it's totally fine to make that change, I'm not sure what the concern is
15:21:51 openstackgerrit Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710
15:22:05 mriedem i released a stable version as a patch release that had a db migration in it awhile back and red hat freaked out, so bauwser is touchy to backports on db migrations ever since
15:22:22 bauwser yeah that
15:22:27 dansmith okay but this is a blocker
15:22:27 bauwser (sorry otp)
15:22:36 mriedem i wasn't aware of red hat's internal stable release processes
15:22:45 mriedem for which i'll always be regretful
15:23:08 dansmith yeah, I remember that, but.. this is... again, a blocker migration
15:23:55 lyarwood bauwser: which db migration was that?
15:24:31 mriedem lyarwood: i think https://github.com/openstack/nova/commit/ee086460db947ea0dcd2cb27fd2aecf738b47c20
15:25:13 mriedem or https://github.com/openstack/nova/commit/608105a7c508ed48055dca6e2d327c944ecb18ea
15:26:12 mriedem lyarwood: this is what you want for the brick encryptors change https://review.openstack.org/#/c/458834/
15:26:46 lyarwood mriedem: yup thanks I'll update the depends on with that now
15:27:33 cdent andymccr, efried : you done yet, I've been holding off until you both bless that shiny code
15:28:09 efried Fer heaven's sake, bless it. We could keep tweaking it for years.
15:28:23 efried Unless pep8 complains about those redundant parens, I say ship it!
15:28:33 efried oh, andymccr fixed...
15:28:49 openstackgerrit Lee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes https://review.openstack.org/391597
15:28:53 cdent efried: unfortunatley I can't +2 it, so...
15:29:43 efried cdent It looks JUST PERFECT now. Please, please approve it! ( sfinucan )
15:29:47 andymccr hahahahahaha
15:31:14 bauwser dansmith: mriedem: so this https://review.openstack.org/#/c/458668/1 is just for a mitaka>newton migration right?
15:31:36 bauwser dansmith: mriedem: I mean, since we say to use the latest .z version, we're fine

Earlier   Later