Fix for the NicVO.java regression.

[borisroman]

Renamed set*() methods to correct naming.

[borisroman]

The updateBuilder will check if the DAO has changed based on the set_() methods. When it can't resolve one, it won't update. After learning this I changed the set_() method names to reflect the names of the variable fields.

[wido]

LGTM

[borisroman]

Tested it in a new environment. The nics are correctly put in the db again.

[borisroman]

@remibergsma @karuturi Please review!

[karuturi]

LGTM. lets wait for travis and other jenkins verifications.

In future, can you club all refactoring work in a branch and merge them together? That way, we can test it once(giving bigger time window for everyone to verofy) and merge
Also, I think this refactoring is a candidate for 4.7. We are already close to RC on 4.6(once 4.5.2 is done) and cannot afford regressions at this stage.

[borisroman]

@karuturi I came to that conclusion in the previous pr. I will stack all refactoring work in a branch. And send a PR when done.

[remibergsma]

@borisroman Thanks! I'll run some tests later tonight. Travis is green, didn't see an Apache build reporting results (yet?).

[asfbot]

cloudstack-pull-rats #363 SUCCESS
This pull request looks good

[asfbot]

cloudstack-pull-analysis #296 ABORTED

[remibergsma]

LGTM Verified that a new cloud deployment had working system VMs again.

[remibergsma]

cloudstack-pull-analysis 296 failed due to: Expected exactly 2 but it took more than 3 microseconds between 2 consecutive calls to System.nanoTime(). Seems not related.

[DaanHoogland]

I think we have to disable this test, enlarging the period even more beats every intention of its use. not related indeed

[remibergsma]

Check, as far as I can tell everything is OK. And since master is broken now anyway, I think it's time to merge this to fix it.

[DaanHoogland]

hm, you shouldt merge anything to a broken master that isn't hellbound on fixing it.

[remibergsma]

@DaanHoogland It does fix the problem, I just feel a bit blind sometimes by the builds that seem less reliable lately so then it's hard to be sure.
But anyway, when looking back we should have quickly reverted the initial PR that introduced the problem. Next time we should do that. Benefit is master is stable again, plus there is time to work on a fix that can then be send as a PR along with the original commits.