| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-24 | |||
| 12:56:52 | hemna | hey guys, I have libvirt section in nova.conf setup to use rbd as the libvirt_images_type, to use ceph for all image storage, and yet the placement API says I don't have a provider with enough space to create an 80G vm (flavor m1.large) | |
| 13:04:04 | stephenfin | alex_xu: Firefox is really quite nice nowadays :) | |
| 13:04:37 | stephenfin | I'd argue better than Chrome in many cases (certainly resource utilization) | |
| 13:05:25 | lyarwood | hemna: https://review.opendev.org/#/c/650188/ is aiming to model that in Placement, I assume you don't have 80G of local disks? | |
| 13:05:41 | hemna | yah I don't have 80G in local disk | |
| 13:05:54 | alex_xu | ok, I can a try, I'm enough with the screen always scrolling automatically... | |
| 13:05:54 | hemna | hence the usage of ceph | |
| 13:07:16 | lyarwood | hemna: right, I was just trying to confirm that DISK_GB wouldn't be >= 80GB for the compute node | |
| 13:07:56 | hemna | http://paste.openstack.org/show/749699/ | |
| 13:08:01 | lyarwood | hemna: I guess that's a valid bug, you could use volumes to workaround it. | |
| 13:09:18 | hemna | I have a single compute node (devstack) | |
| 13:10:05 | lyarwood | so the pool doesn't even have 80GB in it? | |
| 13:12:59 | hemna | 6.5Tib available | |
| 13:15:53 | hemna | lyarwood: http://paste.openstack.org/show/749700/ | |
| 13:16:12 | hemna | walt-cloud-vms is my pool for nova | |
| 13:16:18 | hemna | nothing in it so far | |
| 13:18:06 | efried | jaypipes, sean-k-mooney: Those are my personal scratch notes for priority (lower==earlier) and estimated time needed. | |
| 13:18:58 | efried | alex_xu, stephenfin: What issues are you seeing with chrome+gerrit? I've been using that combo for years without heartache, but maybe I'm missing out on something amazing on Firefox | |
| 13:19:30 | hemna | hrmm | |
| 13:20:56 | stephenfin | efried: Oh, no issues on that particular use case for me: I use Firefox for other reasons (it performs better, supports pretty much everything Chrome doesn't, and is worth supporting to avoid a browser monoculture) | |
| 13:20:58 | alex_xu | efried: the screan always auto scrolling, and jump to another random place... | |
| 13:21:02 | efried | alex_xu: Oh, screen flickers up and down when reviewing big files/deltas? You can fix that by toggling the gerrit option: <your name> => Settings => Diff Options => Render => Slow | |
| 13:21:07 | alex_xu | s/screan/screen | |
| 13:21:20 | alex_xu | yes | |
| 13:21:31 | alex_xu | let me try | |
| 13:22:00 | lyarwood | hemna: sorry on a call, reading over the update_provider_tree code for the libvirt driver this should actually be set to the overall rbd pool size | |
| 13:22:11 | efried | It still jumps a little for me, but only occasionally, and it never does the thrashing thing it used to do. | |
| 13:22:11 | stephenfin | but the only time I've seen an autoscrolling issue in Gerrit is when I'm creating/editing a comment and I try to scroll down. It jumps me back up | |
| 13:22:17 | hemna | it's ok. I'm looking further | |
| 13:22:21 | lyarwood | hemna: can you confirm what placement actually has as DISK_GB for the compute node | |
| 13:22:35 | hemna | I just bounced n-cpu and none of the settings in the [libvirt] section of nova.conf are being used. | |
| 13:22:53 | alex_xu | efried: oh yeah, looks better, thanks | |
| 13:23:01 | efried | cool | |
| 13:23:08 | hemna | lyarwood: http://paste.openstack.org/show/749701/ | |
| 13:23:18 | alex_xu | yea, i saw a little jump, but far better than previous | |
| 13:24:12 | lyarwood | hemna: ah, so the images_type isn't rbd for some reason | |
| 13:24:24 | hemna | yah, it's all the defaults | |
| 13:24:30 | hemna | instead of what I have in nova.conf [libvirt] | |
| 13:24:34 | lyarwood | hemna: it's images_type | |
| 13:24:39 | lyarwood | hemna: not libvirt_images_type | |
| 13:24:59 | hemna | guess it was renamed ? | |
| 13:24:59 | lyarwood | hemna: you've prefixed everything with libvirt_* in there it seems | |
| 13:25:18 | hemna | bah ok | |
| 13:25:25 | hemna | I'll update that and retry | |
| 13:25:29 | hemna | not sure how/why I did that | |
| 13:25:46 | lyarwood | hemna: it has always been images_type, libvirt is just the config section. | |
| 13:26:25 | hemna | must have been a copy/paste from somewhere | |
| 13:28:51 | efried | alex_xu: Would you be willing to be the first contact liaison for your time zone, per http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005555.html ? | |
| 13:29:01 | hemna | hrmm that didn't do it | |
| 13:29:14 | hemna | looks like the conf is read from nova-cpu.conf not nova.conf ? | |
| 13:29:45 | lyarwood | yeah with devstack it is | |
| 13:31:00 | hemna | yup that's what it was | |
| 13:31:02 | hemna | phew | |
| 13:31:09 | hemna | lets see if I can create a vm now. thanks for the help | |
| 13:31:26 | openstackgerrit | Eric Fried proposed openstack/nova stable/stein: Fix {min|max}_version in ironic Adapter setup https://review.opendev.org/655429 | |
| 13:31:31 | lyarwood | hemna: np, sorry for the earlier confusion :) | |
| 13:32:18 | hemna | local_gb is now 6705 | |
| 13:32:20 | hemna | a bit better | |
| 13:32:26 | lyarwood | slightly | |
| 13:40:53 | alex_xu | efried: I can be that, at least i'm the only nova core in my time zone | |
| 13:41:09 | efried | alex_xu: Thanks :) | |
| 13:41:17 | openstackgerrit | Hamdy Khader proposed openstack/nova master: Do not perform port update in case of baremetal instance. https://review.opendev.org/649345 | |
| 13:41:37 | efried | alex_xu: What is your time zone? UTC+8? | |
| 13:41:38 | alex_xu | efried: np | |
| 13:41:42 | alex_xu | yes | |
| 13:49:05 | kashyap | efried: alex_xu: Heya, does this look any beter: https://review.opendev.org/641994 https://review.opendev.org/655191 | |
| 13:49:44 | efried | kashyap: Being merged, that first one looks great! | |
| 13:50:31 | kashyap | efried: Hehe, one more thing: because we're consolidating all the AMD stuff in amd.py, I am going to move 'SVM' trit from x86.py to amd.py (in a separate change). | |
| 13:50:49 | kashyap | (Didn't wanted to sneak it in part of this.) | |
| 13:52:23 | kashyap | alex_xu: efried: Also, a trait-per-CPU-feature is _correct_, isn't it? | |
| 13:53:44 | efried | Re: moving traits... I'm not sure what harm that could do, if any. You may need to provide a shim. edleafe jaypipes? | |
| 13:53:44 | efried | kashyap: Yes, one trait per feature is correct. | |
| 13:54:14 | efried | kashyap: tbc, you're not changing what the string would end up being; just the module path we take to get there, right? | |
| 13:54:38 | kashyap | efried: Yes, exactly. Just moving the 'SVM' as-is from one file to another | |
| 13:54:45 | kashyap | Not modifying the string itself | |
| 13:55:19 | efried | kashyap: I mean the string as it comes out the other end. Like if it's currently HW_CPU_FOO_SVM and you made it HW_CPU_FOO_AMD_SVM, that's bad. | |
| 13:55:36 | efried | i.e. that's a *new* trait (and you can't remove the old one, and it's now confusing which one consumers should use) | |
| 13:55:49 | kashyap | efried: Ah-ha...Hmm. | |
| 13:56:39 | efried | But if it's currently in hw/cpu/foo.py and called AMD_SVM, so it actually winds up being HW_CPU_FOO_AMD_SVM, and you move it to hw/cpu/foo/amd.py and name it SVM, the string itself wouldn't change. And that's the thing that *might* be okay. | |
| 13:56:41 | kashyap | I'll post the quick change, and would prefer to be educated there | |
| 13:57:14 | kashyap | efried: Ah-ha, I think you're right there | |
| 13:57:21 | kashyap | So, I see it being os_traits.HW_CPU_X86_SVM | |
| 13:57:22 | efried | kashyap: Sounds like you ought to propose it in its own patch :) | |
| 13:57:47 | kashyap | If I move SVM to amd.py, it can end up being: HW_CPU_AMD_SVM | |
| 13:57:49 | efried | kashyap: Okay, so by project charter, we can't make os_traits.HW_CPU_X86_SVM go away, ever. | |
| 13:58:09 | efried | HW_CPU_AMD_SVM will be a new trait. | |
| 13:58:21 | efried | If there's no such thing as SVM on X86, that's just too bad. | |
| 13:58:28 | efried | you can leave a comment on it that it's bogus | |
| 13:58:30 | efried | but you can't remove it. | |
| 13:59:21 | kashyap | efried: Yeah, indeed. SVM is AMD's equivalent of Intel's VMX (Virtual Machine Extensions) | |
| 13:59:57 | efried | Okay. So if you're just adding AMD_SVM, you can do it as part of your change if that's appropriate. Is it? Sounds like it might be unrelated. | |
| 13:59:58 | kashyap | efried: Okay, that makes sense -- add a comment that it's bogus; and add a new trait for SVM in amd.py | |
| 14:00:19 | efried | ++ | |
| 14:00:41 | kashyap | efried: It's slightly unrelated: but frankly, all these traits_ you are using hardware-based virt (Intel VMX; or AMD SVM) | |
| 14:00:57 | kashyap | Separate change coming soon | |
| 14:01:16 | efried | If your patch is called "add CPU traits related to spectre/meltdown" and it's not, then separate | |
| 14:02:19 | efried | If your patch is called "add a bunch of CPU traits that are missing" you'll have to justify why we need each one anyway. If it's a bunch of different reasons, all in one patch could be fine. But if it's 1) spectre/meltdown and 2) this other random thing that I saw while I was here -- separate patches :) | |
| 14:02:54 | kashyap | Yeah, noted. :-) | |
| 14:06:13 | edleafe | efried: (reading back) It's the full name of the trait that can't change. How it is constructed in the file structure of os-traits is irrelevant | |
| 14:06:24 | efried | edleafe: cool, gtk | |