Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Jayapal Uradi]

Today I am working  on this PR. Hopefully I will complete it.

Yesterday fixed test_01_isolate_network_FW_PF_default_routes_egress_true, 
test_01_isolate_network_FW_PF_default_routes_egress_false. Today working on RVR 
related tests.

Thanks,
Jayapal
On May 11, 2017, at 10:38 AM, Will Stevens 
> wrote:

Is 1866 ready? It looks like CI is failing on a lot of relevant network tests.

On May 11, 2017 12:48 AM, "Jayapal Uradi" 
> wrote:
Hi Rajani,

Also please  include the PR#1866.

Thanks,
Jayapal

> On May 11, 2017, at 10:10 AM, Rajani Karuturi 
> > wrote:
>
> Thanks for testing Mike.
>
> RC3=RC2+PR#2089+Mike'sPR
>
> Any other additions?
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 7:47 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> I've been running regression tests against the release candidate.
>
> So far, all tests but one have passed.
>
> The failing test is related to the storage cleanup thread. It
> looks like some code was changed in 4.10 with regards to this
> thread and that change is causing a problem around cleanup for
> managed storage in a particular situation.
>
> As a result of this, I was going to vote -1.
>
> I'm guessing the fix will not be complicated, but is important.
>
> I don't yet have the fix, however. Once I do, I can reply to
> this thread.
>
> On May 10, 2017, at 5:47 AM, Rajani Karuturi 
> >
> wrote:
>
> I agree to your concerns Wido. I did check the PR before
> creating
> RC2. There were some outstanding comments on it.
>
> If no one has started testing RC2 and there are no objections,
> we
> can cancel this vote, quickly merge the PR and create RC3.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 3:04 PM, Wido den Hollander 
> (w...@widodh.nl)
> wrote:
>
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> >:
>
> Just to clarify. Wido, the issue you are experiencing is only
> with basic
> networks and also exists in 4.9 right? The issue becomes
> noticeable when
> you have a lot of networks. Is that a fair statement?
>
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
>
> It happens when you have a lot of VMs in those networks.
>
> In our case we have a couple of thousands VMs.
>
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
>
> However, I don't want to delay 4.10 any longer.
>
> Wido
>
> On May 9, 2017 5:39 PM, "Wido den Hollander" 
> >
> wrote:
>
> +0
>
> I don't want to VOTE -1 due to a bug we are facing, but for us
> 4.10 would
> be a problem due to the VR performance.
>
> A PR is open for this, but I also don't want to delay 4.10 any
> longer:
> https://github.com/apache/cloudstack/pull/2089
>
> Technically the VR works, it is just that deployment is utterly
> slow.
>
> Wido
>
> Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
> >:
>
> Hi All,
>
> I've created a 4.10.0.0 release, with the following artifacts up
> for a
>
> vote:
>
> Git Branch and Commit SH:
> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=
>
> fadc80d50f9e95012c9ff3644b60b600c6f65204
>
> Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
> Branch: 4.10.0.0-RC20170509T1030
>
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> PGP release keys (signed using CBB44821):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure
> to
>
> indicate
>
> "(binding)" with their vote
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> ~Rajani
> http://cloudplatform.accelerite.com/




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.





DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 

Re:Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Haijiao]

HI, Rajani



I think these 4 are ready and good for merging into RC3.


CLOUDSTACK-9690: Scale CentOS7 VM fails with error #1849
CLOUDSTACK-9017 : VPC VR DHCP broken for multihomed guest VMs #2082
CLOUDSTACK-9824: Resource count for Primary storage is considered twice - while 
creating and while attaching the disk #1992
CLOUDSTACK-9112: Deploy VM failing frequently due to capacity calculation not 
synchron… #1180






在2017年05月11 12时40分, "Rajani Karuturi"写道:

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi 
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
:

Just to clarify. Wido, the issue you are experiencing is only
with basic
networks and also exists in 4.9 right? The issue becomes
noticeable when
you have a lot of networks. Is that a fair statement?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

On May 9, 2017 5:39 PM, "Wido den Hollander" 
wrote:

+0

I don't want to VOTE -1 due to a bug we are facing, but for us
4.10 would
be a problem due to the VR performance.

A PR is open for this, but I also don't want to delay 4.10 any
longer:
https://github.com/apache/cloudstack/pull/2089

Technically the VR works, it is just that deployment is utterly
slow.

Wido

Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
:

Hi All,

I've created a 4.10.0.0 release, with the following artifacts up
for a

vote:

Git Branch and Commit SH:
https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=

fadc80d50f9e95012c9ff3644b60b600c6f65204

Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
Branch: 4.10.0.0-RC20170509T1030

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

PGP release keys (signed using CBB44821):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

Vote will be open for 72 hours.

For sanity in tallying the vote, can PMC members please be sure
to

indicate

"(binding)" with their vote

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

~Rajani

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Will Stevens]

Is 1866 ready? It looks like CI is failing on a lot of relevant network
tests.

On May 11, 2017 12:48 AM, "Jayapal Uradi" 
wrote:

Hi Rajani,

Also please  include the PR#1866.

Thanks,
Jayapal

> On May 11, 2017, at 10:10 AM, Rajani Karuturi  wrote:
>
> Thanks for testing Mike.
>
> RC3=RC2+PR#2089+Mike'sPR
>
> Any other additions?
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 7:47 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> I've been running regression tests against the release candidate.
>
> So far, all tests but one have passed.
>
> The failing test is related to the storage cleanup thread. It
> looks like some code was changed in 4.10 with regards to this
> thread and that change is causing a problem around cleanup for
> managed storage in a particular situation.
>
> As a result of this, I was going to vote -1.
>
> I'm guessing the fix will not be complicated, but is important.
>
> I don't yet have the fix, however. Once I do, I can reply to
> this thread.
>
> On May 10, 2017, at 5:47 AM, Rajani Karuturi 
> wrote:
>
> I agree to your concerns Wido. I did check the PR before
> creating
> RC2. There were some outstanding comments on it.
>
> If no one has started testing RC2 and there are no objections,
> we
> can cancel this vote, quickly merge the PR and create RC3.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
>
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
>
> Just to clarify. Wido, the issue you are experiencing is only
> with basic
> networks and also exists in 4.9 right? The issue becomes
> noticeable when
> you have a lot of networks. Is that a fair statement?
>
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
>
> It happens when you have a lot of VMs in those networks.
>
> In our case we have a couple of thousands VMs.
>
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
>
> However, I don't want to delay 4.10 any longer.
>
> Wido
>
> On May 9, 2017 5:39 PM, "Wido den Hollander" 
> wrote:
>
> +0
>
> I don't want to VOTE -1 due to a bug we are facing, but for us
> 4.10 would
> be a problem due to the VR performance.
>
> A PR is open for this, but I also don't want to delay 4.10 any
> longer:
> https://github.com/apache/cloudstack/pull/2089
>
> Technically the VR works, it is just that deployment is utterly
> slow.
>
> Wido
>
> Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
> :
>
> Hi All,
>
> I've created a 4.10.0.0 release, with the following artifacts up
> for a
>
> vote:
>
> Git Branch and Commit SH:
> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=
>
> fadc80d50f9e95012c9ff3644b60b600c6f65204
>
> Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
> Branch: 4.10.0.0-RC20170509T1030
>
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> PGP release keys (signed using CBB44821):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure
> to
>
> indicate
>
> "(binding)" with their vote
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> ~Rajani
> http://cloudplatform.accelerite.com/




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is
the property of Accelerite, a Persistent Systems business. It is intended
only for the use of the individual or entity to which it is addressed. If
you are not the intended recipient, you are not authorized to read, retain,
copy, print, distribute or use this message. If you have received this
communication in error, please notify the sender and delete all copies of
this message. Accelerite, a Persistent Systems business does not accept any
liability for virus infected mails.

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Jayapal Uradi]

Hi Rajani,

Also please  include the PR#1866.

Thanks,
Jayapal

> On May 11, 2017, at 10:10 AM, Rajani Karuturi  wrote:
>
> Thanks for testing Mike.
>
> RC3=RC2+PR#2089+Mike'sPR
>
> Any other additions?
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 7:47 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> I've been running regression tests against the release candidate.
>
> So far, all tests but one have passed.
>
> The failing test is related to the storage cleanup thread. It
> looks like some code was changed in 4.10 with regards to this
> thread and that change is causing a problem around cleanup for
> managed storage in a particular situation.
>
> As a result of this, I was going to vote -1.
>
> I'm guessing the fix will not be complicated, but is important.
>
> I don't yet have the fix, however. Once I do, I can reply to
> this thread.
>
> On May 10, 2017, at 5:47 AM, Rajani Karuturi 
> wrote:
>
> I agree to your concerns Wido. I did check the PR before
> creating
> RC2. There were some outstanding comments on it.
>
> If no one has started testing RC2 and there are no objections,
> we
> can cancel this vote, quickly merge the PR and create RC3.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
>
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
>
> Just to clarify. Wido, the issue you are experiencing is only
> with basic
> networks and also exists in 4.9 right? The issue becomes
> noticeable when
> you have a lot of networks. Is that a fair statement?
>
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
>
> It happens when you have a lot of VMs in those networks.
>
> In our case we have a couple of thousands VMs.
>
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
>
> However, I don't want to delay 4.10 any longer.
>
> Wido
>
> On May 9, 2017 5:39 PM, "Wido den Hollander" 
> wrote:
>
> +0
>
> I don't want to VOTE -1 due to a bug we are facing, but for us
> 4.10 would
> be a problem due to the VR performance.
>
> A PR is open for this, but I also don't want to delay 4.10 any
> longer:
> https://github.com/apache/cloudstack/pull/2089
>
> Technically the VR works, it is just that deployment is utterly
> slow.
>
> Wido
>
> Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
> :
>
> Hi All,
>
> I've created a 4.10.0.0 release, with the following artifacts up
> for a
>
> vote:
>
> Git Branch and Commit SH:
> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=
>
> fadc80d50f9e95012c9ff3644b60b600c6f65204
>
> Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
> Branch: 4.10.0.0-RC20170509T1030
>
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> PGP release keys (signed using CBB44821):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure
> to
>
> indicate
>
> "(binding)" with their vote
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> ~Rajani
> http://cloudplatform.accelerite.com/




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Rajani Karuturi]

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi 
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
:

Just to clarify. Wido, the issue you are experiencing is only
with basic
networks and also exists in 4.9 right? The issue becomes
noticeable when
you have a lot of networks. Is that a fair statement?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

On May 9, 2017 5:39 PM, "Wido den Hollander" 
wrote:

+0

I don't want to VOTE -1 due to a bug we are facing, but for us
4.10 would
be a problem due to the VR performance.

A PR is open for this, but I also don't want to delay 4.10 any
longer:
https://github.com/apache/cloudstack/pull/2089

Technically the VR works, it is just that deployment is utterly
slow.

Wido

Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
:

Hi All,

I've created a 4.10.0.0 release, with the following artifacts up
for a

vote:

Git Branch and Commit SH:
https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=

fadc80d50f9e95012c9ff3644b60b600c6f65204

Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
Branch: 4.10.0.0-RC20170509T1030

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

PGP release keys (signed using CBB44821):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

Vote will be open for 72 hours.

For sanity in tallying the vote, can PMC members please be sure
to

indicate

"(binding)" with their vote

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Tutkowski, Mike]

Hi,

I analyzed the problematic PR and fixed the issue this way:

https://github.com/mike-tutkowski/cloudstack/commit/c463057c82656a4d7564fc9205bb79517317c629

If a couple people could take a look at this code and see what you think, I can 
create a PR against the RC and we can make use of this code in the next RC for 
4.10.

Thanks!
Mike

On 5/10/17, 2:34 PM, "Tutkowski, Mike"  wrote:

OK, here’s the gist of the problem:

In StorageManagerImpl.cleanupStorage(boolean), the following line in 4.9

List vols = 
_volsDao.listVolumesToBeDestroyed(new Date(System.currentTimeMillis() - ((long) 
StorageCleanupDelay.value() << 10)));

was changed to the following in 4.10

// ROOT volumes will be destroyed as part of VM cleanup
List vols = 
_volsDao.listNonRootVolumesToBeDestroyed(new Date(System.currentTimeMillis() - 
((long) StorageCleanupDelay.value() << 10)));

This leads to a problem (for both managed and traditional storage) in the 
following situation:

For example: Let’s say we have a system VM running on NFS primary storage. 
We then put this primary storage into maintenance mode, which creates the 
system VM (with the same name) on a different primary storage (we do not create 
a new row in the cloud.vm_instance table for this VM). While this VM works, the 
original root disk of the system VM remains on the original primary storage and 
is not destroyed by the code in StorageManagerImpl.cleanupStorage(boolean) in 
4.10 because 4.10 (as shown above) only asks for non-root volumes to consider 
for deletion. In the 4.9 version of the code, the original root disk is cleaned 
up in StorageManagerImpl.cleanupStorage(boolean). The problem with 4.10 relying 
on a root disk always being deleted when the VM it belongs to is deleted is 
that in a situation like this that the system VM doesn’t get deleted at this 
point – it gets a new root disk that’s hosted by a different primary storage 
(so now it’s original root disk is stranded).

Here is the ticket and the PR where the code change went in:
https://issues.apache.org/jira/browse/CLOUDSTACK-9660
https://github.com/apache/cloudstack/pull/1825

To me, this needs to be fixed before we release 4.10, so I am -1 on this RC.

My suggestion would be to basically revert PR 1825 and to make use of just 
bits and pieces of it.

For example, this part should be kept:

-
volService.expungeVolumeAsync(volFactory.getVolume(vol.getId()));
 +VolumeInfo volumeInfo = 
volFactory.getVolume(vol.getId());
 +if (volumeInfo != null) {
 +volService.expungeVolumeAsync(volumeInfo);
 +} else {
 +s_logger.debug("Volume " + vol.getUuid() 
+ " is already destroyed");
 +}

On 5/10/17, 8:17 AM, "Tutkowski, Mike"  wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It looks 
like some code was changed in 4.10 with regards to this thread and that change 
is causing a problem around cleanup for managed storage in a particular 
situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to this 
thread.

> On May 10, 2017, at 5:47 AM, Rajani Karuturi  
wrote:
> 
> I agree to your concerns Wido. I did check the PR before creating
> RC2. There were some outstanding comments on it.
> 
> If no one has started testing RC2 and there are no objections, we
> can cancel this vote, quickly merge the PR and create RC3.
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
> 
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
> 
> Just to clarify. Wido, the issue you are experiencing is only
> with basic
> networks and also exists in 4.9 right? The issue becomes
> noticeable when
> you have a lot of networks. Is that a fair statement?
> 
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
> 
> It happens when you have a lot of VMs in those networks.
> 
> In our case we have a couple of thousands VMs.
> 
> 

Re: GSoC'17

[Syed Ahmed]

Sverrir,

I had looked at Guacamole before I settled with NoVNC for this proposal. I
found Guacamole to be too heavy to be an integral part of Cloudstack. You
require another database setup and the users have to somehow be matched.
I'd be interested to know more about your approach to this.

Thanks,
-Syed

On Tue, May 9, 2017 at 2:23 AM, Erik Weber  wrote:

> On Fri, May 5, 2017 at 6:30 PM, Sverrir Berg 
> wrote:
> > Congratulations with the selection!
> >
> > We at Greenqloud have been using NoVNC as integral part of Qstack until
> > recently.
>
> Why not upstream it? ;-)
>
> > We are now using Apache Guacamole
> > https://guacamole.incubator.apache.org/.
>
> Why not upstream it? ;-)
>
>
> --
> Erik
>

Re: Awesome CloudStack

[Rene Moser]

Hi Will

On 05/10/2017 07:49 PM, Will Stevens wrote:
> Awesome!!!  Great initiative Rene.  You going to be at ApacheCon in Miami?

Sad to say but no, I can not make it.

> Maybe we can give this list a bit of airtime to give it some more
> visibility.  :)

That would be awesome! ;)

Re: Awesome CloudStack

[Rene Moser]

On 05/10/2017 08:50 PM, Gabriel Beims Bräscher wrote:
> I work in the development of the Autonomiccs plugin; a plugin that
> autonomously manages environments orchestrated by Apache CloudStack (more
> details at [1]). Do you believe that it would be interesting adding plugins
> such as Autonomiccs to your project?

And yes! This sound pretty much like an awesome project! ;)

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Tutkowski, Mike]

OK, here’s the gist of the problem:

In StorageManagerImpl.cleanupStorage(boolean), the following line in 4.9

List vols = _volsDao.listVolumesToBeDestroyed(new 
Date(System.currentTimeMillis() - ((long) StorageCleanupDelay.value() << 10)));

was changed to the following in 4.10

// ROOT volumes will be destroyed as part of VM cleanup
List vols = 
_volsDao.listNonRootVolumesToBeDestroyed(new Date(System.currentTimeMillis() - 
((long) StorageCleanupDelay.value() << 10)));

This leads to a problem (for both managed and traditional storage) in the 
following situation:

For example: Let’s say we have a system VM running on NFS primary storage. We 
then put this primary storage into maintenance mode, which creates the system 
VM (with the same name) on a different primary storage (we do not create a new 
row in the cloud.vm_instance table for this VM). While this VM works, the 
original root disk of the system VM remains on the original primary storage and 
is not destroyed by the code in StorageManagerImpl.cleanupStorage(boolean) in 
4.10 because 4.10 (as shown above) only asks for non-root volumes to consider 
for deletion. In the 4.9 version of the code, the original root disk is cleaned 
up in StorageManagerImpl.cleanupStorage(boolean). The problem with 4.10 relying 
on a root disk always being deleted when the VM it belongs to is deleted is 
that in a situation like this that the system VM doesn’t get deleted at this 
point – it gets a new root disk that’s hosted by a different primary storage 
(so now it’s original root disk is stranded).

Here is the ticket and the PR where the code change went in:
https://issues.apache.org/jira/browse/CLOUDSTACK-9660
https://github.com/apache/cloudstack/pull/1825

To me, this needs to be fixed before we release 4.10, so I am -1 on this RC.

My suggestion would be to basically revert PR 1825 and to make use of just bits 
and pieces of it.

For example, this part should be kept:

-
volService.expungeVolumeAsync(volFactory.getVolume(vol.getId()));
 +VolumeInfo volumeInfo = 
volFactory.getVolume(vol.getId());
 +if (volumeInfo != null) {
 +volService.expungeVolumeAsync(volumeInfo);
 +} else {
 +s_logger.debug("Volume " + vol.getUuid() + " 
is already destroyed");
 +}

On 5/10/17, 8:17 AM, "Tutkowski, Mike"  wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It looks like 
some code was changed in 4.10 with regards to this thread and that change is 
causing a problem around cleanup for managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to this thread.

> On May 10, 2017, at 5:47 AM, Rajani Karuturi  wrote:
> 
> I agree to your concerns Wido. I did check the PR before creating
> RC2. There were some outstanding comments on it.
> 
> If no one has started testing RC2 and there are no objections, we
> can cancel this vote, quickly merge the PR and create RC3.
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
> 
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
> 
> Just to clarify. Wido, the issue you are experiencing is only
> with basic
> networks and also exists in 4.9 right? The issue becomes
> noticeable when
> you have a lot of networks. Is that a fair statement?
> 
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
> 
> It happens when you have a lot of VMs in those networks.
> 
> In our case we have a couple of thousands VMs.
> 
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
> 
> However, I don't want to delay 4.10 any longer.
> 
> Wido
> 
> On May 9, 2017 5:39 PM, "Wido den Hollander" 
> wrote:
> 
> +0
> 
> I don't want to VOTE -1 due to a bug we are facing, but for us
> 4.10 would
> be a problem due to the VR performance.
> 
> A PR is open for this, but I also don't want to delay 4.10 any
> longer:
> https://github.com/apache/cloudstack/pull/2089
> 
> Technically the VR works, it is just that deployment is utterly
> slow.
> 
> Wido
> 
> Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
> 

Re: Awesome CloudStack

[Rene Moser]

Hi Gabriel

On 05/10/2017 08:50 PM, Gabriel Beims Bräscher wrote:
> Hi Rene,
> 
> That is a great idea!
> 
> Is the content related to any project that is linked somehow with Apache
> CloudStack?

As simple as anything "awesome" or let's say useful that is related to
the CloudStack ecosystem. What it ever may be!

The idea of awesome lists is not invented here, see
https://github.com/sindresorhus/awesome.

Re: [PROPOSAL] Separate creation and backup operations for a volume snapshot

[Syed Ahmed]

Oops I meant Harika, I know that Nathan you were working on something like
this a while back with Ceph so I assumed you where the one who proposed
this. Anyways, Harika, look at the locationType parameter in the
CreateSnaphsot API command. This is what you are looking to implement. Note
that this currently only works for Managed storage (SolidFire) so you'd
have to work it into the standard non-managed storage.

Let me know if you have any questions.

Thanks,
-Syed


On Wed, May 10, 2017 at 3:24 PM, Syed Ahmed  wrote:

> Hi Nathan,
>
> This option to choose between primary and secondary was added by me a
> while back. You want to look at
>
> https://github.com/apache/cloudstack/pull/1600
>
>
> On Tue, May 9, 2017 at 10:09 AM, Nathan Johnson  wrote:
>
>> Harika Punna  wrote:
>> >
>> > Currently, Volume Snapshots in Cloudstack take considerable amount of
>> > time to complete as snapshot involves creation on primary and backup on
>> > secondary. I would like to introduce an optional parameter in
>> > CreateSnapshotCmd API to separate these operations.
>> >
>> >
>> > More details in the FS:
>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Separ
>> ate+creation+and+backup+operations+for+a+volume+snapshot
>> >
>> >
>> > Thanks,
>> > Harika.
>>
>> Hello Harika.  There was a related discussion around a global
>> configuration
>> parameter snapshot.backup.rightafter
>>
>> See the thread here:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-4858
>>
>> And here is the PR where this was merged into 4.9:
>>
>> https://github.com/apache/cloudstack/pull/1697
>>
>> This is distinct from what you propose, and I like the idea of being able
>> to specify whether or not to back up at snapshot creation time, versus
>> only
>> having a global configuration parameter.
>>
>> Also one remaining issue with the current implementation of snapshots and
>> backups is that if the snapshot.backup.rightafter parameter is set to
>> false, on doing certain operations with snapshots (create template from
>> snapshot iirc, perhaps some others) it will then need to take the backup
>> to
>> secondary at that time, and it will be very slow.  I think at some point
>> you have to take that hit, so maybe there is no way around this.
>>
>> But that brings me to a followup point: since the PR was merged above, ACS
>> will backup on-demand any snapshots that need to be on secondary that only
>> exist on primary. it would be nice to also have an optional cleanup thread
>> and an expiration of backups to secondary.  Or maybe API endpoints that
>> would allow some external management of backups.
>>
>> What do you think?
>>
>>
>> Nathan Johnson
>> R Engineer
>> Education Networks of America
>>
>>
>

Re: [PROPOSAL] Separate creation and backup operations for a volume snapshot

[Syed Ahmed]

Hi Nathan,

This option to choose between primary and secondary was added by me a while
back. You want to look at

https://github.com/apache/cloudstack/pull/1600


On Tue, May 9, 2017 at 10:09 AM, Nathan Johnson  wrote:

> Harika Punna  wrote:
> >
> > Currently, Volume Snapshots in Cloudstack take considerable amount of
> > time to complete as snapshot involves creation on primary and backup on
> > secondary. I would like to introduce an optional parameter in
> > CreateSnapshotCmd API to separate these operations.
> >
> >
> > More details in the FS:
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> Separate+creation+and+backup+operations+for+a+volume+snapshot
> >
> >
> > Thanks,
> > Harika.
>
> Hello Harika.  There was a related discussion around a global configuration
> parameter snapshot.backup.rightafter
>
> See the thread here:
> https://issues.apache.org/jira/browse/CLOUDSTACK-4858
>
> And here is the PR where this was merged into 4.9:
>
> https://github.com/apache/cloudstack/pull/1697
>
> This is distinct from what you propose, and I like the idea of being able
> to specify whether or not to back up at snapshot creation time, versus only
> having a global configuration parameter.
>
> Also one remaining issue with the current implementation of snapshots and
> backups is that if the snapshot.backup.rightafter parameter is set to
> false, on doing certain operations with snapshots (create template from
> snapshot iirc, perhaps some others) it will then need to take the backup to
> secondary at that time, and it will be very slow.  I think at some point
> you have to take that hit, so maybe there is no way around this.
>
> But that brings me to a followup point: since the PR was merged above, ACS
> will backup on-demand any snapshots that need to be on secondary that only
> exist on primary. it would be nice to also have an optional cleanup thread
> and an expiration of backups to secondary.  Or maybe API endpoints that
> would allow some external management of backups.
>
> What do you think?
>
>
> Nathan Johnson
> R Engineer
> Education Networks of America
>
>

Re: Awesome CloudStack

[Gabriel Beims Bräscher]

Hi Rene,

That is a great idea!

Is the content related to any project that is linked somehow with Apache
CloudStack? For instance, what about plugins that are not in the Apache
CloudStack codebase?

I work in the development of the Autonomiccs plugin; a plugin that
autonomously manages environments orchestrated by Apache CloudStack (more
details at [1]). Do you believe that it would be interesting adding plugins
such as Autonomiccs to your project?

Best Regards,
Gabriel.

[1] autonomiccs.com.br

2017-05-10 14:49 GMT-03:00 Will Stevens :

> Awesome!!!  Great initiative Rene.  You going to be at ApacheCon in Miami?
> Maybe we can give this list a bit of airtime to give it some more
> visibility.  :)
>
> *Will Stevens*
> CTO
>
> 
>
> On Wed, May 10, 2017 at 1:23 PM, Rene Moser  wrote:
>
> > Hi
> >
> > I started "A curated list of bookmarks, packages, tutorials, videos and
> > other cool resources from the CloudStack ecosystem" on
> > https://github.com/resmo/awesome-cloudstack
> >
> > Feel free to extend it by sending PRs ;)
> >
> > René
> >
>

Re: Awesome CloudStack

[Will Stevens]

Awesome!!!  Great initiative Rene.  You going to be at ApacheCon in Miami?
Maybe we can give this list a bit of airtime to give it some more
visibility.  :)

*Will Stevens*
CTO



On Wed, May 10, 2017 at 1:23 PM, Rene Moser  wrote:

> Hi
>
> I started "A curated list of bookmarks, packages, tutorials, videos and
> other cool resources from the CloudStack ecosystem" on
> https://github.com/resmo/awesome-cloudstack
>
> Feel free to extend it by sending PRs ;)
>
> René
>

Awesome CloudStack

[Rene Moser]

Hi

I started "A curated list of bookmarks, packages, tutorials, videos and
other cool resources from the CloudStack ecosystem" on
https://github.com/resmo/awesome-cloudstack

Feel free to extend it by sending PRs ;)

René

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Tutkowski, Mike]

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It looks like some 
code was changed in 4.10 with regards to this thread and that change is causing 
a problem around cleanup for managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to this thread.

> On May 10, 2017, at 5:47 AM, Rajani Karuturi  wrote:
> 
> I agree to your concerns Wido. I did check the PR before creating
> RC2. There were some outstanding comments on it.
> 
> If no one has started testing RC2 and there are no objections, we
> can cancel this vote, quickly merge the PR and create RC3.
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
> 
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
> 
> Just to clarify. Wido, the issue you are experiencing is only
> with basic
> networks and also exists in 4.9 right? The issue becomes
> noticeable when
> you have a lot of networks. Is that a fair statement?
> 
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
> 
> It happens when you have a lot of VMs in those networks.
> 
> In our case we have a couple of thousands VMs.
> 
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
> 
> However, I don't want to delay 4.10 any longer.
> 
> Wido
> 
> On May 9, 2017 5:39 PM, "Wido den Hollander" 
> wrote:
> 
> +0
> 
> I don't want to VOTE -1 due to a bug we are facing, but for us
> 4.10 would
> be a problem due to the VR performance.
> 
> A PR is open for this, but I also don't want to delay 4.10 any
> longer:
> https://github.com/apache/cloudstack/pull/2089
> 
> Technically the VR works, it is just that deployment is utterly
> slow.
> 
> Wido
> 
> Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
> :
> 
> Hi All,
> 
> I've created a 4.10.0.0 release, with the following artifacts up
> for a
> 
> vote:
> 
> Git Branch and Commit SH:
> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=
> 
> fadc80d50f9e95012c9ff3644b60b600c6f65204
> 
> Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
> Branch: 4.10.0.0-RC20170509T1030
> 
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
> 
> PGP release keys (signed using CBB44821):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> 
> Vote will be open for 72 hours.
> 
> For sanity in tallying the vote, can PMC members please be sure
> to
> 
> indicate
> 
> "(binding)" with their vote
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> ~Rajani
> http://cloudplatform.accelerite.com/

Re: ovf file parser

[Will Stevens]

Hey Abhi,
I am not sure where an ISO comes into play.  I did not work with any ISOs
in my flow.  Maybe the OVA is generated in a different way?  Do you have
control over the way the OVA is created?

I was using the following command to export a VM from VMware using the
'ovftool', which would produce my OVA file:

ovftool -o --powerOffSource --noSSLVerify --acceptAllEulas
--maxVirtualHardwareVersion= -tt=OVA
-n=
"vi://:@?moref=vim.VirtualMachine:"


-  is the name according to the ACS naming conventions.
- ,  and  are pretty obvious I think.
-  is where you want the file to be saved to.
-  is the ID of the VM in VMware (described below).
- When migrating from a more recent version of VMware to a previous version
of VMware, you will need to specify the 
setting to reflect the destination VMware version.  The possible settings
and the respective VMware version supported are listed below.
10 - Supports: ESXi 5.5, Fusion 6.x, Workstation 10.x, Player 6.x
9 - Supports: ESXi 5.1, Fusion 5.x, Workstation 9.x, Player 5.x
8 - Supports: ESXi 5.0, Fusion 4.x, Workstation 8.x, Player 4.x
7 - Supports: ESXi/ESX 4.x, Fusion 3.x, Fusion 2.x, Workstation 7.x,
Workstation 6.5.x, Player 3.x, Server 2.x
6 - Supports: Workstation 6.0.x
4 - Supports: ACE 2.x, ESX 3.x, Fusion 1.x, Player 2.x
3 and 4 - Supports: ACE 1.x, Lab Manager 2.x, Player 1.x, Server 1.x,
Workstation 5.x, Workstation 4.x
3 - Supports: ESX 2.x, GSX Server 3.x


For me, since I was discovering the entire source VMware environment and
listing all possible VMs which could be migrated, I had to find a way to
bulk discover VMs.  I did that using the MORTypes using the 'pyshere'
Python package.  The MORTypes are a bit complicated to work with, but they
are a LOT faster, so it was worth it in my case.  I used the following to
get the  listed above.  It is worth noting that this is the only way
I was able to consistently be able to export 'ANY' VM from VMware without
having things like VM naming conventions or cluster placement and such
causing problems.

```
mors = vmware._get_managed_objects(MORTypes.VirtualMachine).keys()
props = {
MORTypes.VirtualMachine:['name', 'config.files.vmPathName'],
}
result = vmware._get_object_properties_bulk(mors, props)
for vm_item in result:
vm_id = vm_item.Obj
```

This export process consistently gave me an OVA in the following format:
vm-name.ova
|-- vm-name.ovf
|-- vm-name-disk1.vmdk
|-- vm-name-disk2.vmdk
|-- vm-name-disk3.vmdk
|-- manifest.txt(?)

With these files, I would make a few directories to simplify the
modification and creation of the OVA per disk.

vm-name-disk1
|-- vm-name.ova (modified)
|-- vm-name-disk1.vmdk

vm-name-disk2
|-- vm-name.ova (modified)
|-- vm-name-disk2.vmdk

vm-name-disk3
|-- vm-name.ova (modified)
|-- vm-name-disk3.vmdk

Which I would then re-tar back into an OVA file to produce:

vm-name-disk1.ova (ACS Template)
vm-name-disk2.ova (Data Volume)
vm-name-disk3.ova (Data Volume)

I then uploaded all of these to ACS via a local file server and launched
the VM from the Template OVA once ready.  After the VM had successfully
launched, I would then attach each of the Data Volumes which I had
previously uploaded.

Given that my flow seems to be slightly different since I never used an
ISO, I am not sure the following is the cause of your current problem, but
I suspect it is.

I had no problems exporting and importing VMs with drives that used the
SCSI controller in VMware, however, I was never able to get VMs with an IDE
controller to work.  Drives with an IDE controller always gave me the same
problem, they would hang at boot because the "root partition could not be
found".  Because I was under time pressure and because my client did not
use drives with IDE controllers, I did not attempt to automate the recovery
for this problem.  I suspect manual intervention is required in order to
modify the MBR to make the disk bootable.

Not sure this was helpful, but hopefully it gets you farther down your road
of troubleshooting this.

Cheers,

*Will Stevens*
CTO



On Wed, May 10, 2017 at 6:56 AM, Abhinandan Prateek <
abhinandan.prat...@shapeblue.com> wrote:

> Hi Will,
>
>   We have hit some road blocks. The main issue here is that cloudstack
> sees the VM as a set of disks, while a OVA contains VM definition including
> instructions on pre boot steps, delays and maybe more. So even if we are
> able to reliably get disks from the OVA and orchestrate these with vCenter,
> we still may end up with some non-booting VM. Following is the flow:
>
> 1. Split the OVA into disks and iso, assume boot disk.
> 2. Boot disk is the parent template and rest of the disks and iso are
> child templates, created in cloudstack.
> 3. Map disk offerings to disks, cloudstack then orchestrates the boot disk
> and additional disks as a venter VM.
> 4. Attach the ISO.
>
> This works with some limitations. The cloudstack VMs exported as OVA work,
> but some of the appliances 

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Rajani Karuturi]

I agree to your concerns Wido. I did check the PR before creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections, we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
:

Just to clarify. Wido, the issue you are experiencing is only
with basic
networks and also exists in 4.9 right? The issue becomes
noticeable when
you have a lot of networks. Is that a fair statement?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

On May 9, 2017 5:39 PM, "Wido den Hollander" 
wrote:

+0

I don't want to VOTE -1 due to a bug we are facing, but for us
4.10 would
be a problem due to the VR performance.

A PR is open for this, but I also don't want to delay 4.10 any
longer:
https://github.com/apache/cloudstack/pull/2089

Technically the VR works, it is just that deployment is utterly
slow.

Wido

Op 9 mei 2017 om 7:31 schreef Rajani Karuturi
:

Hi All,

I've created a 4.10.0.0 release, with the following artifacts up
for a

vote:

Git Branch and Commit SH:
https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=

fadc80d50f9e95012c9ff3644b60b600c6f65204

Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
Branch: 4.10.0.0-RC20170509T1030

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

PGP release keys (signed using CBB44821):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

Vote will be open for 72 hours.

For sanity in tallying the vote, can PMC members please be sure
to

indicate

"(binding)" with their vote

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

~Rajani
http://cloudplatform.accelerite.com/

Re: ovf file parser

[Abhinandan Prateek]

Hi Will,

  We have hit some road blocks. The main issue here is that cloudstack sees the 
VM as a set of disks, while a OVA contains VM definition including instructions 
on pre boot steps, delays and maybe more. So even if we are able to reliably 
get disks from the OVA and orchestrate these with vCenter, we still may end up 
with some non-booting VM. Following is the flow:

1. Split the OVA into disks and iso, assume boot disk.
2. Boot disk is the parent template and rest of the disks and iso are child 
templates, created in cloudstack.
3. Map disk offerings to disks, cloudstack then orchestrates the boot disk and 
additional disks as a venter VM.
4. Attach the ISO.
  
This works with some limitations. The cloudstack VMs exported as OVA work, but 
some of the appliances that I tested it with show errors on vCenter and 
checking the console reveals booting problem. Have you faced similar issues ? 
How do we go about these. I am not sure if you are in a position to share parts 
of the work that might be relevant. We have kept our PR private as it is still 
under works, but if it is useful we can share it. Basically it is based on 
previous similar effort.

Regards,
-abhi




abhinandan.prat...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

On 04/05/17, 3:06 PM, "Abhinandan Prateek"  
wrote:

>
>The template generation related actions are better done on SSVM as they will 
>be dealing/moving with various data/boot disks. Vim(VMWare infrastructure 
>management), works with vCenter context and as such cannot be used inside 
>SSVM. Vim gives a much better validation of OVF as it can make compatibility 
>checks with vCenter. Currently it is part of vmware hypervisor plugin. Due to 
>these dependency I ended parsing and generating OVF using standard dom api.
>Due to the nature of OVF we also ended up making several assumptions. Like the 
>one that says the first disk is the boot disk. The few OVF file that I have 
>seems to work for now. (Other than that the one OVA had second disk as boot 
>disk). Though the OVF file does contain the OS of the VM but weirdly it does 
>not link it to the disk that has it.
>
>
>Regards,
>-abhi
>
>
>
>On 03/05/17, 5:57 PM, "Will Stevens"  wrote:
>
>>Cool. Let me know if you have questions.
>>
>>My instinct is that we probably want to keep the Ova manipulation in the
>>context of vmware since I don't believe it will be used outside that
>>context. Trying to manipulate the ovf files with generic tools may prove to
>>be more complicated to manage going forward as it is almost guaranteed to
>>require some 'hacks' to make it work. If we can avoid those by using the
>>vim jars, it may be worth it. I have not reviewed anything on the vim jars
>>side, so I don't know how good of an option that is.
>>
>>Are there key benefits to not using the vim jars?
>>
>>Cheers,
>>
>>Will
>>
>>On May 3, 2017 3:34 AM, "Abhinandan Prateek" <
>>abhinandan.prat...@shapeblue.com> wrote:
>>
>>> Hi Will,
>>>
>>>I am improving the multiple disk OVA feature. As part of revamp I am
>>> moving out some OVF manipulation code from the vmware hypervisor plugin
>>> context to secondary storage component. The existing code was using vim25
>>> and managed objects to query and rewrite the OVF file. I have rewritten
>>> that, using standard java w3c dom parser.
>>>
>>>The overall flow is mostly similar and as below:
>>> 1. Decompress OVA and read the OVF file. OVF file will give information
>>> about various disks
>>> 3. Create the regular cloudstack template out for the boot disk and
>>> rewrite the OVF file, minus the information about other disks.
>>> 4. For each additional disk create data disk templates and capture the
>>> relationship in db.
>>> 5. This can then be followed by creating the multi-disk cloudstack VM.
>>>
>>> Essentially I am rewriting the original OVF file after removing the File
>>> and Disk information that refers to the other disks.  Given that the the
>>> VMWare is picky, I think it will require some more cleanup and massaging.
>>> Your inputs will definitely help.
>>>
>>> Overall I think the two pieces, the tool that you have and the cloudstack
>>> multi disk OVA functionality can nicely complement each other. Will post my
>>> learning here.
>>>
>>> Thanks and regards,
>>> -abhi
>>>
>>>
>>>
>>>
>>> On 02/05/17, 6:05 PM, "williamstev...@gmail.com on behalf of Will
>>> Stevens" 
>>> wrote:
>>>
>>> >Hey Abhinandan,
>>> >First, can you give us a bit more context regarding what you are doing so
>>> >we can highlight potential areas to watch out for?  I have done some OVF
>>> >parsing/modification and there are a bunch of gotchas to be aware of.  I
>>> >will try to outline some of the ones I found.  I have not tried to use the
>>> >vim25.jar, so I can't really help on that front.
>>> >
>>> >In my use case, I was 

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Wido den Hollander]

> Op 10 mei 2017 om 0:33 schreef Will Stevens :
> 
> 
> Just to clarify. Wido, the issue you are experiencing is only with basic
> networks and also exists in 4.9 right? The issue becomes noticeable when
> you have a lot of networks. Is that a fair statement?

Well, the provisioning is the same between Basic and Advanced. The VR is 
utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

> 
> On May 9, 2017 5:39 PM, "Wido den Hollander"  wrote:
> 
> > +0
> >
> > I don't want to VOTE -1 due to a bug we are facing, but for us 4.10 would
> > be a problem due to the VR performance.
> >
> > A PR is open for this, but I also don't want to delay 4.10 any longer:
> > https://github.com/apache/cloudstack/pull/2089
> >
> > Technically the VR works, it is just that deployment is utterly slow.
> >
> > Wido
> >
> > > Op 9 mei 2017 om 7:31 schreef Rajani Karuturi :
> > >
> > >
> > > Hi All,
> > >
> > > I've created a 4.10.0.0 release, with the following artifacts up for a
> > vote:
> > >
> > > Git Branch and Commit SH:
> > > https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=
> > fadc80d50f9e95012c9ff3644b60b600c6f65204
> > > Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204
> > > Branch: 4.10.0.0-RC20170509T1030
> > >
> > > Source release (checksums and signatures are available at the same
> > > location):
> > > https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
> > >
> > > PGP release keys (signed using CBB44821):
> > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > >
> > > Vote will be open for 72 hours.
> > >
> > > For sanity in tallying the vote, can PMC members please be sure to
> > indicate
> > > "(binding)" with their vote
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)
> > >
> > > ~Rajani
> > > http://cloudplatform.accelerite.com/
> >