| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-02 | |||
| 15:29:39 | mriedem | idk then, ask kgiusti in #openstack-oslo? | |
| 15:29:46 | mriedem | or sileht? | |
| 15:30:11 | cfriesen | yeah, will do. I suspect we're just always transient. | |
| 15:30:17 | tssurya | mriedem: probably this has come up zillion times, but I couldn't find the right reasoning on why the power synchronization is asymmetric in nova.. why does nova not acknowledge that the vm is back up again ? | |
| 15:31:36 | tssurya | isnt' the driver the state of truth ? | |
| 15:32:08 | mriedem | tssurya: what thing are you specifically talking about? the sync_instance_power_states periodic in compute | |
| 15:32:09 | mriedem | ? | |
| 15:32:12 | tssurya | yes | |
| 15:32:18 | mriedem | that shuts down your server if the db says it's down but the driver says it's up? | |
| 15:32:27 | tssurya | exactly | |
| 15:32:36 | mriedem | because you could be getting charged for one when you told nova to shut it down | |
| 15:32:59 | tssurya | ah okay.. | |
| 15:33:11 | mriedem | it's been years since i've had to load that thing into memory | |
| 15:33:17 | mriedem | and it's always a disaster when i do | |
| 15:33:45 | tssurya | and for the ironic cases where the users may interact through the ipmi interface.. | |
| 15:33:56 | tssurya | the only solution we have is to switch the power sync off ? | |
| 15:34:21 | mriedem | nova doesn't support monkeying with the guests out of band | |
| 15:34:27 | tssurya | is there is a way we could make this behaviour configurable (a choice for deployments) | |
| 15:34:39 | tssurya | hmm | |
| 15:34:44 | mriedem | i'm sure vmware and powervc have had this same argument because the user started up the vm in vcenter or the hmc | |
| 15:34:56 | mriedem | and then nova shut it down | |
| 15:35:03 | tssurya | yes, we have the same stuff | |
| 15:35:19 | stephenfin | mriedem: Remind me: can I +W code? We've branched and everything, right? | |
| 15:35:26 | tssurya | we were just thinking if we could make this configurable.. as in tell nova not to shut it back down | |
| 15:35:32 | mriedem | stephenfin: we have not branched | |
| 15:35:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: guest: introduce blockStats instead of domain.blockStats https://review.openstack.org/526833 | |
| 15:35:41 | tssurya | the default could be what nova does today of course | |
| 15:35:43 | stephenfin | Well then :) | |
| 15:35:50 | mriedem | stephenfin: +W depends on the change | |
| 15:35:58 | mriedem | if it's a bug fix, then yeah maybe | |
| 15:36:02 | mriedem | if it's docs, sure | |
| 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 | |