Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-02
15:36:10 stephenfin It's a refactor so nope, it should wait
15:36:12 mriedem if it's a big ass refactor or something risky, likely not a great idea right now
15:36:28 stephenfin Yup, I'll just leave it til branch. No panic on it
15:37:02 mriedem tssurya: likely a better question for the ML to get wider input, from both -dev and ops lists
15:37:19 mriedem i'm able to devote about 5% brain to your question atm
15:37:30 tssurya mriedem: ack, sorry for the bad timing then :)
15:37:35 mriedem np
15:43:20 gmann stephenfin: yes, these were missed and they would not fail as they all are req files which are not verified on sample tests. let me know if you can or want me to add them and good to ref those in api-ref also.
15:51:57 stephenfin gmann: I don't mind. Is it a big issue? I guess it just means the api-ref will be incomplete?
15:52:20 stephenfin gmann: If you _do_ have time to work on them, I'll happily review it
15:59:55 mriedem tssurya: note you can disable that sync power state task
16:00:21 mriedem https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L7439
16:00:30 melwitt dangit, was just pulling that up
16:01:04 melwitt you win...again
16:04:48 melwitt https://github.com/openstack/nova/blob/master/nova/conf/compute.py#L753-L777
16:17:20 rdiggz good day everyone. Could someone help me understand what this means? "A sys-admin privsep daemon has been added and needs to be included in your
16:17:22 rdiggz rootwrap configuration.
16:18:35 rdiggz Its from the release notes of pike and queens. Im seeing an issue deploying a snapshot of a CentOS7 instance that points to sys-admin and im thinking they are related.
16:26:33 mriedem cfriesen: is this a bug that should be upstreamed or at least reported to nova? https://github.com/starlingx-staging/stx-nova/commit/fe0c0617be857161b6bb66d632b2b35887c08772
16:27:27 mriedem oh nvm it's already in nova
16:27:38 mriedem https://github.com/openstack/nova/commit/ce8bf6734e554b116e82e924cbe81a5968441926
16:29:42 cfriesen they should've pointed to upstream if it was a backport. grr.
16:30:05 mriedem it's not a backport
16:42:47 mriedem dansmith: looks like one of your earlier is_bfv attempts made it in https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-b839034e35c154b8c3a1c65bf7791eefR114
16:43:16 mriedem cfriesen: what are offline_cpus?
16:43:16 dansmith mriedem: lol
16:43:59 melwitt I think that's part of the second iteration of my famous root_gb=0 workaround patches
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. :)

Earlier   Later