| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-02 | |||
| 13:05:37 | stephenfin | mriedem: Sure, I'd be happy to | |
| 13:06:24 | mriedem | thanks | |
| 13:06:41 | mriedem | kashyap: is there going to be more to https://blueprints.launchpad.net/nova/+spec/libvirt-cpu-model-extra-flags ? | |
| 13:06:47 | mriedem | or is the bp complete? | |
| 13:06:54 | kashyap | mriedem: Your comment on Friday was right | |
| 13:06:57 | kashyap | mriedem: There is the one last item | |
| 13:07:05 | kashyap | That you quoted to Mel on IRC | |
| 13:07:15 | mriedem | kashyap: even though the last patch says "(A future Nova patch will also allow ability to remove CPU flags.)" | |
| 13:07:17 | kashyap | mriedem: We need ability to remove flags as well. That's one more item | |
| 13:07:19 | kashyap | Indeed | |
| 13:07:24 | mriedem | ok | |
| 13:07:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: Support mixing required traits with any traits https://review.openstack.org/565741 | |
| 13:08:19 | kashyap | mriedem: If you are wondering why we need that. Here is one case I wrote up: | |
| 13:08:22 | kashyap | You might ask: "Why would you want to remove a CPU flag though?" One | |
| 13:08:24 | kashyap | scenario for that is: An Operator wants to generate a baseline CPU | |
| 13:08:27 | kashyap | config. And a certain CPU flag is causing performance issue or other | |
| 13:08:29 | kashyap | nuisance, and if the Operator isolated the problem to _that_ specific | |
| 13:08:32 | kashyap | CPU flag, then she may want to remove the flag. | |
| 13:09:05 | kashyap | mriedem: And thanks for shepherding through the minor nits and merging! | |
| 13:10:48 | gibi | mriedem: hi! regarding having one bp with two specs. Jay asked me to split the spec. Does it automatically means I have to have two bp? | |
| 13:12:09 | mriedem | yes | |
| 13:12:24 | gibi | mriedem: OK, then I will file a separate bp too | |
| 13:16:08 | kashyap | mriedem: When you get a minute, I have a different topic, which needs a opinion. It's quick: | |
| 13:16:18 | kashyap | It's about this: https://review.openstack.org/#/c/565242/ -- libvirt: Remove support for Intel CMT `perf` events | |
| 13:16:53 | kashyap | mriedem: At PTG, we agreed (based on info at that time) to log a warning when Nova's `enabled_perf_events` config is used that it is deprecated, and remove it later | |
| 13:17:10 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: support mixing required traits with any traits https://review.openstack.org/565741 | |
| 13:17:15 | gibi | mriedem: fixed ^^ | |
| 13:17:22 | kashyap | mriedem: However ... upon closer code inspection, we cannot deprecate the config itself, as there are *other* `perf` events besides Intel's CMT events. | |
| 13:17:43 | stephenfin | mriedem, kashyap: I've just left a +1 on this because I think we should take the opportunity to clarify things a little while we're here https://review.openstack.org/#/c/565724/1 | |
| 13:17:46 | kashyap | So here comes my change: What i am proposing is to _remove_ the support for those three Intel CMT events, which is encoded in a dict | |
| 13:17:55 | stephenfin | However, it's not totally related so I can bump to a +2 if you disagree | |
| 13:17:57 | kashyap | (And retain the config itself) | |
| 13:18:12 | kashyap | stephenfin: Let me take a quick look | |
| 13:20:06 | kashyap | stephenfin: Your point is right about it not being clear; but it's a separate change. | |
| 13:20:12 | kashyap | stephenfin: However, | |
| 13:20:52 | kashyap | stephenfin: ... your nit to clean-up _is_post_copy_available() is reasonable, and I should make it in this change. | |
| 13:21:11 | kashyap | It's not a functional change, but just making it like the one below. | |
| 13:22:42 | kashyap | (Even the test change, it still is maybe reasonable to adjust in the current patch.) | |
| 13:22:54 | kashyap | (On a call; will look once done.) | |
| 13:24:03 | mriedem | kashyap: i don't know why PERF_EVENTS_CPU_FLAG_MAPPING are special; you should also probably ask alex_xu about this since he helped work on this getting in | |
| 13:24:24 | kashyap | mriedem: Yep, I actually meant to "Cc" alex_xu on the comment above. | |
| 13:24:46 | kashyap | mriedem: The original config `enabled_perf_events` was added to monitor the flags noted in the CPU_FLAG_MAPPING | |
| 13:24:57 | kashyap | That dict has the three `perf` events for Intel CMT | |
| 13:25:19 | dansmith | kashyap: I know, I just don't think it's worth it.. just MHO | |
| 13:25:38 | kashyap | The way I'm proposing is: (a) remove the broken-by-design Intel CMT (PERF_EVENTS_CPU_FLAG_MAPPING); (b) retain support for other events for `enabled_perf_events` | |
| 13:26:20 | kashyap | dansmith: Hmm, it is a strict improvment, and is correcting a misleading lie that can impact instance boot | |
| 13:26:24 | kashyap | Seems all the worth to me | |
| 13:26:28 | kashyap | Anyway, the backports are done | |
| 13:26:31 | kashyap | And they all pass too | |
| 13:27:10 | kashyap | (It's just a couple of simple lines, FWIW) | |
| 13:27:35 | kashyap | But otherwise, in general I agree with you that minor things shouldn't be backported all the way back like that. | |
| 13:37:04 | bauzas | folks, for those who don't know yet what I call the French May-hem, we're entering a month where a lot of French folks are out | |
| 13:37:23 | dansmith | bauzas: so may is different how then? | |
| 13:38:29 | alex_xu | kashyap: mriedem will check that tomorrow | |
| 13:38:40 | bauzas | dansmith: yesterday was a holiday, plus 3 days | |
| 13:38:53 | kashyap | alex_xu: I still need to fix unit tests; I proposed it just get the core change discussion going | |
| 13:38:55 | dansmith | bauzas: that was thinly veiled sarcasm | |
| 13:39:08 | kashyap | alex_xu: No worries; take care of that. It's more important than this. | |
| 13:39:24 | bauzas | yup :( | |
| 13:39:26 | alex_xu | kashyap: thanks | |
| 13:40:16 | bauzas | anyway, just trying to explain that if people want to discuss with me, ping me directly | |
| 13:40:51 | bauzas | http://www.completefrance.com/home/news/national-holidays-in-france-in-may-1-4050587 | |
| 13:43:20 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306 | |
| 13:49:35 | jaypipes | sahid: looking at your patch now. | |
| 13:52:05 | sahid | thanks jaypipes, let me know if you need any clarifications | |
| 14:02:56 | jaypipes | sahid: did this bug pop up in a RH customer recently or something? | |
| 14:07:52 | mriedem | arvindn05: efried: jaypipes: bauzas: alex_xu: i've replied on the rebuild + image-defined traits thread; at this point i basically need to detach myself from the issue and ask melwitt or dansmith or others with fresh perspective to weigh in | |
| 14:08:00 | sahid | jaypipes: yes BZ#1519540, basically two issues, one on Nova and the other in libvirt | |
| 14:08:08 | sahid | https://bugzilla.redhat.com/show_bug.cgi?id=1519540 | |
| 14:08:09 | openstack | bugzilla.redhat.com bug 1519540 in openstack-nova "nova reporting incorrect available memory" [High,On_dev] - Assigned to sferdjao | |
| 14:08:17 | efried | mriedem: ack | |
| 14:15:16 | jaypipes | sahid: k, reviewed. | |
| 14:15:31 | jaypipes | sahid: I'd be interested in getting stephenfin's eye on that too. | |
| 14:17:05 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_QEMU_POSTCOPY_VERSION https://review.openstack.org/565724 | |
| 14:17:21 | kashyap | stephenfin: Alright, rewrote the unit test the above way. ^ Clearer? | |
| 14:17:44 | mriedem | mdbooth: looks like it's time for https://blueprints.launchpad.net/nova/+spec/local-disk-serial-numbers to go into a runway slot, are you going to be around for the next 2 weeks to respond to reviews? | |
| 14:18:08 | mdbooth | mriedem: Yes indeed! | |
| 14:19:04 | mdbooth | I'm out for the next 2 Mondays, but around apart from that and able to work on this. | |
| 14:19:04 | mriedem | done, you've got until the 16th | |
| 14:19:08 | mdbooth | Thanks | |
| 14:21:08 | artom | What would cause a devstack-installed compute to not report to placement? | |
| 14:21:24 | artom | I see it in both hypervisor-list and service list, so it's "in" the cloud | |
| 14:21:30 | jaypipes | artom: spite. | |
| 14:21:36 | mriedem | misconfig | |
| 14:21:40 | artom | But can't boot VMs on it because I see no resource provider for it | |
| 14:21:41 | mriedem | nova-compute can't talk to placement api maybe | |
| 14:21:47 | mriedem | check [placement] section of nova-cpu.conf | |
| 14:21:55 | mriedem | or just read the n-cpu logs | |
| 14:22:07 | mriedem | see channel topic | |
| 14:22:17 | artom | But this is devstack ;) | |
| 14:23:31 | artom | Hrmm, there's *no* [placement] in nova-cpu.conf | |
| 14:23:35 | artom | That would explain things | |
| 14:24:19 | jaypipes | artom: like I said... spite ;P | |
| 14:24:42 | artom | jaypipes, against me or against placement? | |
| 14:25:51 | jaypipes | artom: 42 | |
| 14:28:24 | artom | mriedem, thanks for the pointers, I copied the controller's [placement] to nova-cpu.conf on the compute and fixed it | |
| 14:29:01 | artom | So nova-cpu.conf is new-ish? I haven't actually looked at a devstack in a while. It's for the compute service, presumably? | |
| 14:30:04 | sahid | jaypipes: yep i think you are right on your review. thanks | |
| 14:32:43 | mriedem | artom: been around since pike | |
| 14:32:58 | artom | mriedem, shows how up to date I am :/ | |