Github user mlsorensen commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1709#discussion_r84509497
--- Diff: core/src/com/cloud/agent/api/CancelMigrationCommand.java ---
@@ -0,0 +1,35 @@
+// Licensed to the Apache Software Foundation (ASF) under
Github user mlsorensen commented on the issue:
https://github.com/apache/cloudstack/pull/1708
If we can confirm that these were false positives, we're good to merge, no?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as wel
Github user mlsorensen commented on the issue:
https://github.com/apache/cloudstack/pull/1692
If the three test failures don't represent regressions, we should probably
get this merged per Rohit's suggestion.
---
If your project is set up for it, you can reply to this emai
Github user mlsorensen commented on the issue:
https://github.com/apache/cloudstack/pull/1572
I realize I'm late to the party on this, but I'd like to suggest that we
change from the agent.properties "vm.rng.enable=true" to simply using the
libvirt version dete
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/1489#issuecomment-215147096
@koushik-das -- I'd say yes, that testing is good enough. If a test can
determine that the default roles allow the expected access to the APIs then
we&#x
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/1489#issuecomment-214843061
It seems complicated to try to actively promote a choice of multiple ways
to check for API authorization (dynamic vs static). I am for deprecating
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/1420#issuecomment-206540043
Let's 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
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/801#issuecomment-153863283
John,
I probably shouldn't respond in this thread, but from your response I
feel like much of my point was missed. In fact I had pointed out the
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/801#issuecomment-153499188
I largely agree, it provides the best experience for our end users if
we can always verify that plugins are functional and maintainable. On the
flip
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/801#issuecomment-141502048
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 not have this feature
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/340#issuecomment-107684409
Looks fine to me.
On Mon, Jun 1, 2015 at 12:13 PM, Rohit Yadav
wrote:
> pinging KVM and HA gurus to help review this @kishankav
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/281#issuecomment-105419893
Just make sure someone has actually used it to resize a volume with data.
On Mon, May 25, 2015 at 5:47 AM, Remi Bergsma
wrote:
> What do
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/288#issuecomment-105133656
The issue now is that root credentials for the host are stored in the db,
and even echoed back if you ask to list hosts with details. It's a huge step
forwa
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/288#issuecomment-105031461
Oh, I see the original post mentions that!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/288#issuecomment-105031405
Note you still have to add a sudoers entry for the user to run
cloudstack-setup-agent.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Allow+non
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/281#issuecomment-104692430
It was fixed for QCOW2 and LVM, back in January or February (unless
something has changed since then). It may be fine for RBD, I just wanted to
bring it up as a
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/281#issuecomment-104432629
You may want to be careful with this. We ran into issues with corruption by
asking libvirt to resize the qcow2 images and reverted back to the script.
---
If
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/233#issuecomment-100995179
Yeah, I got past tomcat and other systemd switchover issues on > 4.5 code,
but then ran into other issues. The mgmt server configs got all messed up by
the
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/233#issuecomment-99635718
Yeah, I think this is a big enough change that we should give all KVM
"stakeholders" an opportunity to review and test before merge. At least the
commi
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/211#issuecomment-97475041
I guess for KVM at least, the behavior should be similar to
stopping/starting the Agent. It makes the hypervisor go into disconnected, but
leaves the VM states as
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/211#issuecomment-97474185
I haven't researched this fix extensively. However, I just want to make
sure that the alert state is not accompanied by any undesirable behavior.
Movin
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/128#issuecomment-86101387
Is there a typo in the Jira ticket? CLOUDSTACK-8251 is "Allow option for
securing KVM Libvirt daemon network connections", which is one I opened
Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/81#issuecomment-74774048
I went digging to see what might have prompted this fix, and it seems that
qcow2-based storage wasn't notifying qemu when the storage resized. I've
commi
23 matches
Mail list logo
