Earlier  
Posted Nick Remark
#openstack-nova - 2018-05-02
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 :/
14:33:11 jroll mriedem: gdi, this is why you need a bouncer, meant to ping you on this: https://review.openstack.org/#/c/565736/
14:33:20 jroll s/meant/tried/
14:33:27 mriedem artom: i don't know why you'd not have placement configured properly, devstack should have set that all up for you
14:34:11 mriedem gfdi jim, i'm a doctor not a guy that sits up all night waiting for irc pings
14:34:20 jroll heh
14:34:42 artom mriedem, I followed https://docs.openstack.org/devstack/latest/guides/neutron.html, maybe it's out of date for placement? Specifically, ENABLED_SERVICES on the compute
14:35:12 mriedem yes definitely
14:35:56 mriedem placement-client should be in that list
14:36:00 mriedem like https://docs.openstack.org/devstack/latest/guides/multinode-lab.html#configure-compute-nodes
14:36:33 artom mriedem, aha, indeed
14:37:15 artom Shall I apply force to a change in the textual representation of the documentation?
14:37:30 mriedem yes
14:37:37 mriedem be a good citizen
14:37:52 artom Service guarantees citizenship!
14:38:14 jaypipes sahid: ok, cool. test cases should be identical, though, so that's a plus :)
14:42:30 Shilpa stephenfin: Hi
14:43:39 stephenfin Shilpa: o/
14:43:47 kashyap artom: Also, do post your renewed multi-node configs somewhere
14:43:56 jaypipes mriedem, stephenfin, dansmith: your reviews on https://review.openstack.org/#/c/561315/ would be appreciated. thx in advance :)

Earlier   Later