On Thu, Dec 21, 2017 at 11:50 AM, intrigeri <intrigeri+libvirt@xxxxxxxx> wrote: > Christian Ehrhardt: >> Great point intrigeri! > >> #1 >> At least as far as my history analysis went this was triggered by ceph >> having the support for lttng enabled. >> Not by actually (trying to) enable the LTT-ng tracking. >> While being disabled in ceph package since then it could show up in a >> similar manner from almost any other source. > >> #2 >> OTOH I never have seen any complains on LTT-ng not working in the virt >> stack for the years carrying this delta. >> So either it is not an issue to those using LTT-ng or no one >> (statistically) uses it on virt-hosts in a case that would require it >> to get these access. > >> Especially due to #1 IMHO I'd tend to add the denies as the flooding >> hits people not explicitly enabling/caring about LTT-ng. >> It would be great if instead of allow/deny we had the option to "deny >> but report once" - like a ratelimit, but we don't. > > OK, why not then. My only remaining concern is that someone who wants > to enable LTT-ng for their VMs (and somehow manages to guess that > these two new rules break it) has to edit the libvirt-qemu abstraction > directly: AFAIK there's no way to override them via a local/ include, > because deny rules take precedence over allow rules. But anyway, we > don't have any local/ include set up for this abstraction on > Debian/Ubuntu currently, so for all practical matters it does not make > a big difference. > > Thus, +1 for applying. Thanks > And then let's keep our awareness level high and be ready to revert if > we get bad feedback about it from !Ubuntu users :) Ack -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
