-
Notifications
You must be signed in to change notification settings - Fork 1.2k
alert: fix type ID for alerts #11350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 4.19
Are you sure you want to change the base?
Conversation
ALERT.VM.SNAPSHOT, ALERT.VR.PUBLIC.IFACE.MTU and ALERT.VR.PRIVATE.IFACE.MTU are all having type value 32. Signed-off-by: Abhishek Kumar <[email protected]>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 4.19 #11350 +/- ##
=========================================
Coverage 15.17% 15.17%
Complexity 11362 11362
=========================================
Files 5415 5415
Lines 476030 476050 +20
Branches 58115 58119 +4
=========================================
+ Hits 72246 72249 +3
- Misses 395701 395717 +16
- Partials 8083 8084 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@blueorangutan package |
@shwstppr a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 14494 |
@blueorangutan test |
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
[SF] Trillian test result (tid-13999)
|
public static final AlertType ALERT_TYPE_VR_PUBLIC_IFACE_MTU = new AlertType((short)33, "ALERT.VR.PUBLIC.IFACE.MTU", true); | ||
public static final AlertType ALERT_TYPE_VR_PRIVATE_IFACE_MTU = new AlertType((short)34, "ALERT.VR.PRIVATE.IFACE.MTU", true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
like Capacity.CAPACITY_TYPE_MEMORY
all these numbers should be mnenomic. I think. an enum is in order, but a growable Set
could be used as well, to make it more dynamic. btw I don’t think the Alert
types should be gotten from external entities to this component (like Capacity
) but external components should at best be allowed to register types, or else use type provided by the AlertService
. I hope this makes sense.
Also all this said, this is not a rejection of this change, just some remarks on the design quality/techdebt we are looking at.
Description
Alert types ALERT.VM.SNAPSHOT, ALERT.VR.PUBLIC.IFACE.MTU and ALERT.VR.PRIVATE.IFACE.MTU are all having type value 32.
TBD: will this cause any sort of issue?
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?