-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
CLOUDSTACK-8800 : Improved the listVirtualMachines API call to include memory utilization information for a VM #1444
Conversation
Thanks for your PR @rafaelweingartner, for tracking purposes, would you mind creating a jira ticket and including the ticket id in the PR title? |
@eriweb sure I can. |
This PR has some nice improvements, so that's great @rafaelweingartner! Still, I'm clueless why people merge without running a single integration test. When doing so, you risk making master unstable. You simply don't know if you broke something else unintentionally. When you run integration tests on another PR later on and that fails, you don't know whether it's that PR or it was master. We've been there, it's a pain. I'll leave it up to @swill to decide as I'm no longer RM. I'd have reverted it, for sure. |
@remibergsma I understand your point. |
@rafaelweingartner, thank you for offering to merge in the changes from #780. I have reverted that merge, if you can merge it here and we can run integration tests against it, that would be greatly appreciated. Thank you sir. :) |
6ba07b9
to
70d0d1f
Compare
@remibergsma, @swill I had cherry-picked the changes of PR #780 into this PR and then I applied my changes to solve those problems that were reported there. |
@@ -484,6 +489,10 @@ public DomainBlockStats answer(final InvocationOnMock invocation) throws Throwab | |||
// IO traffic as generated by the logic above, must be greater than zero | |||
Assert.assertTrue(vmStat.getDiskReadKBs() > 0); | |||
Assert.assertTrue(vmStat.getDiskWriteKBs() > 0); | |||
// Memory limit of VM must be greater than zero |
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.
You specify that memory must be greater than zero in this comment, but it uses >=
in the actual logic. Can you explain?
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.
I have no idea; this code is not mine. I just cherry-picked the commit “92b99714a03c238bcda6ac0c7a57b44cf4890e65” and worked around the possible runtime exception that it might cause.
I expected the code to be ok, giving that it had already received LGTMs and it seemed that it was only reverted because of those points we lifted up in the PR #780.
The code I introduced here can be seen with commit “70d0d1f8c0615fd3b0e6484b7818bb5d14b089b3”. For every single bit there I can provide you an explanation, for the other code introduced with “92b99714a03c238bcda6ac0c7a57b44cf4890e65” I sadly cannot.
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.
I understand. Thanks.
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.
@maneesha-p: can you shed some light on this?
You specify that memory must be greater than zero in this comment, but it uses >= in the actual logic. Can you explain?
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.
I have read and given some time to think about this test. It is very big and complicated, but those are other issues that are due to the method itself that is being tested.
About the test coditional, I believe that the “>=” is right. Because if you are checking the freeMemory, that method can return zero (0) in cases that you are using all of the memory that is being allocated to the VM. I think that the comment in the test case is misleading us.
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.
Ok, that does make sense. I will get this tested and we will go from there. Thanks for the review.
CI RESULTS
Summary of the problem(s):
Associated Uploads
Uploads will be available until Comment created by |
The issues that we see here are environment issues that sometimes show up. They are not related to this PR. I am running another set of usage specific integration tests. I am not sure of the state of these tests, so I will post the results when they are done and we can go from there. |
CI RESULTS
Summary of the problem(s):
Associated Uploads
Uploads will be available until Comment created by |
Ran the usage tests to make sure everything is passing. Don't worry about the snapshot issue, it is not related to this PR. I think this PR is ready if I count the LGTM votes from the previous PR. Any final thoughts??? |
@swill, I am so sorry, I had forgotten this PR. I opened the email to help in a review thinking that this was from someone else. Are you sure we can count the LGTMs from other PR here? |
I would like to get at least one LGTM in this PR. The code is basically the same as the previous one other than the fixes to the potential NPE issues. I think we should get some reviews here regardless. |
@rafaelweingartner please rebase as we currently have merge conflicts. Thanks... |
…e memory utilization information for a VM for xenserver,kvm and for vmware.
70d0d1f
to
6f659e6
Compare
@swill conflicts solved |
@swill Jenkins is complaining about a file called "testsmallfileinactive", but I have not introduced any sort of file like that. Is that some sort of trash that was left behind on the Jenkins VM? |
Just do a force push again. Jenkins is being a bit of a princess recently, so we just have to keep trying. This has been happening to a lot of PRs and it is almost never related to the PR. Maybe I should get my hands dirty and see if I can improve the Jenkins implementation, but I just don't have time right now... |
Ok, I will do that. |
ya, that is interesting. a couple people have mentioned similar tools. once I get the repo moved to the new github org I can start look into adding such tooling... |
6f659e6
to
6c3d8ca
Compare
@rafaelweingartner please rebase against master, and squash changes to a single commit tag:easypr |
@rhtyd I think it would not be a good idea to squash these commits. We will lose the history if we do it here. I only cherry picked the changes done by @maneesha-p and were reverted a while back. Then, I fixed some of the issues that commit introduced. Also, there is no conflict with the master version, do we really need to rebase again? |
I think the two commits are fine in this case, so just leave it as it is. 👍 Can we get some LGTM code reviews on this one? Thanks... |
@rafaelweingartner for a project with thousands of commits, splitting the commits for a PR or bug that solves for the same logical issue results in fragmented history. Both commits can individually improve the commit messages, at least they can be amended to including the JIRA bug ID, detail description (what it is, what it solves etc.). Those things are important and useful when we look back in future. If commits are split into multiple ones, it creates issue to track them, to port them etc. I suggest you squash them into one commit. |
@@ -205,14 +205,21 @@ public UserVmResponse newUserVmResponse(ResponseView view, String objectName, Us | |||
|
|||
userVmResponse.setNetworkKbsWrite((long)vmStats.getNetworkWriteKBs()); | |||
|
|||
if ((userVm.getHypervisorType() != null) && (userVm.getHypervisorType().equals(HypervisorType.KVM) || userVm.getHypervisorType().equals(HypervisorType.XenServer))) { // support KVM and XenServer only util 2013.06.25 | |||
if ((userVm.getHypervisorType() != null) && (userVm.getHypervisorType().equals(HypervisorType.KVM) || userVm.getHypervisorType().equals(HypervisorType.XenServer) || userVm.getHypervisorType().equals(HypervisorType.VMware))) { // support KVM and XenServer only util 2013.06.25 . supporting Vmware from 2015.09.02 |
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.
@maneesha-p @rafaelweingartner
Is there any need for all the HV checks? In case these properties are not supported in some HV, the values can be defaulted to something like 0 or -1.
Due to the checks it cannot be run in simulator.
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.
@koushik-das, that is a great question.
I have no idea why we need to check the hypervisor type. This is something that probably comes way before @maneesha-p changes, giving that she/he just added the check for VMware.
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.
I removed the HV checks and ran it on a simulator and worked as expected, returned 0 for the newly added fields in response. Since this is supposed to work for XS, KVM, VMware anyways, and simulator works as well, guess the check can be removed.
@rhtyd, I understand and I agree with your concerns. The point here is that I am not fragmenting commits, I just cherry picked a commit that was reverted and then I fixed the issues it introduced. About the commit message, both commits are pretty clear what they do, not? The commit “7ad3c5e” from @maneesha-p, has the Jira ticket and a description. And the commit “6c3d8ca” that I introduced, has only a title, but it is pretty clear what it is doing (it fix issues that were introduced by a PR). Do you mean that it should have some Jira ticket opened? |
@rafaelweingartner just checked that the first commit indeed is by someone else, though I think it would be still valid to note in your commit (the 2nd one) the JIRA ID (same as the first one) and summarize details on what extra work you're doing to improve (i.e. why we need it, how we are doing it etc.). Thanks. |
It was worked around some possible runtime exceptions introduced by the changes that were added by the PR 780. Basically, the points in which a null pointer exception could happen, we added safety checks to avoid them. It was create a specific method do that, all together test cases were created for this newly method that was added.
6c3d8ca
to
866ac7b
Compare
That is a nice suggestion. |
@koushik-das, You are right. |
Can we get another code review on this one. Also, can you force push to kick off Jenkins again? Thx... |
1114165
to
417d9a5
Compare
@swill done ;) |
Thanks @rafaelweingartner for the updated PR. |
CI RESULTS
Summary of the problem(s):
Associated Uploads
Uploads will be available until Comment created by |
I think this one is pretty much ready. I have one code review on this one. Can I get one more person to look over this for me? Thanks... |
CLOUDSTACK-8800 : Improved the listVirtualMachines API call to include memory utilization information for a VMThis PR introduces the changes proposed in PR #780 with some work to make the code null safe. During this PR, I have also removed some unused code. * pr/1444: Removed unnecessary check when creating the “userVmResponse” object. Fixed issues from CLOUDSTACK-8800 that were introduced in PR 780 CLOUDSTACK-8800 : Improved the listVirtualMachines API call to include memory utilization information for a VM for xenserver,kvm and for vmware. Signed-off-by: Will Stevens <williamstevens@gmail.com>
This PR introduces the changes proposed in PR #780 with some work to make the code null safe.
During this PR, I have also removed some unused code.