Github user serg38 commented on the issue:
https://github.com/apache/cloudstack/pull/1602
@syed. The default behavior won't change. The proposed enhancement will add
an ability to control link/full clone deployment of a primary storage level. If
it is not defined there a current
Github user mike-tutkowski commented on the issue:
https://github.com/apache/cloudstack/pull/1600
My mistake. I forgot that I added that a while ago. :)
On Jul 4, 2016, at 12:40 PM, Syed Mushtaq Ahmed
> wrote:
Github user syed commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1602#discussion_r69486019
--- Diff:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
---
@@ -1353,6 +1363,20 @@ public void
Github user syed commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1602#discussion_r69485338
--- Diff:
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
---
@@ -1353,6 +1363,20 @@ public void
Github user syed commented on the issue:
https://github.com/apache/cloudstack/pull/1600
@mike-tutkowski , the list snapshot already returns the `loacationType`. I
think you've already added that.
---
If your project is set up for it, you can reply to this email and have your
reply
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, backport and regression-test all those
changes.
From my personal experience, I've done a lot
Github user nvazquez commented on the issue:
https://github.com/apache/cloudstack/pull/1602
@syed adding to use cases that @serg38 mentioned, I edited PR's title which
could be confusing
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user serg38 commented on the issue:
https://github.com/apache/cloudstack/pull/1602
@syed. On Vmware using link cloned was a default behavior. The primary use
cases are:
- storage saving if underlying arrays don't support deduplication
- speed of the deployment if
Github user syed commented on the issue:
https://github.com/apache/cloudstack/pull/1600
A bit of background on how this feature works. When locationType is
specified as `Archve`, a snaphsot is taken at the storage, but the copy to
seconday storage is done via the hypervisor as it is
Github user syed commented on the issue:
https://github.com/apache/cloudstack/pull/1602
@nvazquez is there a use case where you would want some VMWare hypervisors
to not do a full clone?
---
If your project is set up for it, you can reply to this email and have your
reply appear on
> Op 4 juli 2016 om 6:57 schreef John Burwell :
>
>
> All,
>
> Following up on a our discussions about LTS [1], post 4.9 releases [2], and
> 5.0.0/6.0.0 [3], I have assembled a release plan for the next 18-20 months in
> the wiki [4]. My original proposal assumed
Github user rhtyd commented on the issue:
https://github.com/apache/cloudstack/pull/1601
@glennwagner can you also comment if you saw any unusual CPU usage? thanks
for testing this
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user wido commented on the issue:
https://github.com/apache/cloudstack/pull/1575
#1547 has been merged, so this no longer does. Maybe you want to send a new
PR and close this one?
Sorry for the conflicts though!
---
If your project is set up for it, you can reply to
Github user glennwagner commented on the issue:
https://github.com/apache/cloudstack/pull/1601
LGTM
Testing 4.9 master with pr 1601
1. Original results without PR KVM hosts failing to add , error in logs
were NIO connection errors
2. After the PR was
14 matches
Mail list logo