Ovmsupport

[snuf]

Pulling back up against master so we can keep following it a bit...

[rohityadavcloud]

Hey, @snuf can you rebase this against master, let's merge it on master if it works functionally and the build passes with smoke tests?

[snuf]

Hey Rohit,

It’s been rebased with master two days ago, so should be a “breeze”, is there a specific point you want me to merge with ?

Cheers,

Funs

On 05 Dec 2014, at 18:31, Rohit Yadav notifications@github.com wrote:

Hey, @snuf can you rebase this against master, let's merge it on master if it works functionally and the build passes with smoke tests?

—
Reply to this email directly or view it on GitHub.

[rohityadavcloud]

That's great Funs. I see it's already passing smoke tests on TravisCI so we can merge it on master whenever you advise? If it's functionally working with good enough coverage and tests I would say go ahead and merge it on master right away.

[snuf]

Hi Rohit,

Well there are a couple of things here:

1st: I work on a fork and pull in upstream master and merge that into ovmsupport (https://github.com/snuf/cloudstack/tree/ovmsupport) so in principle that makes the ovmsupport tree aligned with master including my patches.
2nd: Test coverage on part of the code is 81% (the object branch, supportive translation layer to communicate with Ovm3) and on part not where I want it to be (the hypervisor branch, where integration with Cloudstack lives).
3rd: It works within the boundaries of the feature design doc on wiki, which means all basic stuff works but some features can not be provided as Ovm3 doesn’t support them with the storage backend (running snapshots for example).
4th: The systemvm.img that’s generated from buildsystemvm.sh is a raw image so can be used for the systemvms for Ovm3.

Does this answer your question ? I genuinely think there should be some coverage for the integration layer into Cloudstack which is kind of absent?

Cheers,

Funs

On 06 Dec 2014, at 14:02, Rohit Yadav notifications@github.com wrote:

That's great Funs. I see it's already passing smoke tests on TravisCI so we can merge it on master whenever you advise? If it's functionally working with good enough coverage and tests I would say go ahead and merge it on master right away.

—
Reply to this email directly or view it on GitHub.

[rohityadavcloud]

Hi Funs,

Thanks for replying. Alright let us know when you've good set of integration tests, I'm halfway with a new integration testing system semi-automated by ansible that uses CloudStack to test CloudStack. In that I run KVM, Xen etc. as VMs on KVM hosts all managed by CloudStack.

Regards.

[rohityadavcloud]

@snuf Funs how about we merge your stuff in?

[snuf]

Hey Rohit,

Well all was fine until I did my last two merges from master after doing the 3.3.x integration of OVM, allocate vnet breaks and rolls back on the DB all of a sudden am trying to figure out where that is. So all bits work except for network provising for a VM (jeez luckily not important at all…), so vm rollout breaks. Am looking at where and why it breaks, but am pretty not impressed at the moment :\

Cheers,

Funs

On 02 Mar 2015, at 03:14, Rohit Yadav <notifications@github.com mailto:notifications@github.com> wrote:

@snuf https://github.com/snuf Funs how about we merge your stuff in?

—
Reply to this email directly or view it on GitHub #9 (comment).

[snuf]

Kay happy to report it was a problem in my rollout script which I changed recently cough so everything is fine, it’s just that the change left out the vlan range, so that explains a lot..

So you can go ahead and merge if you want to, I’m 3 days a way from master atm (need me to do a new pull request?).

Cheers,

Funs

On 02 Mar 2015, at 03:14, Rohit Yadav notifications@github.com wrote:

@snuf https://github.com/snuf Funs how about we merge your stuff in?

—
Reply to this email directly or view it on GitHub #9 (comment).