Earlier  
Posted Nick Remark
#openstack-nova - 2018-08-02
16:44:35 cfriesen mriedem: that's part of our cpu scaling code. you can boot with X cpus and then scale down to fewer. offline_cpus tracks which guest vCPUs are supposed to be offline.
16:44:49 cfriesen mriedem: (the cpu scaling stuff requires guest cooperation to do properly)
16:45:02 cfriesen melwitt: I think that's correct
16:45:44 melwitt dansmith had started with the request spec part but I found that the claims and reporting on the compute side didn't yet support is_bfv so had to add that to it too in another patch stacked on top. and in the end it looked exactly like the original workaround patch that got nack'd by everyone
16:46:04 melwitt so it lay abandoned again
16:46:53 mriedem cfriesen: how is that different from just resizing down?
16:47:01 mriedem the offline CPUs are reserved?
16:47:27 cfriesen mriedem: it's similar to the "live-resize" proposed recently
16:47:30 mriedem i.e. so you can scale up and down w/o worrying about claim failures?
16:47:34 cfriesen mriedem: the server stays running
16:48:10 cfriesen mriedem: the resource tracking is adjusted, but the quota isn't
16:48:24 cfriesen so you could fail to scale up if there are no free cpus on the host
16:49:14 mriedem right that's what i was saying,
16:49:24 mriedem you essentially boot with like 4 vcpu,
16:49:29 mriedem resize down to 2,
16:49:39 mriedem but the other 2 are "offline" so you can resize back up?
16:50:01 mriedem but you're still paying for 4 VCPU of quota?
16:50:32 cfriesen remember this is private cloud so "paying for quota" is a bit iffy. but yes.
16:51:00 dansmith I'm not sure people usually charge for quota either
16:51:10 dansmith they pay for usage, which would be based on the stuff they're updating I imagine
16:51:16 mriedem and this is needed why? so edge nodes can automatically scale down during down times and scale up during peak hours?
16:51:55 dansmith it's needed because someone wanted it one time
16:52:03 dansmith because there was a knob they couldn't twiddle
16:52:07 cfriesen dansmith: :)
16:52:35 cfriesen I think the idea is that there are pets with unpredictable load that don't scale well horizontally
16:53:44 cfriesen similar rationale as https://blueprints.launchpad.net/nova/+spec/instance-live-resize
16:53:48 mriedem sure
16:54:00 mriedem ok, feature 1 of 130 sorted out in my spreadsheet,
16:54:01 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor NeutronFixture https://review.openstack.org/588338
16:54:05 mriedem time for lunch!
16:54:44 melwitt found it https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-afb9c0c0ca5276c7eacd987bbf51d8e6R370
16:54:53 cfriesen mriedem: having done that spreadsheet multiple times with the benefit of commit history, I feel for you. I apologize for our legal guys.
16:55:33 mriedem i'll take your pity and just remind you of it when you get tired of me asking questions
16:59:18 mriedem ooo server group metadata
16:59:22 mriedem good thing we just nuked that from the api in rocky
17:00:04 mriedem anyone know of a way to make github just load all diffs? because it simply gave up here
17:00:38 cfriesen mriedem: heh. the only thing we use it for is "max number of servers in group", and a "best effort" flag that pre-existed the "soft" affinity policies.
17:01:18 mriedem i guess rather than crawl through github it's probably easiest to just clone this repo and look for "WRS" ?
17:03:15 cfriesen looking for WRS will get you a lot of stuff. also look for files with wrs in the name
17:04:06 sean-k-mooney mriedem: all the changes are squashed into one big commit on top of what was master when it was created
17:04:37 mriedem sean-k-mooney: yes, i'm intimately familiar
17:05:22 sean-k-mooney i made a list of randome stuff to look at later in that repo but left it at intel when i left
17:07:58 cfriesen mriedem: technically speaking one of the things I liked was the ability to dynamically shift host CPUs between being used for "pinned" instances and "shared" instances on the same node. That was also the rationale for the floating-point representation of "used cpus" on the host.
17:20:41 sean-k-mooney cfriesen: yes... that is interesting
17:21:16 sean-k-mooney cfriesen: yes re pinned all the floating instances on the host to make that work if i recall
17:22:16 mriedem today ops just use host aggregates to separate hosts/flavors that do cpu pinning and hosts with cpu overcommit yeah?
17:22:19 sean-k-mooney cfriesen: im not sure liked is the workd i would have chosen but the capablit is certenly interesting.
17:22:46 sean-k-mooney mriedem: mostly yes
17:23:16 sean-k-mooney that is more of a cludge to workaround the fact nova does not do it magically for them rather then they like it
17:24:43 cfriesen mriedem: the issue was that we have demand for small installs (down to one or two nodes in some cases) and so it's not practical to have to devote entire nodes to either shared or dedicated instances
17:24:55 sean-k-mooney there were some specs covering having pininned and shared cores on the same host this cycle. tesro and jay were talking about them in dublin.
17:25:23 cfriesen sean-k-mooney: with the new specs you still have to specify up-front which cpus are for which purpose
17:25:51 sean-k-mooney cfriesen: right so you level them float but repin the floating vms wheever you spawn a new pinned vm
17:26:04 sean-k-mooney *let them float
17:27:16 cfriesen sean-k-mooney: sort of. the floating tasks are in a cpuset on the host, and we re-pin the cpuset (to avoid looping over all floating instances)
17:27:24 cfriesen but logically it's equivalent
17:27:25 sean-k-mooney any yes i realise you have to specify up front. with the approch ye took ye still set a minium amount of cores that could be used for the non pinned host right? or did you calulate it based on the oversubsction ratio
17:27:44 cfriesen sean-k-mooney: allocation ratio
17:28:14 jaypipes sean-k-mooney: what's pininned cores? :P
17:28:29 mriedem cfriesen: yeah i figured that was the reason
17:28:34 mriedem 2 node edge site
17:28:37 mriedem or whatever 'grouse' is
17:28:37 sean-k-mooney jaypipes: its my getting used to my keyboard :)
17:28:41 jaypipes :)
17:28:49 jaypipes switched to dvorak?
17:28:52 mriedem cfriesen: grouse install is what, single node?
17:29:43 sean-k-mooney ha no i have a corsair mechanical keyboard that i bought like a year ago but i used to the crappy membrane keyboard i used to use at work
17:30:24 sean-k-mooney i can type way faster now but also im makeing some mistakes i didnt before so hopefully in a week or so i will be used to it
17:31:30 cfriesen mriedem: those names are all newly-invented, have to go look
17:31:55 cfriesen but we support single-node, duplex single-node, and multi-node with two controller nodes
17:32:22 mriedem it goes grouse, something something, and then something with an R in the name
17:32:25 mriedem canadian mountain ranges
17:32:51 cfriesen robson, I think. Pretty much invented right before the summit. :)
17:33:40 mriedem https://youtu.be/Z1DN41WnRkc?t=560
17:33:45 mriedem grouse, whistler, robson
17:34:31 cfriesen there we go. the two-controller case uses replicated storage for improved availability
17:36:51 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove old check_attach version check in API https://review.openstack.org/588348
17:38:48 openstackgerrit Eric Fried proposed openstack/nova master: [placement] Debug log per granular request group https://review.openstack.org/588350
17:43:58 sean-k-mooney cfriesen: ya 3 dedicated contoler nodes is major overkill in many cases but alot of people still default to it
17:44:49 openstackgerrit Merged openstack/nova master: Remove unused stubbing function from test https://review.openstack.org/586968
17:44:59 openstackgerrit Merged openstack/nova master: Improve NeutronFixture and remove unncessary stubbing https://review.openstack.org/587412
17:57:57 openstackgerrit Eric Fried proposed openstack/nova master: WIP/PoC: safe_connect shouldn't hide failures https://review.openstack.org/584593
18:20:48 mnaser so i noticed that
18:20:49 mnaser https://github.com/openstack/nova/blob/master/nova/virt/libvirt/volume/volume.py#L62-L79
18:20:52 mnaser and
18:20:54 mnaser https://github.com/openstack/nova/blob/master/nova/virt/libvirt/imagebackend.py#L168-L176
18:21:02 mnaser is pretty much the same thing repeated
18:21:28 mnaser one does it for volumes, the other does it for 'imagebackend' aka nova "images"
18:22:10 mnaser would moving the method to nova.virt.libvirt.utils make sense?
18:23:24 mnaser or maybe moving it into a function inside LibvirtConfigGuestDisk ?
18:27:00 melwitt maybe. if you think there's a common utility method both could use
18:27:31 melwitt they look similar but not sure if they're doing the exact same thing
18:28:34 mnaser melwitt: they're pretty much both setting quotas, one handles the quotas that are extra_specs in flavor, the other one handles setting quotas that are from nova volumes
18:39:12 melwitt mnaser: I see. yeah, I dunno where the common method should go. utils seems like the place, as for LibvirtConfigGuestDisk I'd ask lyarwood or mdbooth (they are EU time zone)
18:45:16 mriedem cfriesen: there wasn't any upstream equivalent for this per-instance live migration max downtime feature was there? i know about https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/live-migration-per-instance-timeout.html but that's for per-instance live migration timeout which is different.
18:53:51 openstackgerrit Eric Fried proposed openstack/nova master: [placement] Add /reshaper handler for POST https://review.openstack.org/576927
18:53:52 openstackgerrit Eric Fried proposed openstack/nova master: reshaper: Look up provider if not in inventories https://review.openstack.org/585033
18:53:53 openstackgerrit Eric Fried proposed openstack/nova master: Make get_allocations_for_resource_provider sane https://review.openstack.org/584598
18:53:54 openstackgerrit Eric Fried proposed openstack/nova master: Report client: Real get_allocs_for_consumer https://review.openstack.org/584599
18:53:55 openstackgerrit Eric Fried proposed openstack/nova master: Report client: get_allocations_for_provider_tree https://review.openstack.org/584648

Earlier   Later