[GitHub] cloudstack pull request #1605: CLOUDSTACK-9428: Fix for CLOUDSTACK-9211 - Im...

Github user sateesh-chodapuneedi commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1605#discussion_r69677623 --- Diff: plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java --- @@ -2015,19 +2016,20 @@ protected

[GitHub] cloudstack pull request #1605: CLOUDSTACK-9428: Fix for CLOUDSTACK-9211 - Im...

Github user sateesh-chodapuneedi commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1605#discussion_r69677503 --- Diff: plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java --- @@ -2015,19 +2016,20 @@ protected

[GitHub] cloudstack issue #1605: CLOUDSTACK-9428: Fix for CLOUDSTACK-9211 - Improve p...

Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1605 In general, a good idea. I've not tested it though. @nvazquez can you re-kick Jenkins by pushing -f on the PR --- If your project is set up for it, you can reply to this email and have your

Re: Roadmap for 4.x and 5.0

Marc You are correct that my shell script is not most robust - it should be re-written in java - and called upon on "graceful" shutdown - this script should be treated as POC i guess. What it guards against - is more than just snapshots though. Basically - any async operation that would be

[GitHub] cloudstack pull request #1605: CLOUDSTACK-9428: Fix for CLOUDSTACK-9211 - Im...

GitHub user nvazquez opened a pull request: https://github.com/apache/cloudstack/pull/1605 CLOUDSTACK-9428: Fix for CLOUDSTACK-9211 - Improve performance JIRA TICKET: https://issues.apache.org/jira/browse/CLOUDSTACK-9428 ### Introduction On #1310 passing vRAM size

[GitHub] cloudstack issue #1604: improvement: systemvm slow operations

Github user romain-dartigues commented on the issue: https://github.com/apache/cloudstack/pull/1604 @syed > there could be a possibility of having an ipv6 gateway Right, but IPv6 does not use ARP but [NDP](https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol)

Re: [PROPOSAL] 2016-2017 Release Cycle and Calendar

Wido, I don’t think that Rohit is advocating expanding the 4.9.0 scope. Instead, he is saying that proceeding with LTS on 4.8.0.1 would be counterproductive. 4.8.0 was released in January meaning that 4.9 will contain nearly 6 months of defect fixes and enhancements. Had we cut LTS last

[GitHub] cloudstack issue #1600: Support Backup of Snapshots for Managed Storage

Github user syed commented on the issue: https://github.com/apache/cloudstack/pull/1600 @mike-tutkowski I've fixed the problem where the volume was not being detached after the copy. --- If your project is set up for it, you can reply to this email and have your reply appear on

[GitHub] cloudstack issue #1602: CLOUDSTACK-9422: Granular 'vmware.create.full.clone'...

Github user nvazquez commented on the issue: https://github.com/apache/cloudstack/pull/1602 Thanks @syed for your comments! I agree with @serg38 that extension to other hypervisors could be done in a separate PR --- If your project is set up for it, you can reply to this email

[GitHub] cloudstack issue #1602: CLOUDSTACK-9422: Granular 'vmware.create.full.clone'...

Github user serg38 commented on the issue: https://github.com/apache/cloudstack/pull/1602 @syed. Absolutely it can although the effort seems to be well beyond and scope of this PR. @nvazquez and I have only access to vmware hypervisors at this point. If there is an interest to expand

[GitHub] cloudstack issue #1603: Vrouter fixes pylint

Github user The-Loeki commented on the issue: https://github.com/apache/cloudstack/pull/1603 Hi :) sorry I was unable to process your request to merge your PR with mine, as you can probably tell by now this would've oversized & muddied both PR's ;) Depending on the uptake of the

[GitHub] cloudstack issue #1586: CLOUDSTACK-9410 Data Disk shown as detached in XS

Github user syed commented on the issue: https://github.com/apache/cloudstack/pull/1586 agree with @yvsubhash. I don't see an need to set the name-label to `detached` the code LGTM --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub

[GitHub] cloudstack issue #1602: CLOUDSTACK-9422: Granular 'vmware.create.full.clone'...

Github user syed commented on the issue: https://github.com/apache/cloudstack/pull/1602 Thanks @serg38 my question is more along the lines of can this `fullClone`/ `linkedClone` functionality be extended to other hypervisors, in that case, we can make the code hypervisor agnostic. If

[GitHub] cloudstack issue #1604: improvement: systemvm slow operations

Github user syed commented on the issue: https://github.com/apache/cloudstack/pull/1604 @romain-dartigues do we know why the `arping` is failing? Ideally, if the vif is configured correctly, the arping should go through properly. If the `arping` fails, do we still know that the

[GitHub] cloudstack pull request #1604: improvement: systemvm slow operations

Github user syed commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1604#discussion_r69583623 --- Diff: systemvm/patches/debian/config/opt/cloud/bin/merge.py --- @@ -228,7 +228,7 @@ def processCLItem(self, num, nw_type): if('localgw'

[GitHub] cloudstack issue #1603: Vrouter fixes pylint

Github user romain-dartigues commented on the issue: https://github.com/apache/cloudstack/pull/1603 Hi @The-Loeki, and thank you for your prompt comment! For your side notes: * this is mostly a preference, I don't care what you use but here are my argument for the

[GitHub] cloudstack issue #1603: Vrouter fixes pylint

Github user The-Loeki commented on the issue: https://github.com/apache/cloudstack/pull/1603 kudos for all the hard work! Most of this should've been done a long time ago as `pylint` is one of the first firewalls of code quality ensurance. Side notes: * no fan of `%s`

[GitHub] cloudstack pull request #1604: improvement: systemvm slow operations

GitHub user romain-dartigues opened a pull request: https://github.com/apache/cloudstack/pull/1604 improvement: systemvm slow operations On our setup we had issues with vrouters when a large number of VM were created at once. The vrouters try to arping the gateway (to

[GitHub] cloudstack issue #1599: Independent marvin

Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1599 @wido yes, with this PR we can split marvin to its own repository. As an example to show it's doable, here is a repository I extracted from cloudstack master -- https://github.com/rhtyd/marvin

[GitHub] cloudstack issue #1599: Independent marvin

Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/1599 This is just there to get the ground work done for Marvin to it's own repo? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your

Re: [PROPOSAL] 2016-2017 Release Cycle and Calendar

> Op 4 juli 2016 om 18:17 schreef Rohit Yadav : > > > I think 4.9 brings some new features, enhancements and improvements that > people would appreciate in a LTS release. Many of them cannot be simply > backported and 2 weeks will be far shorter to identify,

[GitHub] cloudstack pull request #1575: systemvm - Python code cleanup

Github user romain-dartigues closed the pull request at: https://github.com/apache/cloudstack/pull/1575 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the

[GitHub] cloudstack issue #1575: systemvm - Python code cleanup

Github user romain-dartigues commented on the issue: https://github.com/apache/cloudstack/pull/1575 As suggested by @wido, rebase + new pull request in #1603. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your

[GitHub] cloudstack pull request #1603: Vrouter fixes pylint

GitHub user romain-dartigues opened a pull request: https://github.com/apache/cloudstack/pull/1603 Vrouter fixes pylint In my dreams, all Python code pass through pylint and must validate before a merge. This merge request is becoming quite big, maybe too much; I'd like to