| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-24 | |||
| 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 | |
| 14:13:14 | mriedem | efried: want to hit the easy gerrit cherry pick button to put this in stable/stein? https://review.opendev.org/#/c/654457/ | |
| 14:13:19 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655332 | |
| 14:13:43 | efried | mriedem: I'm 42 minutes ahead of you. | |
| 14:13:51 | mriedem | ah didn't notice b/c the tb changed | |
| 14:13:57 | efried | tb? | |
| 14:14:02 | mriedem | topic branch | |
| 14:14:19 | mriedem | the gerrit ui appends an annoying branch specifier in the backports | |
| 14:14:21 | efried | oh. That's weird | |
| 14:14:36 | efried | I'll pay attention to that from now on and fix it. | |
| 14:24:14 | openstackgerrit | Eric Fried proposed openstack/nova master: Fix mock specs set to strings https://review.opendev.org/655455 | |
| 14:24:14 | openstackgerrit | Eric Fried proposed openstack/nova master: Hacking N363: Don't use spec[_set]='string' https://review.opendev.org/650370 | |
| 14:24:32 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Prepare _heal_allocations_for_instance for nested allocations https://review.opendev.org/637954 | |
| 14:24:33 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: pull out functions from _heal_allocations_for_instance https://review.opendev.org/655457 | |
| 14:24:33 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.opendev.org/637955 | |
| 14:24:34 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: pull out put_allocation call from _heal_* https://review.opendev.org/655459 | |
| 14:24:34 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: reorder conditions in _heal_allocations_for_instance https://review.opendev.org/655458 | |
| 14:24:46 | efried | melwitt: FYI since we talked about this a couple weeks ago: I fixed the Mock(spec='string') things ---^ and put the patch for the hacking rule on top of it | |
| 14:30:25 | efried | kashyap: You have a lot of support for https://review.opendev.org/#/c/645814/ -- if you add some words about when/how you're going to use the information (which I still don't know from outside conversations - fail spawn? fail to start n-cpu?) I'll fast approve if that's okay with sean-k-mooney | |
| 14:31:20 | efried | aspiers: I'm removing SEV from the PTG agenda, since it's approved \o/ | |
| 14:31:21 | sean-k-mooney | ya im fine with that. | |
| 14:31:28 | efried | thx | |
| 14:31:42 | kashyap | efried: Yeah, it's the top-2 item on my TODO, will add it by tomm, that okay? | |
| 14:31:49 | kashyap | If not for this traits yak, I would have done it today | |
| 14:31:57 | efried | kashyap: wfm | |
| 14:32:07 | efried | kashyap: IMO more important than traits yak | |
| 14:32:18 | efried | but of course I would say that because it eases my PTG schedule pain :P | |
| 14:32:29 | sean-k-mooney | ideally it would be nice to log the cpu basleing that was calulated + the flags form the cpu model and config and indicate what flag was incompatable. then kill the agent but we can discus that in the implementation | |
| 14:32:45 | kashyap | efried: Yesterday, I was about to add a quick note that: "Ack, will address this once I finish addressing the Secure Boot comments" | |
| 14:32:59 | kashyap | (The SB spec took a lot more time, too) | |
| 14:33:13 | sean-k-mooney | effectivly if nova can detect via libvirt that its incomatible we shoudl also tell the operator why so that they dont need to figure it out themselves | |
| 14:33:21 | kashyap | sean-k-mooney: Yeah. Let's hash it out when I actually get to implement it | |
| 14:33:27 | jaypipes | efried: ack, got it. thx! | |
| 14:33:56 | efried | jaypipes: Since parlayed into a draft agenda, see ML. | |
| 14:34:06 | efried | (which may be where you were coming from in the first place) | |
| 14:37:22 | kashyap | efried: On your question on that spec about 'where to fail' -- I'm thinking currently 'spawn'. Will add words to the spec | |
| 14:37:32 | efried | kashyap: Perfect, thanks. | |
| 14:37:44 | efried | I don't actually have a stake in what the answer is - I just want to see one :) | |