We have the warning in the events tab: "The number of LVs on the domain XXX exceeded 300, you are approaching the limit where performance may degrade." But many users do not access frequently the admin portal and do not get notified regarding that. We would like to add an email notification for this as well.
Failed to set the "Users"->"Manage Events"->"Storage Management Events:" -> "Storage Domain's number of LVs exceeded threshold", got: " Operation Canceled Error while executing action: A Request to the Server failed with the following Status Code: 500" Sosreport from host has been attached.
Created attachment 1146504 [details] Screenshot from 2016-04-12 17:48:44.png
Created attachment 1146505 [details] sosreport from the engine
Engine's components: CentOS Linux release 7.2.1511 (Core) Linux 3.10.0-327.13.1.el7.x86_64 #1 SMP Thu Mar 31 16:04:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux ovirt-engine-4.0.0-0.0.master.20160404161620.git4ffd5a4.el7.centos.noarch ovirt-host-deploy-1.5.0-0.0.master.20160329063025.gitdf57fe1.el7.centos.noarch ovirt-host-deploy-java-1.5.0-0.0.master.20160329063025.gitdf57fe1.el7.centos.noarch javassist-3.16.1-10.el7.noarch javapackages-tools-3.4.1-11.el7.noarch java-1.7.0-openjdk-devel-1.7.0.99-2.6.5.0.el7_2.x86_64 java-1.8.0-openjdk-1.8.0.77-0.b03.el7_2.x86_64 java-1.7.0-openjdk-headless-1.7.0.99-2.6.5.0.el7_2.x86_64 java-1.8.0-openjdk-headless-1.8.0.77-0.b03.el7_2.x86_64 javamail-1.4.6-8.el7.noarch java-1.7.0-openjdk-1.7.0.99-2.6.5.0.el7_2.x86_64 These from server.log might be also related to the issue: Caused by: java.lang.NoClassDefFoundError: javax/mail/internet/AddressException at java.lang.Class.forName0(Native Method) [rt.jar:1.8.0_77] at java.lang.Class.forName(Class.java:264) [rt.jar:1.8.0_77] at org.ovirt.engine.core.bll.CommandsFactory.loadClass(CommandsFactory.java:193) [bll.jar:] at org.ovirt.engine.core.bll.CommandsFactory.getCommandClass(CommandsFactory.java:178) [bll.jar:] at org.ovirt.engine.core.bll.CommandsFactory.getCommandClass(CommandsFactory.java:161) [bll.jar:] at org.ovirt.engine.core.bll.CommandsFactory.createCommand(CommandsFactory.java:86) [bll.jar:] at org.ovirt.engine.core.bll.CommandsFactory.createCommand(CommandsFactory.java:79) [bll.jar:] at org.ovirt.engine.core.bll.MultipleActionsRunner.initCommandsAndReturnValues(MultipleActionsRunner.java:80) [bll.jar:] at org.ovirt.engine.core.bll.MultipleActionsRunner.execute(MultipleActionsRunner.java:61) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runMultipleActionsImpl(Backend.java:613) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runMultipleActions(Backend.java:583) [bll.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_77] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_77] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_77] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_77] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final]
Did you check other events? all fails or only the LVs event fails? If all is not working than we need to open a bug for it and block this on the new bug, else we need to reopen the RFE as the basic flow is not working.
(In reply to Aharon Canan from comment #5) > Did you check other events? all fails or only the LVs event fails? > > If all is not working than we need to open a bug for it and block this on > the new bug, > > else we need to reopen the RFE as the basic flow is not working. It fails each time you selecting all or any of the selection boxes, not related to this feature in general, this looks like a frontend java bug. I think that separate bug is the best option for this and this RFE will have to be set as dependent on opened bug.
Opened a separate bug and blocking this one with it: https://bugzilla.redhat.com/show_bug.cgi?id=1326578
Yaniv, After number of LV's in storage domain reaches 300, and I get an email notification.. should I expect getting the same notification for 301,302,303.. etc. (over and over again)? Thanks
Please bare in mind that if customer will create each of he's disks (LVs) separately inside specially created SD,(one LV per SD)*300, then he'll hit the 1339245.
(In reply to Nikolai Sednev from comment #9) > Please bare in mind that if customer will create each of he's disks (LVs) > separately inside specially created SD,(one LV per SD)*300, then he'll hit > the 1339245. No, he won't. This alert is for LVs PER STORAGE DOMAIN.
(In reply to Natalie Gavrielov from comment #8) > Yaniv, > > After number of LV's in storage domain reaches 300, and I get an email > notification.. should I expect getting the same notification for > 301,302,303.. etc. (over and over again)? > > Thanks Yes, you should get it each time you create a disk and the total number of disks on the domain is >= AlertOnNumberOfLVs in the db (300 by default).
(In reply to Idan Shaby from comment #11) > (In reply to Natalie Gavrielov from comment #8) > > Yaniv, > > > > After number of LV's in storage domain reaches 300, and I get an email > > notification.. should I expect getting the same notification for > > 301,302,303.. etc. (over and over again)? > > > > Thanks > > Yes, you should get it each time you create a disk and the total number of > disks on the domain is >= AlertOnNumberOfLVs in the db (300 by default). Let's say a user is running a script creating 500 disks (LV's).. he'll get 200 emails. This is kind of spamming the user, isn't it?
He'll get 201 emails. It's not a bug, it's by design. But let the PMs/managers decide. Yaniv/Allon?
Won't the flood suppression mechanism prevent you from getting too many emails at one?
I am not sure. Moti, can you give us your two cents about the email notification mechanism?
(In reply to Allon Mureinik from comment #14) > Won't the flood suppression mechanism prevent you from getting too many > emails at one? Yes, the definition of the enum in AuditLogType doesn't contain any flood info - therefore events keeps coming. NUMBER_OF_LVS_ON_STORAGE_DOMAIN_EXCEEDED_THRESHOLD(1008, AuditLogSeverity.WARNING), You should decide on a reasonable threshold and set it for this enum (see AuditLogTimeInterval) In order to prevent loosing events for other storage domains, you should use the AuditLog.setCustomEventId() and set the storage domain id as the event identifier - so flooding prevention will act per storage domain. (In reply to Idan Shaby from comment #15) > I am not sure. > Moti, can you give us your two cents about the email notification mechanism? Aggregating notifications to the user by the event-type makes sense. But this specific bug can be fixed without changing the infra for that.
Allon/Idan, Is there an open issue on flooding with emails?
Not that I know of. Allon, Do we want to pull this BZ back from QE and send a patch to prevent a mail flood? From what Moti explained here, it should be pretty simple.
If it's under an hour's work, just do it. If not, let's leave the decision to PM.
(In reply to Idan Shaby from comment #18) > Not that I know of. > Allon, Do we want to pull this BZ back from QE and send a patch to prevent a > mail flood? > From what Moti explained here, it should be pretty simple. We should not flood the user with email. Once every few hours should be good.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Moving target release to RC to include the latest fix.
Verified, rhevm-4.0.0.5-0.1.el7ev.noarch One issue found (in one of the earlier builds) : https://bugzilla.redhat.com/show_bug.cgi?id=1340209