[jira] [Commented] (CLOUDSTACK-8636) Verify failure of creation of Custom disk offering with disksize parameter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627637#comment-14627637
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8636:


GitHub user pritisarap12 opened a pull request:

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

CLOUDSTACK-8636: Verify failure of creation of Custom disk offering with 
disksize parameter

Custom disk creation should not take disksize parameter while creating the 
disk offering

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pritisarap12/cloudstack 
CLOUDSTACK-8636-Verify-failure-of-creation-of-Custom-disk-offering-with-disksize-parameter

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/592.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #592


commit b3c01f8bc3f46b65cb996373cd962392d4588a92
Author: Priti Sarap 
Date:   2015-07-15T06:56:45Z

CLOUDSTACK-8636: Verify failure of creation of Custom disk offering with 
disksize parameter




> Verify failure of creation of Custom disk offering with disksize parameter
> --
>
> Key: CLOUDSTACK-8636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8636
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> Custom disk offering creation should fail if it is given with disksize 
> parameter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8632) Unable to revert snapshot on XenServer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627639#comment-14627639
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8632:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/590#issuecomment-121510634
  
Hi @pritisarap12 

The issue/PR title says "Unable to rever snapshot on XenServer", however 
you have created a component test to "check that volume snapshot fails for the 
ROOT volume of VM which has VM snapshot created."

Could you please just elaborate a bit more on the meaning of this PR?

Cheers,
Wilder 


> Unable to revert snapshot on XenServer
> --
>
> Key: CLOUDSTACK-8632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: Priti Sarap
>  Labels: snapshot
> Fix For: 4.2.1
>
>
> On XenServer Volume snapshot fails for the volume which is attached to the VM 
> having VM snapshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8632) Unable to revert snapshot on XenServer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627640#comment-14627640
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8632:


Github user sanju1010 commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/590#discussion_r34650668
  
--- Diff: test/integration/testpaths/testpath_revert_snap.py ---
@@ -0,0 +1,159 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+""" Test cases for Verifying revert snapshot 
+"""
+from nose.plugins.attrib import attr
+from marvin.cloudstackTestCase import cloudstackTestCase
+from marvin.lib.utils import (cleanup_resources,
+ validateList)
+from marvin.lib.base import (Account,
+ ServiceOffering,
+ Snapshot,
+ VmSnapshot,
+ VirtualMachine,
+ )
+from marvin.lib.common import (get_domain,
+   get_zone,
+   get_template,
+   list_volumes,
+  )
+
+class TestUnableToRevertSnapshot(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+testClient = super(TestUnableToRevertSnapshot, 
cls).getClsTestClient()
+cls.apiclient = testClient.getApiClient()
+cls.testdata = testClient.getParsedTestDataConfig()
+
+cls.hypervisor = cls.testClient.getHypervisorInfo()
+# Get Zone, Domain and templates
+cls.domain = get_domain(cls.apiclient)
+cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests())
+
+cls.template = get_template(
+cls.apiclient,
+cls.zone.id,
+cls.testdata["ostype"])
+
+cls._cleanup = []
+
+try:
+
+cls.skiptest = False
+
+if cls.hypervisor.lower() not in ['xenserver']:
+cls.skiptest = True
+return 
+# Create an account
+cls.account = Account.create(
+cls.apiclient,
+cls.testdata["account"],
+domainid=cls.domain.id
+)
+
+# Create user api client of the account
+cls.userapiclient = testClient.getUserApiClient(
+UserName=cls.account.name,
+DomainName=cls.account.domain
+)
+# Create Service offering
+cls.service_offering = ServiceOffering.create(
+cls.apiclient,
+cls.testdata["service_offering"],
+)
+
+cls._cleanup = [
+cls.account,
+cls.service_offering,
+]
+except Exception as e:
+cls.tearDownClass()
+raise e
+return
+
+@classmethod
+def tearDownClass(cls):
+try:
+cleanup_resources(cls.apiclient, cls._cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+
+def setUp(self):
+self.apiclient = self.testClient.getApiClient()
+self.dbclient = self.testClient.getDbConnection()
+self.cleanup = []
+if self.skiptest:
+self.skipTest("This test is to be checked on xenserver only  
Hence, skip for %s"  % self.hypervisor)
+
+def tearDown(self):
+try:
+cleanup_resources(self.apiclient, self.cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+return
+
+@attr(tags=["advanced", "basic"])
+def test_01_check_revert_snapshot(self

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627645#comment-14627645
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/591#issuecomment-121511254
  
@bhaisaab @DaanHoogland @remibergsma could you have a look at this?

Wasn't ACS management-server supposed to be executed as SUDO? If I'm right, 
there is no need to change the file permission so drastically.

In that case, @sanju1010 , you need to be sudo to run it. AFAIK we all run 
our ACS environments, prod and tests, as sudo.

Cheers,
WIlder


> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8636) Verify failure of creation of Custom disk offering with disksize parameter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627646#comment-14627646
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8636:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/592#issuecomment-121511374
  
This description looks better, @pritisarap12 . I think you meant something 
like that for your previous PR.

I will wait for the build/travis and vote on them.

Cheers,
Wilder


> Verify failure of creation of Custom disk offering with disksize parameter
> --
>
> Key: CLOUDSTACK-8636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8636
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> Custom disk offering creation should fail if it is given with disksize 
> parameter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8636) Verify failure of creation of Custom disk offering with disksize parameter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627647#comment-14627647
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8636:


Github user sanju1010 commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/592#discussion_r34650908
  
--- Diff: test/integration/testpaths/testpath_custom_disk_offering.py ---
@@ -0,0 +1,84 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+""" Test case for Create Custom DiskOffering with size Test Path
+"""
+
+from nose.plugins.attrib import attr
+from marvin.cloudstackTestCase import cloudstackTestCase
+from marvin.cloudstackAPI import (createDiskOffering)
+from marvin.lib.utils import (cleanup_resources)
+from marvin.lib.common import (get_domain,
+   get_zone
+   )
+
+
+class TestCustomDiskOfferingWithSize(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+testClient = super(
+TestCustomDiskOfferingWithSize,
+cls).getClsTestClient()
+cls.apiclient = testClient.getApiClient()
+cls.testdata = testClient.getParsedTestDataConfig()
+cls.hypervisor = cls.testClient.getHypervisorInfo()
+
+# Get Zone, Domain and templates
+cls.domain = get_domain(cls.apiclient)
+cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests())
+cls._cleanup = []
+
+cls.tearDownClass()
+
+return
+
+@classmethod
+def tearDownClass(cls):
+try:
+cleanup_resources(cls.apiclient, cls._cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+
+def setUp(self):
+self.apiclient = self.testClient.getApiClient()
+self.dbclient = self.testClient.getDbConnection()
+self.cleanup = []
+
+def tearDown(self):
+try:
+cleanup_resources(self.apiclient, self.cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+return
+
+@attr(tags=["basic", "advanced"], required_hardware="false")
+def test_create_custom_disk_offering_with_size(self):
+""" Create custom disk offerign with size
+1.   Create custom disk offering with size.
+2.   Should not allow to create custom disk offering
+ with size mentioned.(Exception should be raised)
+"""
+
+with self.assertRaises(Exception):
--- End diff --

Due to product bug, if custom disk offering is created with size we need to 
delete it as part of cleanup. Can you please handle this?


> Verify failure of creation of Custom disk offering with disksize parameter
> --
>
> Key: CLOUDSTACK-8636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8636
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> Custom disk offering creation should fail if it is given with disksize 
> parameter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8628) Ceph RBD only cluster with KVM does not fence properly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627650#comment-14627650
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8628:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/580#issuecomment-121512071
  
Hi @wido 

Could you please add an extra test to cover the "pools.size() == 0)"?

Cheers,
Wilder


> Ceph RBD only cluster with KVM does not fence properly
> --
>
> Key: CLOUDSTACK-8628
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8628
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: Future, 4.6.0
>
>
> When a NFS storage pool is present on a KVM cluster that pool is used for 
> writing heartbeats to.
> In case of a Ceph (RBD) only cluster such pools are not available and thus 
> the KVM hosts do not write any heartbeats.
> Should the KVM Agent crash for any reason they will be fenced of directly and 
> this will cause a split-brain situation.
> Fencing should not happen when no NFS storage pool is present as it is 
> dangerous for data consistency. A Instance could be running on two hosts at 
> the same time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627655#comment-14627655
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/591#issuecomment-121512748
  
@wilderrodrigues currently I am on holiday and not able to look into stuff. 
As far as I know sudo was implemented for KVM agent only.  

See ya in about 10 days!

Sent from my iPhone

> On 15 Jul 2015, at 09:05, Wilder Rodrigues  
wrote:
> 
> @bhaisaab @DaanHoogland @remibergsma could you have a look at this?
> 
> Wasn't ACS management-server supposed to be executed as SUDO? If I'm 
right, there is no need to change the file permission so drastically.
> 
> In that case, @sanju1010 , you need to be sudo to run it. AFAIK we all 
run our ACS environments, prod and tests, as sudo.
> 
> Cheers,
> WIlder
> 
> —
> Reply to this email directly or view it on GitHub.
> 



> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8631) [Automation]fixing test/integration/component/test_ss_max_limits.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627690#comment-14627690
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8631:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/585#issuecomment-121522610
  
thanks LGTM


> [Automation]fixing test/integration/component/test_ss_max_limits.py
> ---
>
> Key: CLOUDSTACK-8631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8631
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.1
>
>
> Method "updateSecondaryStorageLimits " was not updating resource count if 
> values(accountLimit, domainLimit, projectLimit) are zero .
> modifes if condition to consider  zero also.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8631) [Automation]fixing test/integration/component/test_ss_max_limits.py

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627704#comment-14627704
 ] 

ASF subversion and git services commented on CLOUDSTACK-8631:
-

Commit 373b2c787e72b44b85ccae46d47d3c02508e17ac in cloudstack's branch 
refs/heads/master from nitt10prashant
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=373b2c7 ]

CLOUDSTACK-8631 :changing if condition in component/test_ss_max_limits.py
This closes #585


> [Automation]fixing test/integration/component/test_ss_max_limits.py
> ---
>
> Key: CLOUDSTACK-8631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8631
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.1
>
>
> Method "updateSecondaryStorageLimits " was not updating resource count if 
> values(accountLimit, domainLimit, projectLimit) are zero .
> modifes if condition to consider  zero also.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8631) [Automation]fixing test/integration/component/test_ss_max_limits.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627705#comment-14627705
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8631:


Github user asfgit closed the pull request at:

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


> [Automation]fixing test/integration/component/test_ss_max_limits.py
> ---
>
> Key: CLOUDSTACK-8631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8631
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.1
>
>
> Method "updateSecondaryStorageLimits " was not updating resource count if 
> values(accountLimit, domainLimit, projectLimit) are zero .
> modifes if condition to consider  zero also.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8631) [Automation]fixing test/integration/component/test_ss_max_limits.py

[Daan Hoogland (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daan Hoogland updated CLOUDSTACK-8631:
--
Fix Version/s: (was: 4.5.1)
   4.5.2

> [Automation]fixing test/integration/component/test_ss_max_limits.py
> ---
>
> Key: CLOUDSTACK-8631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8631
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.2
>
>
> Method "updateSecondaryStorageLimits " was not updating resource count if 
> values(accountLimit, domainLimit, projectLimit) are zero .
> modifes if condition to consider  zero also.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8636) Verify failure of creation of Custom disk offering with disksize parameter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627717#comment-14627717
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8636:


Github user pritisarap12 commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/592#discussion_r34656988
  
--- Diff: test/integration/testpaths/testpath_custom_disk_offering.py ---
@@ -0,0 +1,84 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+""" Test case for Create Custom DiskOffering with size Test Path
+"""
+
+from nose.plugins.attrib import attr
+from marvin.cloudstackTestCase import cloudstackTestCase
+from marvin.cloudstackAPI import (createDiskOffering)
+from marvin.lib.utils import (cleanup_resources)
+from marvin.lib.common import (get_domain,
+   get_zone
+   )
+
+
+class TestCustomDiskOfferingWithSize(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+testClient = super(
+TestCustomDiskOfferingWithSize,
+cls).getClsTestClient()
+cls.apiclient = testClient.getApiClient()
+cls.testdata = testClient.getParsedTestDataConfig()
+cls.hypervisor = cls.testClient.getHypervisorInfo()
+
+# Get Zone, Domain and templates
+cls.domain = get_domain(cls.apiclient)
+cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests())
+cls._cleanup = []
+
+cls.tearDownClass()
+
+return
+
+@classmethod
+def tearDownClass(cls):
+try:
+cleanup_resources(cls.apiclient, cls._cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+
+def setUp(self):
+self.apiclient = self.testClient.getApiClient()
+self.dbclient = self.testClient.getDbConnection()
+self.cleanup = []
+
+def tearDown(self):
+try:
+cleanup_resources(self.apiclient, self.cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+return
+
+@attr(tags=["basic", "advanced"], required_hardware="false")
+def test_create_custom_disk_offering_with_size(self):
+""" Create custom disk offerign with size
+1.   Create custom disk offering with size.
+2.   Should not allow to create custom disk offering
+ with size mentioned.(Exception should be raised)
+"""
+
+with self.assertRaises(Exception):
--- End diff --

Updated the testcase as per review changes.


> Verify failure of creation of Custom disk offering with disksize parameter
> --
>
> Key: CLOUDSTACK-8636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8636
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> Custom disk offering creation should fail if it is given with disksize 
> parameter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8632) Unable to revert snapshot on XenServer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627726#comment-14627726
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8632:


Github user pritisarap12 commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/590#discussion_r34657738
  
--- Diff: test/integration/testpaths/testpath_revert_snap.py ---
@@ -0,0 +1,159 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+""" Test cases for Verifying revert snapshot 
+"""
+from nose.plugins.attrib import attr
+from marvin.cloudstackTestCase import cloudstackTestCase
+from marvin.lib.utils import (cleanup_resources,
+ validateList)
+from marvin.lib.base import (Account,
+ ServiceOffering,
+ Snapshot,
+ VmSnapshot,
+ VirtualMachine,
+ )
+from marvin.lib.common import (get_domain,
+   get_zone,
+   get_template,
+   list_volumes,
+  )
+
+class TestUnableToRevertSnapshot(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+testClient = super(TestUnableToRevertSnapshot, 
cls).getClsTestClient()
+cls.apiclient = testClient.getApiClient()
+cls.testdata = testClient.getParsedTestDataConfig()
+
+cls.hypervisor = cls.testClient.getHypervisorInfo()
+# Get Zone, Domain and templates
+cls.domain = get_domain(cls.apiclient)
+cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests())
+
+cls.template = get_template(
+cls.apiclient,
+cls.zone.id,
+cls.testdata["ostype"])
+
+cls._cleanup = []
+
+try:
+
+cls.skiptest = False
+
+if cls.hypervisor.lower() not in ['xenserver']:
+cls.skiptest = True
+return 
+# Create an account
+cls.account = Account.create(
+cls.apiclient,
+cls.testdata["account"],
+domainid=cls.domain.id
+)
+
+# Create user api client of the account
+cls.userapiclient = testClient.getUserApiClient(
+UserName=cls.account.name,
+DomainName=cls.account.domain
+)
+# Create Service offering
+cls.service_offering = ServiceOffering.create(
+cls.apiclient,
+cls.testdata["service_offering"],
+)
+
+cls._cleanup = [
+cls.account,
+cls.service_offering,
+]
+except Exception as e:
+cls.tearDownClass()
+raise e
+return
+
+@classmethod
+def tearDownClass(cls):
+try:
+cleanup_resources(cls.apiclient, cls._cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+
+def setUp(self):
+self.apiclient = self.testClient.getApiClient()
+self.dbclient = self.testClient.getDbConnection()
+self.cleanup = []
+if self.skiptest:
+self.skipTest("This test is to be checked on xenserver only  
Hence, skip for %s"  % self.hypervisor)
+
+def tearDown(self):
+try:
+cleanup_resources(self.apiclient, self.cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+return
+
+@attr(tags=["advanced", "basic"])
+def test_01_check_revert_snapshot(s

[jira] [Commented] (CLOUDSTACK-8580) Users should be able to expunge VMs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627757#comment-14627757
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8580:


GitHub user borisroman opened a pull request:

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

CLOUDSTACK-8580

Users are now able to view, expunge and recover their vm's themselves. Two 
configuration options are added to allow this behaviour on a global or per 
account scale. Configuration options default to false.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/borisroman/cloudstack master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/593.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #593


commit dd7dfc3a4e1e33140ecca53802660f25f831f775
Author: Boris Schrijver 
Date:   2015-07-15T09:04:32Z

CLOUDSTACK-8580 Users are now able to view, expunge and recover their vm's 
themselves. Two configuration options are added to allow this behaviour on a 
global or per account scale. Configuration options default to false.




> Users should be able to expunge VMs
> ---
>
> Key: CLOUDSTACK-8580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8580
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Lennert den Teuling
>Priority: Minor
>
> When automating deployments of CloudStack (with for example Terraform) there 
> are situations where VMs get recreated with the same name (and hostname). 
> When VMs are destroyed by a user, the name will be reserved on the network 
> until the VM truly gets expunged (depending on expunge.delay). Because of 
> this, some automation tools cannot work because a new deployment with the 
> same name gives an error.  
> Users do not have the ability to directly expunge VMs (Only admin and 
> domain-admins can), but they can destroy them and the admin can configure the 
> expunge.delay where VMs truly get removed (expunged). 
> Working with the expunge delay is very safe in case users accidentally remove 
> a VM, but in some cases (when users know what they are doing) there should 
> also be a option to completely remove the VM when destroying it (expunge). 
> Ideally the admin should be able to configure this behavior trough the global 
> settings, cause i believe the admin deliberately needs to turn it on (off by 
> default).
> We have looked into making our clients domain-admin by default, but that 
> gives them abilities we do not want to give, so we see no other way then just 
> enabling expunge for the user. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8637) Verify that cloudstack gives error on creation of VM's with the same Display name when vm.instancename.flag=true

[Priti Sarap (JIRA)]

Priti Sarap created CLOUDSTACK-8637:
---

 Summary: Verify that cloudstack gives error on creation of VM's 
with the same Display name when vm.instancename.flag=true
 Key: CLOUDSTACK-8637
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8637
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.2.1
Reporter: Priti Sarap
 Fix For: 4.2.1


When vm.instancename.flag=true it will only set the "instancename" without any 
additional prefix so name of the instance on hypervisor will also be same hence 
verify that when tried to create another instance with same name on same 
hypervisor should fail on VMWare as it should have every instance with unique 
name.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627814#comment-14627814
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user pvr9712 commented on the pull request:

https://github.com/apache/cloudstack/pull/591#issuecomment-121559068
  
I have tested this changes and it works.  


> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8637) Verify that cloudstack gives error on creation of VM's with the same Display name when vm.instancename.flag=true

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627832#comment-14627832
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8637:


GitHub user pritisarap12 opened a pull request:

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

CLOUDSTACK-8637: Verify that VM with same Display name creation fails if 
vm.instancename.flag=true

When vm.instancename.flag=true it will only set the "instancename" without 
any additional prefix so name of the instance on host will also be same hence 
verify that when tried to create another instance with same name on same host 
should fail on VMWare as it should have every instance with unique name.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pritisarap12/cloudstack 
CLOUDSTACK-8637-Verify-that-cloudstack-gives-error-on-creation-of-VMs-with-the-same-Display-name-when-vm.instancename.flag=true

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/594.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #594


commit a2df28d2f7f2596a121a53ee064250b62bb3b6c2
Author: Priti Sarap 
Date:   2015-07-15T09:46:24Z

CLOUDSTACK-8637: Verify that VM with same Display name creation fails if 
vm.instancename.flag=true




> Verify that cloudstack gives error on creation of VM's with the same Display 
> name when vm.instancename.flag=true
> 
>
> Key: CLOUDSTACK-8637
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8637
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> When vm.instancename.flag=true it will only set the "instancename" without 
> any additional prefix so name of the instance on hypervisor will also be same 
> hence verify that when tried to create another instance with same name on 
> same hypervisor should fail on VMWare as it should have every instance with 
> unique name.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627834#comment-14627834
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/591#issuecomment-121563084
  
@pvr9712 the question here is not if it works or not, because it's quite 
clear that once the permission changes it will suffice @sanju1010's need. The 
point is: is that the right thing to do? That's why I CCed @bhaisaab and 
@DaanHoogland .

I don't think that the approach is completely right. It sound like 
something "oh, wait! I don't have permission to do that. Let's then change the 
file permissions.".

To be honest, I haven't seen anyone running into such a problem. Could you 
perhaps describe better the environment you have, @sanju1010 ?

Cheers,
Wilder


> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627843#comment-14627843
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user pvr9712 commented on the pull request:

https://github.com/apache/cloudstack/pull/591#issuecomment-121566177
  
@wilderrodrigues if you look at the earlier commit, the code was refactored 
and I feel it is a miss.  If this worked for someone, will be interested to 
know.  
best,
Raja


> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627871#comment-14627871
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user pvr9712 commented on the pull request:

https://github.com/apache/cloudstack/pull/591#issuecomment-121571026
  
BTW, here is my email on the Dev list with the details for this issues - 
including the earlier commit - Using Master builds, MS logs shows following 
error -

"management-server.log:org.springframework.context.ApplicationContextException: 
Failed to start bean 'cloudStackLifeCycle'; nested exception is 
com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is mode 
0755, should be 0440sudo: sorry, you must have a tty to run sudo"

After modifying the permissions - MS works fine.

Apparently, this is related to a checkin ...
commit 870e1898eb28039fafaaeb8e50a7039f626f912c

https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c

I have created a defect, 
CLOUDSTACK-8633, to 
track this 




> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627890#comment-14627890
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/591#issuecomment-121573911
  
Hi @pvr9712 

Thanks for the commit IDs, a bit of context always help.

It would have saved us some time if the PR would have the commit ID which 
caused the bug.

LGTM :+1: 

Cheers,
Wilder


> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8638) Cloudstack deb packages don't include update_host_passwd.sh

[Boris Schrijver (JIRA)]

Boris Schrijver created CLOUDSTACK-8638:
---

 Summary: Cloudstack deb packages don't include 
update_host_passwd.sh
 Key: CLOUDSTACK-8638
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8638
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Packaging
Affects Versions: 4.6.0
Reporter: Boris Schrijver
Priority: Critical


When building the master; Cloudstack deb packages don't include 
update_host_passwd.sh



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8580) Users should be able to expunge VMs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627904#comment-14627904
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8580:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/593#issuecomment-121585809
  
Can you add the description of the functionality is short to the pr title?

for instance 'CLOUDSTACK-8580: user access to deleted VMs'


> Users should be able to expunge VMs
> ---
>
> Key: CLOUDSTACK-8580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8580
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Lennert den Teuling
>Priority: Minor
>
> When automating deployments of CloudStack (with for example Terraform) there 
> are situations where VMs get recreated with the same name (and hostname). 
> When VMs are destroyed by a user, the name will be reserved on the network 
> until the VM truly gets expunged (depending on expunge.delay). Because of 
> this, some automation tools cannot work because a new deployment with the 
> same name gives an error.  
> Users do not have the ability to directly expunge VMs (Only admin and 
> domain-admins can), but they can destroy them and the admin can configure the 
> expunge.delay where VMs truly get removed (expunged). 
> Working with the expunge delay is very safe in case users accidentally remove 
> a VM, but in some cases (when users know what they are doing) there should 
> also be a option to completely remove the VM when destroying it (expunge). 
> Ideally the admin should be able to configure this behavior trough the global 
> settings, cause i believe the admin deliberately needs to turn it on (off by 
> default).
> We have looked into making our clients domain-admin by default, but that 
> gives them abilities we do not want to give, so we see no other way then just 
> enabling expunge for the user. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8580) Users should be able to expunge VMs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627958#comment-14627958
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8580:


Github user borisroman commented on the pull request:

https://github.com/apache/cloudstack/pull/593#issuecomment-121600559
  
Added description to title.


> Users should be able to expunge VMs
> ---
>
> Key: CLOUDSTACK-8580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8580
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Lennert den Teuling
>Priority: Minor
>
> When automating deployments of CloudStack (with for example Terraform) there 
> are situations where VMs get recreated with the same name (and hostname). 
> When VMs are destroyed by a user, the name will be reserved on the network 
> until the VM truly gets expunged (depending on expunge.delay). Because of 
> this, some automation tools cannot work because a new deployment with the 
> same name gives an error.  
> Users do not have the ability to directly expunge VMs (Only admin and 
> domain-admins can), but they can destroy them and the admin can configure the 
> expunge.delay where VMs truly get removed (expunged). 
> Working with the expunge delay is very safe in case users accidentally remove 
> a VM, but in some cases (when users know what they are doing) there should 
> also be a option to completely remove the VM when destroying it (expunge). 
> Ideally the admin should be able to configure this behavior trough the global 
> settings, cause i believe the admin deliberately needs to turn it on (off by 
> default).
> We have looked into making our clients domain-admin by default, but that 
> gives them abilities we do not want to give, so we see no other way then just 
> enabling expunge for the user. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8637) Verify that cloudstack gives error on creation of VM's with the same Display name when vm.instancename.flag=true

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627961#comment-14627961
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8637:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/594#issuecomment-121601522
  
looks like this is for vmware only
no way for me to verify, but good looks okay.
LGTM, merging now


> Verify that cloudstack gives error on creation of VM's with the same Display 
> name when vm.instancename.flag=true
> 
>
> Key: CLOUDSTACK-8637
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8637
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> When vm.instancename.flag=true it will only set the "instancename" without 
> any additional prefix so name of the instance on hypervisor will also be same 
> hence verify that when tried to create another instance with same name on 
> same hypervisor should fail on VMWare as it should have every instance with 
> unique name.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8637) Verify that cloudstack gives error on creation of VM's with the same Display name when vm.instancename.flag=true

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627965#comment-14627965
 ] 

ASF subversion and git services commented on CLOUDSTACK-8637:
-

Commit abf216aed62c214afbe6f7e0d48d8dc58a8c3962 in cloudstack's branch 
refs/heads/master from [~pritisarap12]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=abf216a ]

CLOUDSTACK-8637: Verify that VM with same Display name creation fails if 
vm.instancename.flag=true

Signed-off-by: Rohit Yadav 

This closes #594


> Verify that cloudstack gives error on creation of VM's with the same Display 
> name when vm.instancename.flag=true
> 
>
> Key: CLOUDSTACK-8637
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8637
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> When vm.instancename.flag=true it will only set the "instancename" without 
> any additional prefix so name of the instance on hypervisor will also be same 
> hence verify that when tried to create another instance with same name on 
> same hypervisor should fail on VMWare as it should have every instance with 
> unique name.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8636) Verify failure of creation of Custom disk offering with disksize parameter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627966#comment-14627966
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8636:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/592#issuecomment-121602397
  
LGTM


> Verify failure of creation of Custom disk offering with disksize parameter
> --
>
> Key: CLOUDSTACK-8636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8636
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> Custom disk offering creation should fail if it is given with disksize 
> parameter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8637) Verify that cloudstack gives error on creation of VM's with the same Display name when vm.instancename.flag=true

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627967#comment-14627967
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8637:


Github user asfgit closed the pull request at:

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


> Verify that cloudstack gives error on creation of VM's with the same Display 
> name when vm.instancename.flag=true
> 
>
> Key: CLOUDSTACK-8637
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8637
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> When vm.instancename.flag=true it will only set the "instancename" without 
> any additional prefix so name of the instance on hypervisor will also be same 
> hence verify that when tried to create another instance with same name on 
> same hypervisor should fail on VMWare as it should have every instance with 
> unique name.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8636) Verify failure of creation of Custom disk offering with disksize parameter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627969#comment-14627969
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8636:


Github user asfgit closed the pull request at:

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


> Verify failure of creation of Custom disk offering with disksize parameter
> --
>
> Key: CLOUDSTACK-8636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8636
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> Custom disk offering creation should fail if it is given with disksize 
> parameter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8636) Verify failure of creation of Custom disk offering with disksize parameter

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627968#comment-14627968
 ] 

ASF subversion and git services commented on CLOUDSTACK-8636:
-

Commit 373b107b96bb757fee41f6eb68d97f4d47aa7a39 in cloudstack's branch 
refs/heads/master from [~pritisarap12]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=373b107 ]

CLOUDSTACK-8636: Verify failure of creation of Custom disk offering with 
disksize parameter

- Clear disk offering in tearDown() class if gets created

Signed-off-by: Rohit Yadav 

This closes #592


> Verify failure of creation of Custom disk offering with disksize parameter
> --
>
> Key: CLOUDSTACK-8636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8636
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> Custom disk offering creation should fail if it is given with disksize 
> parameter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8636) Verify failure of creation of Custom disk offering with disksize parameter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627971#comment-14627971
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8636:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/592#issuecomment-121602562
  
squashed/merged your commits; in future please try to squash them as you 
iterate with your reviews


> Verify failure of creation of Custom disk offering with disksize parameter
> --
>
> Key: CLOUDSTACK-8636
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8636
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>
> Custom disk offering creation should fail if it is given with disksize 
> parameter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627973#comment-14627973
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/591#issuecomment-121602657
  
LGTM, good catch


> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627978#comment-14627978
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user asfgit closed the pull request at:

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


> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627979#comment-14627979
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8633:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/591#issuecomment-121603506
  
Added same logic for fedora20/21 spec files as well. Merged on master now.


> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627977#comment-14627977
 ] 

ASF subversion and git services commented on CLOUDSTACK-8633:
-

Commit 87e53eae53bb34a44d8869a8c6289795a186a9e1 in cloudstack's branch 
refs/heads/master from sanjeev
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=87e53ea ]

CLOUDSTACK-8633: Changing file permissions from 755 to 440

Reviewed-By: Raja

Signed-off-by: Rohit Yadav 

This closes #591


> Cannot login due to an error in starting 'cloudStackLifeCycle' bean
> ---
>
> Key: CLOUDSTACK-8633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Raja Pullela
>Priority: Blocker
>
> Using Master builds, MS logs shows following error – 
> “management-server.log:org.springframework.context.ApplicationContextException:
>  Failed to start bean 'cloudStackLifeCycle'; nested exception is 
> com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated 
> public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is 
> mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo”
> After modifying the permissions – MS works fine. 
> Apparently, this is related to a check that was done some time back…
> commit 870e1898eb28039fafaaeb8e50a7039f626f912c
> https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8635) Ubuntu packages should depend on OpenJDK headless JRE

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627987#comment-14627987
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8635:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/588#issuecomment-121603953
  
checked both debian packages and ubuntu ones, LGTM


> Ubuntu packages should depend on OpenJDK headless JRE
> -
>
> Key: CLOUDSTACK-8635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8635
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>
> We now depend on openjdk-7-jre on Ubuntu, but this also install a lot of 
> desktop related packages.
> We don't need them and can depend on openjdk-7-jre-headless



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8635) Ubuntu packages should depend on OpenJDK headless JRE

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627988#comment-14627988
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8635:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/588#issuecomment-121603988
  
@wido do we need to port them on 4.5 branch?


> Ubuntu packages should depend on OpenJDK headless JRE
> -
>
> Key: CLOUDSTACK-8635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8635
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>
> We now depend on openjdk-7-jre on Ubuntu, but this also install a lot of 
> desktop related packages.
> We don't need them and can depend on openjdk-7-jre-headless



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8635) Ubuntu packages should depend on OpenJDK headless JRE

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627991#comment-14627991
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8635:


Github user asfgit closed the pull request at:

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


> Ubuntu packages should depend on OpenJDK headless JRE
> -
>
> Key: CLOUDSTACK-8635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8635
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>
> We now depend on openjdk-7-jre on Ubuntu, but this also install a lot of 
> desktop related packages.
> We don't need them and can depend on openjdk-7-jre-headless



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8635) Ubuntu packages should depend on OpenJDK headless JRE

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627989#comment-14627989
 ] 

ASF subversion and git services commented on CLOUDSTACK-8635:
-

Commit 6d92abcb76304686792b4fc346e564e09d1822d8 in cloudstack's branch 
refs/heads/master from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6d92abc ]

CLOUDSTACK-8635: Depend on the headless JRE for Ubuntu packages

This will install less packages on the system running CloudStack.

The -headless JRE doesn't include packages for running on desktops

Signed-off-by: Rohit Yadav 

This closes #588


> Ubuntu packages should depend on OpenJDK headless JRE
> -
>
> Key: CLOUDSTACK-8635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8635
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>
> We now depend on openjdk-7-jre on Ubuntu, but this also install a lot of 
> desktop related packages.
> We don't need them and can depend on openjdk-7-jre-headless



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8581) Make S3 TCP KeepAlive and ConnectionTtl configureable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628002#comment-14628002
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8581:


Github user bhaisaab commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/582#discussion_r34674108
  
--- Diff: api/src/com/cloud/agent/api/to/S3TO.java ---
@@ -118,6 +122,14 @@ public boolean equals(final Object thatObject) {
 return false;
 }
 
+if (connectionTtl != null ? 
!connectionTtl.equals(thatS3TO.connectionTtl) : thatS3TO.connectionTtl != null) 
{
+return false;
--- End diff --

break into readable if-else please


> Make S3 TCP KeepAlive and ConnectionTtl configureable
> -
>
> Key: CLOUDSTACK-8581
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8581
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.6.0
>
>
> Currently we can not set the TCP KeepAlive and ConnectionTtl settings for the 
> Amazon S3 ClientConfiguration class: 
> http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/ClientConfiguration.html
> Our S3Util doesn't set these values so it defaults to what Amazon configures.
> This doesn't work in all situations and we want to make this configurable. 
> For example the ConnectionTtl should be lowered in cases where the Object 
> Store closes a HTTP connection after a very short period.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8639) fixing calculation mistakes in component/test_ss_domain_limits.py

[prashant kumar mishra (JIRA)]

prashant kumar mishra created CLOUDSTACK-8639:
-

 Summary: fixing calculation mistakes in 
component/test_ss_domain_limits.py
 Key: CLOUDSTACK-8639
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8639
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.5.1
Reporter: prashant kumar mishra
Assignee: prashant kumar mishra
 Fix For: 4.5.1


expectedCount=int(int(templates[0].size) / (1024**3))
expectedCount *= 2

if template[0].size is less that one GB  expectedCount will be 0

so expectedCount*=2  will not have any effect . 

fixing expectedCount calculation:

self.templateSize = int((int(templates[0].size)*2) / (1024**3))



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8639) fixing calculation mistakes in component/test_ss_domain_limits.py

[prashant kumar mishra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

prashant kumar mishra updated CLOUDSTACK-8639:
--
Description: 
expectedCount=int(int(templates[0].size) / (1024**3))
expectedCount *= 2

if template[0].size is less that one GB , expectedCount will be 0

so expectedCount*=2  will not have any effect . 

fixing expectedCount calculation:

self.templateSize = int((int(templates[0].size)*2) / (1024**3))
expectedCount =self.templateSize

  was:
expectedCount=int(int(templates[0].size) / (1024**3))
expectedCount *= 2

if template[0].size is less that one GB  expectedCount will be 0

so expectedCount*=2  will not have any effect . 

fixing expectedCount calculation:

self.templateSize = int((int(templates[0].size)*2) / (1024**3))


> fixing calculation mistakes in component/test_ss_domain_limits.py
> -
>
> Key: CLOUDSTACK-8639
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8639
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.1
>
>
> expectedCount=int(int(templates[0].size) / (1024**3))
> expectedCount *= 2
> if template[0].size is less that one GB , expectedCount will be 0
> so expectedCount*=2  will not have any effect . 
> fixing expectedCount calculation:
> self.templateSize = int((int(templates[0].size)*2) / (1024**3))
> expectedCount =self.templateSize



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8457) Make SAML plugin production grade

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628013#comment-14628013
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8457:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/583#issuecomment-121606896
  
LGTM from Abhi (on chat); test setup on http://acs.bhaisaab.org:8080/client/


> Make SAML plugin production grade
> -
>
> Key: CLOUDSTACK-8457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8457
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SAML
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.6.0, 4.5.2
>
>
> The current SAML plugin is not well tested with major IdPs used in production 
> such as Shibboleth. It is also limited to using HTTP-redirect only and does 
> not support HTTP-Post and other artifacts. Further, the security concerns are 
> not well addressed, for example both authorization, creation of 
> users/accounts (on first login) and authentication is done by the plugin 
> which needs to be tested wrt security, addressed and improved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8635) Ubuntu packages should depend on OpenJDK headless JRE

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628015#comment-14628015
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8635:


Github user wido commented on the pull request:

https://github.com/apache/cloudstack/pull/588#issuecomment-121607193
  
@bhaisaab We could, since users who would upgrade to 4.5.2 coming from 
4.4.X wouldn't need to install all those packages.


> Ubuntu packages should depend on OpenJDK headless JRE
> -
>
> Key: CLOUDSTACK-8635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8635
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>
> We now depend on openjdk-7-jre on Ubuntu, but this also install a lot of 
> desktop related packages.
> We don't need them and can depend on openjdk-7-jre-headless



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8639) fixing calculation mistakes in component/test_ss_domain_limits.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628019#comment-14628019
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8639:


GitHub user nitt10prashant opened a pull request:

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

CLOUDSTACK-8639:fixing calculation mistakes in component/test_ss_doma…

test result
=
Test secondary storage limit of domain and its sub-domains ... === 
TestName: test_04_create_template_delete_account | Status : SUCCESS ===
ok

--
Ran 1 test in 175.563s

OK

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nitt10prashant/cloudstack ss_domain_limit

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/595.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #595


commit 2b0261fd87eb0e8d9f770cb989adbcb586d215cc
Author: nitt10prashant 
Date:   2015-07-15T13:03:00Z

CLOUDSTACK-8639:fixing calculation mistakes in 
component/test_ss_domain_limits.py




> fixing calculation mistakes in component/test_ss_domain_limits.py
> -
>
> Key: CLOUDSTACK-8639
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8639
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.1
>
>
> expectedCount=int(int(templates[0].size) / (1024**3))
> expectedCount *= 2
> if template[0].size is less that one GB , expectedCount will be 0
> so expectedCount*=2  will not have any effect . 
> fixing expectedCount calculation:
> self.templateSize = int((int(templates[0].size)*2) / (1024**3))
> expectedCount =self.templateSize



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8457) Make SAML plugin production grade

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628023#comment-14628023
 ] 

ASF subversion and git services commented on CLOUDSTACK-8457:
-

Commit 47d2d07eb95a21f2de301461bbf566b489b5650c in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=47d2d07 ]

CLOUDSTACK-8457: SAML UI Dialog fixes to use local $form

This uses local selector to access the DOM elements, the previous commit
would find a global element which is not in the context and fail changing the
element in the opened dialog.

Signed-off-by: Rohit Yadav 

This closes #583


> Make SAML plugin production grade
> -
>
> Key: CLOUDSTACK-8457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8457
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SAML
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.6.0, 4.5.2
>
>
> The current SAML plugin is not well tested with major IdPs used in production 
> such as Shibboleth. It is also limited to using HTTP-redirect only and does 
> not support HTTP-Post and other artifacts. Further, the security concerns are 
> not well addressed, for example both authorization, creation of 
> users/accounts (on first login) and authentication is done by the plugin 
> which needs to be tested wrt security, addressed and improved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8457) Make SAML plugin production grade

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628024#comment-14628024
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8457:


Github user asfgit closed the pull request at:

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


> Make SAML plugin production grade
> -
>
> Key: CLOUDSTACK-8457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8457
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SAML
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.6.0, 4.5.2
>
>
> The current SAML plugin is not well tested with major IdPs used in production 
> such as Shibboleth. It is also limited to using HTTP-redirect only and does 
> not support HTTP-Post and other artifacts. Further, the security concerns are 
> not well addressed, for example both authorization, creation of 
> users/accounts (on first login) and authentication is done by the plugin 
> which needs to be tested wrt security, addressed and improved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8457) Make SAML plugin production grade

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628025#comment-14628025
 ] 

ASF subversion and git services commented on CLOUDSTACK-8457:
-

Commit c7a6623cacf134985a3926f1b6405401b0522e60 in cloudstack's branch 
refs/heads/4.5 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7a6623 ]

CLOUDSTACK-8457: SAML UI Dialog fixes to use local $form

This uses local selector to access the DOM elements, the previous commit
would find a global element which is not in the context and fail changing the
element in the opened dialog.

Signed-off-by: Rohit Yadav 

This closes #583

(cherry picked from commit 47d2d07eb95a21f2de301461bbf566b489b5650c)
Signed-off-by: Rohit Yadav 


> Make SAML plugin production grade
> -
>
> Key: CLOUDSTACK-8457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8457
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SAML
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.6.0, 4.5.2
>
>
> The current SAML plugin is not well tested with major IdPs used in production 
> such as Shibboleth. It is also limited to using HTTP-redirect only and does 
> not support HTTP-Post and other artifacts. Further, the security concerns are 
> not well addressed, for example both authorization, creation of 
> users/accounts (on first login) and authentication is done by the plugin 
> which needs to be tested wrt security, addressed and improved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8605) KVM: Config Drive and getVmIp support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628198#comment-14628198
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8605:


Github user kishankavala commented on the pull request:

https://github.com/apache/cloudstack/pull/577#issuecomment-121645521
  
/var/lib/libvirt/images is used for local storage also.  
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource#configure
  _localStoragePath = (String)params.get("local.storage.path");
if (_localStoragePath == null) {
_localStoragePath = "/var/lib/libvirt/images/";
}

I'll update the patch to use _localStoragePath  instead of hard-coded 
/var/lib/libvirt/images


> KVM: Config Drive and getVmIp support
> -
>
> Key: CLOUDSTACK-8605
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8605
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.6.0
>Reporter: Kishan Kavala
>Assignee: Kishan Kavala
> Fix For: 4.6.0
>
>
> Add support for 
> - creating config drive
> - Fetch IP from guest Vm which is assigned by external DHCP



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-8635) Ubuntu packages should depend on OpenJDK headless JRE

[Wido den Hollander (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wido den Hollander closed CLOUDSTACK-8635.
--
   Resolution: Fixed
Fix Version/s: 4.5.2
   4.6.0

Merged into master and will backport to 4.5

> Ubuntu packages should depend on OpenJDK headless JRE
> -
>
> Key: CLOUDSTACK-8635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8635
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.6.0, 4.5.2
>
>
> We now depend on openjdk-7-jre on Ubuntu, but this also install a lot of 
> desktop related packages.
> We don't need them and can depend on openjdk-7-jre-headless



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8640) Uploads to S3 Secondary Storage fail, stay at 0% completed

[Wido den Hollander (JIRA)]

Wido den Hollander created CLOUDSTACK-8640:
--

 Summary: Uploads to S3 Secondary Storage fail, stay at 0% completed
 Key: CLOUDSTACK-8640
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8640
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: SystemVM
Affects Versions: 4.5.1, Future
 Environment: Ceph RADOS Gateway with Civetweb as Secondary Storage
Reporter: Wido den Hollander
Assignee: Wido den Hollander


I noticed this after upgrading to 4.5.2 (build from 4.5 branch).

Uploads never completed when a template was downloaded en directly uploaded to 
S3 secondary storage provided by Ceph's RADOS Gateway using Multipart.

After searching for hours I found this: 
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/event/ProgressEvent.html#getBytesTransferred()

The ProgressEvent of the returned that 0 bytes had been transferred. But when 
using the getBytes() method it actually works.

The upload succeeds, but we check if the amount of uploaded bytes is equal or 
more then what we expected. If not, we say the upload failed.

This happens inside S3TemplateDownloader (which really needs some fixes btw)

Tracing this down if it's related to Ceph or actually something in 
S3TemplateDownloader.

I also tried the Amazon SDK 1.9.34, but that didn't make a different.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8580) Users should be able to expunge VMs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628591#comment-14628591
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8580:


Github user borisroman closed the pull request at:

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


> Users should be able to expunge VMs
> ---
>
> Key: CLOUDSTACK-8580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8580
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Lennert den Teuling
>Priority: Minor
>
> When automating deployments of CloudStack (with for example Terraform) there 
> are situations where VMs get recreated with the same name (and hostname). 
> When VMs are destroyed by a user, the name will be reserved on the network 
> until the VM truly gets expunged (depending on expunge.delay). Because of 
> this, some automation tools cannot work because a new deployment with the 
> same name gives an error.  
> Users do not have the ability to directly expunge VMs (Only admin and 
> domain-admins can), but they can destroy them and the admin can configure the 
> expunge.delay where VMs truly get removed (expunged). 
> Working with the expunge delay is very safe in case users accidentally remove 
> a VM, but in some cases (when users know what they are doing) there should 
> also be a option to completely remove the VM when destroying it (expunge). 
> Ideally the admin should be able to configure this behavior trough the global 
> settings, cause i believe the admin deliberately needs to turn it on (off by 
> default).
> We have looked into making our clients domain-admin by default, but that 
> gives them abilities we do not want to give, so we see no other way then just 
> enabling expunge for the user. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8584) Management Server does not start - "cluster node IP should be valid local address"

[James Clendenan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629147#comment-14629147
 ] 

James Clendenan commented on CLOUDSTACK-8584:
-

it appears that Debian and Ubuntu have the same issues with this.

Problem:
at some point your hosts file had 127.0.1.1 as the fqdn entry for your machine.

One of the setup tools grabbed it and used it to set:

/etc/cloudstack/management/db.properties:cluster.node.IP=127.0.1.1

Solution for user:
Fix your hosts file by deleting the 127.0.1.1 entry, or setting it to an ip on 
an actual usable interface

Solution for developer:
Figure out why this was considered to be valid to insert in the first place, 
and don't do it..  (fail earlier)


> Management Server does not start - "cluster node IP should be valid local 
> address"
> --
>
> Key: CLOUDSTACK-8584
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8584
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.1
> Environment: * Ubuntu 14.04
> * Installed Management Server from repository
>Reporter: Michael Lihs
>
> h1. Problem Description
> When I try to start the CloudStack Management Server, I get the following 
> error message in the {{/var/log/cloudstack/management/management-server.log}}:
> {code}
> 2015-06-24 06:21:37,950 INFO  [c.c.c.ClusterManagerImpl] (main:null) Start 
> configuring cluster manager : ClusterManagerImpl
> 2015-06-24 06:21:37,956 INFO  [c.c.c.ClusterManagerImpl] (main:null) Cluster 
> node IP : 127.0.1.1
> 2015-06-24 06:21:37,965 ERROR [o.a.c.s.l.CloudStackExtendedLifeCycle] 
> (main:null) Failed to configure ClusterManagerImpl
> javax.naming.ConfigurationException: cluster node IP should be valid local 
> address where the server is running, please check your configuration
>   at 
> com.cloud.cluster.ClusterManagerImpl.configure(ClusterManagerImpl.java:1042)
>   at 
> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114)
>   at 
> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153)
>   at 
> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.configure(CloudStackExtendedLifeCycle.java:110)
>   at 
> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:56)
>   at 
> org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167)
>   at 
> org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
>   at 
> org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339)
>   at 
> org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143)
>   at 
> org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108)
>   at 
> org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:945)
>   at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
>   at 
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
>   at 
> org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
>   at 
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
>   at 
> org.apache.cloudstack.spring.module.factor

[jira] [Commented] (CLOUDSTACK-8616) Redundant VPC with both routers as Master

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629171#comment-14629171
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8616:


Github user bhaisaab commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/587#discussion_r34755507
  
--- Diff: systemvm/patches/debian/config/opt/cloud/bin/cs/CsFile.py ---
@@ -35,10 +35,9 @@ def load(self):
 self.new_config.append(line)
 except IOError:
 logging.debug("File %s does not exist" % self.filename)
-return
 else:
 logging.debug("Reading file %s" % self.filename)
-self.config = copy.deepcopy(self.new_config)
+self.config = list(self.new_config)
--- End diff --

Alright, as I mentioned in my comment if the list contains (references to) 
other objects then only copy.deepcopy should be used. I was not clear about the 
usage, after reading the code I think it would work since we're working with 
list of strings (read from file), followed by append/insert operations; list() 
would be indeed faster than copy.deepcopy in this case as well.


> Redundant VPC with both routers as Master
> -
>
> Key: CLOUDSTACK-8616
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8616
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> There is an intermittent problem with the keepalived on the redundant VPC 
> routers. Sometimes both routers stay on Master state for a while.
> We are able to reproduce it only when testing with Marvin, which executes the 
> calls very quick. When using the UI and following the same steps, it doesn't 
> happen.
> Setting up:
> 1. Create a VPC using redundant VPC offering
> 2. Add 2 Tiers
> 3. Create 2 VMs in each Tier
> 4. Create ACLs to allow traffic on port 22 coming from 0.0.0.0/0
> 5. Acquire 4 public IPs
> 6. Create Port Forwarding rules - per IP - for port 22
> 7. Assign each PF created to one of the VMs
> 8. SSH to the VMs
> Testing fail over:
> 1. Stop the Master Router
> 2. Check the the Backup Router became Master
> 3. SSH to the VMs 
> Testing failure:
> 1. Delete all port forwarding rules
> 2. SSH to the VMs 
> 3. Verify that it no longer works
> Test recovering
> 1. Restart the router
> 2. Once the router is running, check that it's on Backup state
> 3. Add the port forwarding rules back
> 4. Verify that the routers are still on the same state: 1 Master and 1 Backup
> - That's the part when it fails during the Marvin tests
> - When 2 routers are on Master, by restarting 1 router will bring 
> everything to a normal state: 1 master and 1 backup
> 5. SSH to the VMs 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8616) Redundant VPC with both routers as Master

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629173#comment-14629173
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8616:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/587#issuecomment-121827701
  
LGTM, though did not test it due to lack of time and test infrastructure.


> Redundant VPC with both routers as Master
> -
>
> Key: CLOUDSTACK-8616
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8616
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> There is an intermittent problem with the keepalived on the redundant VPC 
> routers. Sometimes both routers stay on Master state for a while.
> We are able to reproduce it only when testing with Marvin, which executes the 
> calls very quick. When using the UI and following the same steps, it doesn't 
> happen.
> Setting up:
> 1. Create a VPC using redundant VPC offering
> 2. Add 2 Tiers
> 3. Create 2 VMs in each Tier
> 4. Create ACLs to allow traffic on port 22 coming from 0.0.0.0/0
> 5. Acquire 4 public IPs
> 6. Create Port Forwarding rules - per IP - for port 22
> 7. Assign each PF created to one of the VMs
> 8. SSH to the VMs
> Testing fail over:
> 1. Stop the Master Router
> 2. Check the the Backup Router became Master
> 3. SSH to the VMs 
> Testing failure:
> 1. Delete all port forwarding rules
> 2. SSH to the VMs 
> 3. Verify that it no longer works
> Test recovering
> 1. Restart the router
> 2. Once the router is running, check that it's on Backup state
> 3. Add the port forwarding rules back
> 4. Verify that the routers are still on the same state: 1 Master and 1 Backup
> - That's the part when it fails during the Marvin tests
> - When 2 routers are on Master, by restarting 1 router will bring 
> everything to a normal state: 1 master and 1 backup
> 5. SSH to the VMs 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8581) Make S3 TCP KeepAlive and ConnectionTtl configureable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629174#comment-14629174
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8581:


Github user bhaisaab commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/582#discussion_r34755599
  
--- Diff: api/src/com/cloud/agent/api/to/S3TO.java ---
@@ -118,6 +122,14 @@ public boolean equals(final Object thatObject) {
 return false;
 }
 
+if (connectionTtl != null ? 
!connectionTtl.equals(thatS3TO.connectionTtl) : thatS3TO.connectionTtl != null) 
{
+return false;
--- End diff --

LGTM, other than the complex ternary in the if().


> Make S3 TCP KeepAlive and ConnectionTtl configureable
> -
>
> Key: CLOUDSTACK-8581
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8581
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.6.0
>
>
> Currently we can not set the TCP KeepAlive and ConnectionTtl settings for the 
> Amazon S3 ClientConfiguration class: 
> http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/ClientConfiguration.html
> Our S3Util doesn't set these values so it defaults to what Amazon configures.
> This doesn't work in all situations and we want to make this configurable. 
> For example the ConnectionTtl should be lowered in cases where the Object 
> Store closes a HTTP connection after a very short period.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8628) Ceph RBD only cluster with KVM does not fence properly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629175#comment-14629175
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8628:


Github user bhaisaab commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/580#discussion_r34755639
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtFenceCommandWrapper.java
 ---
@@ -48,6 +48,18 @@ public Answer execute(final FenceCommand command, final 
LibvirtComputingResource
 final KVMHAMonitor monitor = libvirtComputingResource.getMonitor();
 
 final List pools = monitor.getStoragePools();
+
+/**
+ * We can only safely fence off hosts when we use NFS
+ * On NFS primary storage pools hosts continuesly write
+ * a heartbeat. Disable Fencing Off for hosts without NFS
+ */
+if (pools.size() == 0) {
+String logline = "No NFS storage pools found. No way to safely 
fence " + command.getVmName() + " on host " + command.getHostGuid();
--- End diff --

maybe add an alert for admin here, _alertMgr.sendAlert?


> Ceph RBD only cluster with KVM does not fence properly
> --
>
> Key: CLOUDSTACK-8628
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8628
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: Future, 4.6.0
>
>
> When a NFS storage pool is present on a KVM cluster that pool is used for 
> writing heartbeats to.
> In case of a Ceph (RBD) only cluster such pools are not available and thus 
> the KVM hosts do not write any heartbeats.
> Should the KVM Agent crash for any reason they will be fenced of directly and 
> this will cause a split-brain situation.
> Fencing should not happen when no NFS storage pool is present as it is 
> dangerous for data consistency. A Instance could be running on two hosts at 
> the same time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8626) [Automation]fixing test/integration/component/test_ps_max_limits.py for lxc hypervisor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629179#comment-14629179
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8626:


Github user asfgit closed the pull request at:

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


> [Automation]fixing  test/integration/component/test_ps_max_limits.py for lxc 
> hypervisor 
> 
>
> Key: CLOUDSTACK-8626
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8626
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.1
>
>
> ==>Deploy vm with data disk is failing on lxc setup since "rbd" storage is 
> not available .
> ==>modifying script to deploy vm without data disk since test case does not 
> require data disk 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8626) [Automation]fixing test/integration/component/test_ps_max_limits.py for lxc hypervisor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629176#comment-14629176
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8626:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/579#issuecomment-121828476
  
LGTM


> [Automation]fixing  test/integration/component/test_ps_max_limits.py for lxc 
> hypervisor 
> 
>
> Key: CLOUDSTACK-8626
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8626
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.1
>
>
> ==>Deploy vm with data disk is failing on lxc setup since "rbd" storage is 
> not available .
> ==>modifying script to deploy vm without data disk since test case does not 
> require data disk 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8626) [Automation]fixing test/integration/component/test_ps_max_limits.py for lxc hypervisor

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629177#comment-14629177
 ] 

ASF subversion and git services commented on CLOUDSTACK-8626:
-

Commit 8e1f01d7798dfc5d0bbafc70e31636038ed21a00 in cloudstack's branch 
refs/heads/master from nitt10prashant
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8e1f01d ]

CLOUDSTACK-8626 :[Automation]fixing 
test/integration/component/test_ps_max_limits.py for lxc hypervisor

Signed-off-by: Rohit Yadav 

This closes #579


> [Automation]fixing  test/integration/component/test_ps_max_limits.py for lxc 
> hypervisor 
> 
>
> Key: CLOUDSTACK-8626
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8626
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.1
>
>
> ==>Deploy vm with data disk is failing on lxc setup since "rbd" storage is 
> not available .
> ==>modifying script to deploy vm without data disk since test case does not 
> require data disk 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8605) KVM: Config Drive and getVmIp support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629180#comment-14629180
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8605:


Github user bhaisaab commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/577#discussion_r34755687
  
--- Diff: packaging/centos63/cloud.spec ---
@@ -129,6 +129,8 @@ Requires: perl
 Requires: libvirt-python
 Requires: qemu-img
 Requires: qemu-kvm
+Requires: genisoimage
--- End diff --

you'll need to add this to other cloud.spec files in 
packages/{centos7,fedora20,fedora21}


> KVM: Config Drive and getVmIp support
> -
>
> Key: CLOUDSTACK-8605
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8605
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.6.0
>Reporter: Kishan Kavala
>Assignee: Kishan Kavala
> Fix For: 4.6.0
>
>
> Add support for 
> - creating config drive
> - Fetch IP from guest Vm which is assigned by external DHCP



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7539) [S3] Parallel deployment makes reference count of a cache in nfs secondary staging store negative(-1)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629181#comment-14629181
 ] 

ASF GitHub Bot commented on CLOUDSTACK-7539:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/572#issuecomment-121829053
  
While LGTM and travis seems to be happy about it, my java kung - {locks and 
synchroization} -fu skills are not to be trusted


> [S3] Parallel deployment makes reference count of a cache in nfs secondary 
> staging store negative(-1)
> -
>
> Key: CLOUDSTACK-7539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Template
>Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0
> Environment: OS: CentOS 6.5, CloudStack Version: 4.3.0,  Hypervisor: 
> KVM,  Primary Storage: Local Storage,  Secondary Storage:   S3(RADOS),  Zone: 
>  Advanced
>Reporter: Hiroki Ohashi
>Assignee: Daan Hoogland
>Priority: Critical
> Fix For: 4.5.2
>
>
> When we create some instances in parallel in an environment shown above, an 
> exception like ([#2]) happens. After that, reference count of a cache in NFS 
> Secondary Staging Store(SSS) becomes negative([#3]).
> In this situcation, we can't use a template used for creating the instances 
> because negative reference count will cause another
> exception([#4]). Furthermore, template caches in NFS SSS aren't cleaned up.
> I think this is related to CLOUDSTACK-6236. I'm using CloudStack 4.3.0 
> branch. The code was applied a patch of CLOUDSTACK-6236 to and also fixed 
> about volume reference count setter problem by myself. But the reference 
> count problem still happens.
> Conditions to trigger
>   - A cache of a template isn't on NFS SSS.
>   - Choose compute offering that occupies all resources in a host.(ex. Use 
> all cores and almost all memory)
>   - Create multiple instances ([#1]).
> Other behaviors
>   - Management server inserts multiple entries for template cache(ImageCache) 
> to cloud.template_store_ref.
>   - SSVM probably downloads same template from S3 and creates multiple caches 
> to NFS SSS concurrently. Sometimes, SSVM retries download  and cache creation.
> (1)
> {anchor:1}
> {noformat}
> #! /bin/bash
> COMPUTE_OFFERING="b6fc0598-6903-48cc-b894-ead3bb0e39f5"
> TEMPLATE="ef1d5a8e-5951-4036-a236-fe2d47224fe4"
> ZONE="23156857-4722-4fc4-86d4-a12ca1028197"
> NETWORK="4ba56179-f7b9-4560-a00e-80c946856ff8"
> KEYPAIR=mykey
> NAME1="test-template-error-0003"
> NAME2="test-template-error-0004"
> cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING} 
> templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK} 
> displayname=${NAME1} name=${NAME1} keypair=${KEYPAIR}
> sleep 1
> cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING} 
> templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK} 
> displayname=${NAME2} name=${NAME2} keypair=${KEYPAIR}
> {noformat}
> (2)
> {anchor:2}
> {noformat}
> 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
> Seq 171-1789133096: Processing:  { Ans: , MgmtId: 98532524288, via: 171, Ver: 
> v1, Flags: 10, 
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/3/330/22e69a40-0916-4d11-a07a-63d38e76887f.qcow2","id":0,"accountId":0,"hvm":false,"name":"22e69a40-0916-4d11-a07a-63d38e76887f.qcow2","size":14340259840,"physicalSize":14340259840}},"result":true,"wait":0}}]
>  }
> 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] 
> (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) Seq 171-1789133096: Received:  { 
> Ans: , MgmtId: 98532524288, via: 171, Ver: v1, Flags: 10, { CopyCmdAnswer } }
> 2014-09-10 17:22:51,257 DEBUG [o.a.c.s.i.s.TemplateObject] 
> (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) failed to update state
> com.cloud.utils.fsm.NoTransitionException: Unable to transition to a new 
> state from Allocated via OperationSuccessed
> at 
> com.cloud.utils.fsm.StateMachine2.getNextState(StateMachine2.java:83)
> at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:100)
> at 
> org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.update(ObjectInDataStoreManagerImpl.java:297)
> at 
> org.apache.cloudstack.storage.image.store.TemplateObject.processEvent(TemplateObject.java:225)
> at 
> org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:240)
> at 
> org.apache.cloudstack.storage.cach

[jira] [Commented] (CLOUDSTACK-8549) Update assert statements in testpath_disable_enable_zone.py testpath

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629186#comment-14629186
 ] 

ASF subversion and git services commented on CLOUDSTACK-8549:
-

Commit b73e486d02a7ec84fc221e57cc95b35435e0af2c in cloudstack's branch 
refs/heads/master from [~pritisarap12]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b73e486 ]

CLOUDSTACK-8549-Update test_concurrent_snapshots_limits.py asesrt statement

Signed-off-by: Rohit Yadav 

This closes #386


> Update assert statements in testpath_disable_enable_zone.py testpath 
> -
>
> Key: CLOUDSTACK-8549
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8549
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.1
>Reporter: Priti Sarap
> Fix For: 4.5.1
>
>
> Update the assertNotEquals for verifying the state of VM's to 
> assertEqual("running")



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8549) Update assert statements in testpath_disable_enable_zone.py testpath

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629185#comment-14629185
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8549:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/386#issuecomment-121829533
  
LGTM, really old so merging now


> Update assert statements in testpath_disable_enable_zone.py testpath 
> -
>
> Key: CLOUDSTACK-8549
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8549
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.1
>Reporter: Priti Sarap
> Fix For: 4.5.1
>
>
> Update the assertNotEquals for verifying the state of VM's to 
> assertEqual("running")



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8549) Update assert statements in testpath_disable_enable_zone.py testpath

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629187#comment-14629187
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8549:


Github user asfgit closed the pull request at:

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


> Update assert statements in testpath_disable_enable_zone.py testpath 
> -
>
> Key: CLOUDSTACK-8549
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8549
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.1
>Reporter: Priti Sarap
> Fix For: 4.5.1
>
>
> Update the assertNotEquals for verifying the state of VM's to 
> assertEqual("running")



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8556) Unable to delete attached volume in cleanup

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629190#comment-14629190
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8556:


Github user asfgit closed the pull request at:

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


> Unable to delete attached volume in cleanup
> ---
>
> Key: CLOUDSTACK-8556
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8556
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.1
>Reporter: Priti Sarap
> Fix For: 4.5.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8556) Unable to delete attached volume in cleanup

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629188#comment-14629188
 ] 

ASF subversion and git services commented on CLOUDSTACK-8556:
-

Commit c5d016c372c8e0b1eb1cfc8be9f42c4b6d35a909 in cloudstack's branch 
refs/heads/master from [~pritisarap12]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c5d016c ]

CLOUDSTACK-8556: Unable to delete attached volume in cleanup

Signed-off-by: Rohit Yadav 

This closes #481


> Unable to delete attached volume in cleanup
> ---
>
> Key: CLOUDSTACK-8556
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8556
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.1
>Reporter: Priti Sarap
> Fix For: 4.5.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629191#comment-14629191
 ] 

ASF GitHub Bot commented on CLOUDSTACK-6276:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/508#issuecomment-121829695
  
ping, any update on this? still WIP?


> Affinity Groups within projects
> ---
>
> Key: CLOUDSTACK-6276
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Ingo Jochim
>
> Hello,
> I like to have the features "Affinity Group" and "Project" combined.
> As far as I know I cannot use Affinity Groups within Projects.
> Thanks and regards,
> Ingo



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8556) Unable to delete attached volume in cleanup

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629189#comment-14629189
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8556:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/481#issuecomment-121829664
  
LGTM, squashing and merging; please squash your changes in future as you 
iterate on your PR


> Unable to delete attached volume in cleanup
> ---
>
> Key: CLOUDSTACK-8556
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8556
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.1
>Reporter: Priti Sarap
> Fix For: 4.5.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8582) Fix test cases failing on simulator

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629193#comment-14629193
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8582:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/532#issuecomment-121829768
  
LGTM


> Fix test cases failing on simulator
> ---
>
> Key: CLOUDSTACK-8582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8582
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.6.0
>Reporter: Gaurav Aradhye
>Assignee: Gaurav Aradhye
>  Labels: automation
> Fix For: 4.6.0
>
>
> Fix the test cases failing on simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8308) Add test cases for volume/VM snapshot test path

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629194#comment-14629194
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8308:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/384#issuecomment-121829822
  
Ping, any updates?


> Add test cases for volume/VM snapshot test path
> ---
>
> Key: CLOUDSTACK-8308
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8308
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: Future
>Reporter: Priti Sarap
>  Labels: automation
> Fix For: Future
>
>
> Add test cases for volume/VM snapshot test path



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8483) Private template not visible in project

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629196#comment-14629196
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8483:


Github user bhaisaab commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/334#discussion_r34755962
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/user/template/CreateTemplateCmd.java 
---
@@ -124,6 +127,9 @@
description = "true if template contains XS/VMWare tools 
inorder to support dynamic scaling of VM cpu/memory")
 protected Boolean isDynamicallyScalable;
 
+@Parameter(name = ApiConstants.PROJECT_ID, type = CommandType.UUID, 
entityType = ProjectResponse.class, description = "create template for the 
project")
+private Long projectId;
--- End diff --

Ping. Since, this is an append only API change. IMO we can merge on 4.5 as 
well.
Updates, is this good to go?


> Private template not visible in project
> ---
>
> Key: CLOUDSTACK-8483
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8483
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Projects
>Affects Versions: 4.5.0
>Reporter: Sudhansu Sahu
>Assignee: Sudhansu Sahu
>
> Private template get created outside the project context. These templates are 
> not visible in project view.
> STEPS TO REPRODUCE:
> 1 Select a project view, and go into volumes view
> 2 Create a template from a Volume and wait until the process is complete
> 3 The template cannot be found in the project
> 4 Navigate back to the "Default view" The template can be found in the 
> templates screen in this view



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8582) Fix test cases failing on simulator

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629198#comment-14629198
 ] 

ASF subversion and git services commented on CLOUDSTACK-8582:
-

Commit d73f64a518f1f6b3721570afb3a7e0be99b120b5 in cloudstack's branch 
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d73f64a ]

CLOUDSTACK-8582: Skipping unsuitable test cases for simulator

Signed-off-by: Rohit Yadav 

This closes #532


> Fix test cases failing on simulator
> ---
>
> Key: CLOUDSTACK-8582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8582
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.6.0
>Reporter: Gaurav Aradhye
>Assignee: Gaurav Aradhye
>  Labels: automation
> Fix For: 4.6.0
>
>
> Fix the test cases failing on simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8582) Fix test cases failing on simulator

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629199#comment-14629199
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8582:


Github user asfgit closed the pull request at:

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


> Fix test cases failing on simulator
> ---
>
> Key: CLOUDSTACK-8582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8582
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.6.0
>Reporter: Gaurav Aradhye
>Assignee: Gaurav Aradhye
>  Labels: automation
> Fix For: 4.6.0
>
>
> Fix the test cases failing on simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8632) Unable to revert snapshot on XenServer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629252#comment-14629252
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8632:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/590#issuecomment-121843137
  
LGTM


> Unable to revert snapshot on XenServer
> --
>
> Key: CLOUDSTACK-8632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: Priti Sarap
>  Labels: snapshot
> Fix For: 4.2.1
>
>
> On XenServer Volume snapshot fails for the volume which is attached to the VM 
> having VM snapshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8580) Users should be able to expunge VMs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629254#comment-14629254
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8580:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/593#issuecomment-121843328
  
LGTM :+1: 


> Users should be able to expunge VMs
> ---
>
> Key: CLOUDSTACK-8580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8580
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Lennert den Teuling
>Priority: Minor
>
> When automating deployments of CloudStack (with for example Terraform) there 
> are situations where VMs get recreated with the same name (and hostname). 
> When VMs are destroyed by a user, the name will be reserved on the network 
> until the VM truly gets expunged (depending on expunge.delay). Because of 
> this, some automation tools cannot work because a new deployment with the 
> same name gives an error.  
> Users do not have the ability to directly expunge VMs (Only admin and 
> domain-admins can), but they can destroy them and the admin can configure the 
> expunge.delay where VMs truly get removed (expunged). 
> Working with the expunge delay is very safe in case users accidentally remove 
> a VM, but in some cases (when users know what they are doing) there should 
> also be a option to completely remove the VM when destroying it (expunge). 
> Ideally the admin should be able to configure this behavior trough the global 
> settings, cause i believe the admin deliberately needs to turn it on (off by 
> default).
> We have looked into making our clients domain-admin by default, but that 
> gives them abilities we do not want to give, so we see no other way then just 
> enabling expunge for the user. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8639) fixing calculation mistakes in component/test_ss_domain_limits.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629258#comment-14629258
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8639:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/595#issuecomment-121843873
  
I browsed the code and found out that this "templateSize = 
int(int(templates[0].size) / (1024**3))" was already been used in other places. 
So, your changes does make sense to me and therefore you get a LGTM :+1: 

Cheers,
Wilder


> fixing calculation mistakes in component/test_ss_domain_limits.py
> -
>
> Key: CLOUDSTACK-8639
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8639
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.5.1
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
> Fix For: 4.5.1
>
>
> expectedCount=int(int(templates[0].size) / (1024**3))
> expectedCount *= 2
> if template[0].size is less that one GB , expectedCount will be 0
> so expectedCount*=2  will not have any effect . 
> fixing expectedCount calculation:
> self.templateSize = int((int(templates[0].size)*2) / (1024**3))
> expectedCount =self.templateSize



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8608) Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629260#comment-14629260
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8608:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/555#issuecomment-121844265
  
Travis failed due to a timeout.

I will have a look at the code.


> Fix unpleasant admin experience with VMware fresh installs/upgrades - System 
> VM's failed to start due to permissions issue
> --
>
> Key: CLOUDSTACK-8608
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8608
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
> Fix For: 4.6.0
>
>
> VMware uses a folder in machine where management server is running to mount 
> secondary storage. This is a bootstrap phase to start system vm, because 
> unlike KVM, Xenserver, management server cannot directly access VMWare ESXI 
> host to download systemvm template from secondary storage to primary storage. 
> The secondary storage is usually managed by SSVM that uses root account to 
> download templates. However, management server is using account 'cloud' to 
> manipulate templates after secondary storage is mounted. After admin 
> registers new systemvm template in CS as a normal upgrade procedure, the old 
> SSVM will download the template using account root, but management server 
> will create new SSVM from the new template using account 'cloud'. Then a 
> permission denied error will raise.
> Prior to 4.4, CS used to handle this by running 'chmod -R' to the folder to 
> which secondary storage is mounted every time management server mounts 
> secondary storage. Unfortunately, this method is slow because we  are trying 
> to give permissions to the entire folder. So in 4.4, we stopped automatically 
> providing the permissions and asked admin to manually run 'chmod -R' to the 
> folder 'templates' on secondary storage, after registering new systemvm 
> template.
> We can avoid this manual admin step by only providing permissions for the 
> /templates folder instead of the entire folder. This way we will avoid the 
> snapshots folder which could be very large in upgrade setups.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629284#comment-14629284
 ] 

ASF GitHub Bot commented on CLOUDSTACK-6276:


Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/508#issuecomment-121846292
  
hey @bhaisaab, still WIP. I ask for some help to finish it on the ML, 
because I will not have time to work on it the next months.


> Affinity Groups within projects
> ---
>
> Key: CLOUDSTACK-6276
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Ingo Jochim
>
> Hello,
> I like to have the features "Affinity Group" and "Project" combined.
> As far as I know I cannot use Affinity Groups within Projects.
> Thanks and regards,
> Ingo



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8588) Remove redundant skip test for LXC

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629292#comment-14629292
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8588:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/526#issuecomment-121846745
  
@bhaisaab @DaanHoogland , could you also have a look at this one?

It LGTM

Cheers,
Wilder


> Remove redundant skip test for LXC 
> ---
>
> Key: CLOUDSTACK-8588
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8588
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.1
>Reporter: Priti Sarap
> Fix For: 4.5.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8588) Remove redundant skip test for LXC

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629301#comment-14629301
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8588:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/526#issuecomment-121848960
  
LGTM


> Remove redundant skip test for LXC 
> ---
>
> Key: CLOUDSTACK-8588
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8588
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.1
>Reporter: Priti Sarap
> Fix For: 4.5.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629304#comment-14629304
 ] 

ASF GitHub Bot commented on CLOUDSTACK-6276:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/508#issuecomment-121849880
  
Hi @resmo and @bhaisaab 

I will check with @remibergsma / @DaanHoogland / @snuf if that's something 
we could get involved in. I'm okay with helping, as long as I have some time 
dedicated in our sprints.

Would you have some more details on how far you are, @resmo ? Will it break 
existing functionality if we merge? If not and if I get the time, we can get it 
merge and I will continue from where you left.

Cheers,
Wilder


> Affinity Groups within projects
> ---
>
> Key: CLOUDSTACK-6276
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Ingo Jochim
>
> Hello,
> I like to have the features "Affinity Group" and "Project" combined.
> As far as I know I cannot use Affinity Groups within Projects.
> Thanks and regards,
> Ingo



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)