Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1753
Trillian test result (tid-684)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 77996 seconds
Marvin logs:
https://github.com/blueoranguta
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1753
Trillian test result (tid-685)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 46946 seconds
Marvin logs:
https://github.com/blueoranguta
Github user rhtyd commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1726#discussion_r92754533
--- Diff: server/src/com/cloud/storage/StorageManagerImpl.java ---
@@ -2199,15 +2199,20 @@ public void cleanupDownloadUrls(){
if(downlo
Github user yvsubhash commented on the issue:
https://github.com/apache/cloudstack/pull/1726
@rhtyd Can you please merge this
---
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
en
On 2016-12-16 11:27, Syahrul Sazli Shaharir wrote:
On Wed, 26 Oct 2016, Linas ?ilinskas wrote:
So after some investigation I've found out that qemu 2.3.0 is indeed
broken, at least the way CS uses the qemu chardev/socket.
Not sure in which specific version it happened, but it was fixed in
2.
On Wed, 26 Oct 2016, Linas ?ilinskas wrote:
So after some investigation I've found out that qemu 2.3.0 is indeed broken,
at least the way CS uses the qemu chardev/socket.
Not sure in which specific version it happened, but it was fixed in
2.4.0-rc3, specifically noting that CloudStack 4.2 was
Github user mike-tutkowski commented on the issue:
https://github.com/apache/cloudstack/pull/1749
The semi-unusual part about this PR, @rhtyd, is that is contains code
jointly developed by me and @syed.
He has reviewed my contributions and I have reviewed his.
We just
Github user mike-tutkowski commented on the issue:
https://github.com/apache/cloudstack/pull/1749
Hi @rhtyd We have one LTGM (from @syed) and I have run and posted all
regression tests for managed storage. If we could have one more person take a
look, that would be great. I don't thin
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1749
Trillian test result (tid-683)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 46910 seconds
Marvin logs:
https://github.com/blueoranguta
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1753
Trillian test result (tid-679)
Environment: xenserver-65sp1 (x2), Advanced Networking with Mgmt server 6
Total time taken: 53078 seconds
Marvin logs:
https://github.com/blueoran
Github user syed commented on the issue:
https://github.com/apache/cloudstack/pull/1829
@koushik-das I like that fix. I've modified my fix to do a better check.
@rhtyd I've rebased to 4.9 as well.
Thank you guys for the prompt replies :)
---
If your project is set up for it, yo
Github user marcaurele commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1832#discussion_r92676861
--- Diff:
engine/orchestration/src/com/cloud/agent/manager/AgentAttache.java ---
@@ -399,10 +414,22 @@ public void send(final Request req, final Liste
Github user marcaurele commented on the issue:
https://github.com/apache/cloudstack/pull/1832
@karuturi Ok thanks for the clarifications, and it's the scenario I thought
about too. That being said, I'm currently thinking of a new approach for the
command sequencer because having imple
Github user karuturi commented on the issue:
https://github.com/apache/cloudstack/pull/1832
@marcaurele The thread which is running the job gets killed due to
OperationCancelledException. But, if any command is already sent and is being
executed on hypervisor, that wont be cancelled.
Github user marcaurele commented on the issue:
https://github.com/apache/cloudstack/pull/1832
@karuturi It's a good feature but I don't see where the job gets actually
cancelled. Reading the changes I can only see that the response of the job will
become a cancelled operation, but the
Github user wido commented on the issue:
https://github.com/apache/cloudstack/pull/1812
Ok, understood. Get it.
Based on the code changes: LGTM
---
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
Github user karuturi commented on the issue:
https://github.com/apache/cloudstack/pull/873
@rhtyd will do in coming days (though I dont see a reason for the stress on
log message leaving aside logic)
---
If your project is set up for it, you can reply to this email and have your
repl
GitHub user yvsubhash reopened a pull request:
https://github.com/apache/cloudstack/pull/1725
CLOUDSTACK-9559 Why allow deleting zone without deleting the secondaâ¦
CLOUDSTACK-9559 allow deleting zone without deleting the secondary storage
under the zone
You can merge this pull
Github user yvsubhash closed the pull request at:
https://github.com/apache/cloudstack/pull/1725
---
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 feature
+1 (binding)
Upgraded from 4.9.0 to 4.9.1.0 on a running system with:
- KVM
- Basic Networking
- Ubuntu Management Server
Build .deb packages from source and installed them. Worked as planned.
Wido
> Op 15 december 2016 om 10:35 schreef Rohit Yadav :
>
>
> +1 (binding)
>
>
> - Based on upg
GitHub user karuturi opened a pull request:
https://github.com/apache/cloudstack/pull/1832
cloudstack-9652 Job framework - Cancelling async jobs
enabled cancellation of long running or subsequent queued up async jobs
You can merge this pull request into a Git repository by running
+1 (binding)
- Based on upgrade tests from 4.5.2.2 to 4.9.1.0
- Upgrading a local 4.9.0 based Ubuntu/kvm setup
- Manual packaging and repository building
- Travis and Trillian test results from PR #1753 (vpc/rvr failures are known to
be intermittent, the feature implementation/usage is flaky)
Github user yvsubhash commented on the issue:
https://github.com/apache/cloudstack/pull/1726
@ustcweizhou Volume snapshots would be left over even in case of normal vm
destroy and that is expected. They can be used if there is a need to restore
the volume at a later point in time. T
Github user koushik-das commented on the issue:
https://github.com/apache/cloudstack/pull/1829
@syed Please check #672. There was a discussion sometimes back on dev@ and
this PR was mentioned. I feel that fix is slightly better than removing the
check altogether.
---
If your project
Hello,
It turned out it’s an issue with the way the upgrade was performed, I’ve run
the cloudstack-setup-databases on top of 4.9 code base and it basically created
the 4.9 schema, the when I’ve imported the backups on DB level it didn’t
overwrite the 4.9 changes and they were still there with
Hi Rohit,
Thanks for the good way to fix this issue.
I've tested too the upgrade from 4.9.1.0 RC1 to 4.10.0.0 snapshot with
success now.
Milamber
On 15/12/2016 06:05, Rohit Yadav wrote:
Hi Bruno,
I checked the issue, the PR #1615 was merged only on master. Since, we've not
started releas
26 matches
Mail list logo
