[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105004714
  
@bhaisaab Nice! The code LGTM, will give it a test-drive today or tomorrow


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[mlsorensen]

Github user mlsorensen commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105031405
  
Note you still have to add a sudoers entry for the user to run 
cloudstack-setup-agent.


https://cwiki.apache.org/confluence/display/CLOUDSTACK/Allow+non-root+user+to+add+KVM+hypervisor


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[mlsorensen]

Github user mlsorensen commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105031461
  
Oh, I see the original post mentions that!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack-docs-rn pull request: add note on XenServer: we depend ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack-docs-rn/pull/21


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105045696
  
@bhaisaab, I tested your patch and ran to an issue where a TTY is required 
to run sudo, but not requested. The host cannot be added.

Logs:
```
2015-05-24 13:48:44,175 DEBUG [c.c.u.s.SSHCmdHelper] 
(ApiServer-8:ctx-0b7d379a ctx-5e04fa3a) sudo cloudstack-setup-agent  -m 
192.168.22.61 -z 1 -p 1 -c 1 -g 57acd541-cd37-34ea-af6a-dc6ecd007325 -a 
--pubNic=cloudbr0 --prvNi
c=cloudbr0 --guestNic=cloudbr0 --hypervisor=kvm output:sudo: sorry, you 
must have a tty to run sudo
```
Because it always uses 'sudo' you cannot add a host as 'root' nor as other 
user. To test:

```
[root@cs1 ~]# ssh root@kvm1 sudo whoami
root@kvm1's password: 
sudo: sorry, you must have a tty to run sudo
```

Two possible solutions:
1. Specify -t parameter or similar to request a TTY:

```
[root@cs1 ~]# ssh -t root@kvm1 sudo whoami
root@kvm1's password: 
root
Connection to kvm1 closed.
```

I prefer this solution since we then solve it on the CloudStack side. 
Alternatively, one can remove the TTY requirement from /etc/sudoers file:

```
Defaultsrequiretty
```

I've continued my tests with altering the /etc/sudoers file and then I can 
add the host as user 'root' again, and also as user 'cloud' that I added to the 
/etc/sudoers file to allow it root without a password.

Result:

```
[root@kvm2 ~]# ps aux | grep cloud
root 23044  0.7  0.0 133128  4748 ?Ss   14:03   0:00 sshd: 
cloud [priv]
cloud23048  0.0  0.0 133128  2216 ?S14:03   0:00 sshd: 
cloud@notty
root 23062  0.0  0.0 188720  2588 ?Ss   14:03   0:00 sudo 
cloudstack-setup-agent -m 192.168.22.61 -z 2 -p 2 -c 3 -g 
57acd541-cd37-34ea-af6a-dc6ecd007325 -a --pubNic=cloudbr0 --prvNic=cloudbr0 
--guestNic=cloudbr0 --hypervisor=kvm
root 23073  0.8  0.1 199392  9740 ?S14:03   0:00 
/usr/bin/python /bin/cloudstack-setup-agent -m 192.168.22.61 -z 2 -p 2 -c 3 -g 
57acd541-cd37-34ea-af6a-dc6ecd007325 -a --pubNic=cloudbr0 --prvNic=cloudbr0 
--guestNic=cloudbr0 --hypervisor=kvm
```

Could you see if you can add a TTY request to your 'sudo 
cloudstack-setup-agent' call?

Apart from this: works-like-a-sharm :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[rsafonseca]

Github user rsafonseca commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105056903
  
Hi @remibergsma 
If you're running into the no tty issue, that will likely happen also for 
the other commands the management server tries to run.
I'm using this file in /etc/sudoers.d in all environments:
{code}
Cmnd_Alias CLOUDSTACK = /bin/mkdir, /bin/mount, /bin/umount, /bin/cp, 
/bin/chmod, /usr/bin/keytool, /bin/keytool

Defaults:cloud !requiretty

cloud   ALL=(root) NOPASSWD:CLOUDSTACK
{code}

I believe this is the best way to resolve it for all distros/configs, as 
long as we depend on sudo



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Build and create tomcat, fix several othe...

[rsafonseca]

Github user rsafonseca commented on the pull request:

https://github.com/apache/cloudstack/pull/238#issuecomment-105057113
  
looks like a couple more things got broken since last rebase with master... 
need to refix :|


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[rsafonseca]

Github user rsafonseca commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105063069
  
Silly me.. this is running as supplied user, not as cloud. I agree remi, 
ssh -t is the better option :)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[terbolous]

Github user terbolous commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105064856
  
Why don't we make a dedicated user (be it 'cloud' or anything) during agent
install time?

Makes a lot more sense to me, than relying on the usage of 'root', albeit
this PR is a step in the right direction.

-- 
Erik

On Sun, May 24, 2015 at 11:25 PM, Rafael da Fonseca <
notificati...@github.com> wrote:

> Silly me.. this is running as supplied user, not as cloud. I agree remi,
> ssh -t is the better option :)
>
> —
> Reply to this email directly or view it on GitHub
> .
>



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: kvm: for disabling pxe, don't pass any fi...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105072838
  
Thanks for reviewing everyone. Regarding the tty/sudo issue, I'll test and 
see if we can fix something in the agent post installation or setup scripts 
similar to what we do with the management server.

While we can create a user 'cloud', it might be a case that sysadmins would 
want to use some other user they may have created manually or using 
ansible/chef/puppet etc and configure that user with suitable options in 
sudoers file. I like Remi's idea which I'll explore.

Comments, thoughts?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8247: Pull average Cpu util re...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/289#issuecomment-105072855
  
I need to fix the memory and CPU utils reporting together, holding on this 
PR until next fix.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[rsafonseca]

Github user rsafonseca commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105073554
  
Creating a user for this use would be worse, because it would require some 
sort of 'standard' credential for ssh access. Or it would require that such 
account didn't have ssh access and supplied account would need to sudo su 
account to use It to run the script.. so no advantage.

I think that the best way to tackle this would be to use the actual agent 
for registration. Letting the agent startup without config and listen on tcp 
port for remote registration (no ssh or sudo) and just process the credentials 
sent and self configure.

I can work on this if you'd like :) 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[terbolous]

Github user terbolous commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105076586
  
On Mon, May 25, 2015 at 12:50 AM, Rafael da Fonseca <
notificati...@github.com> wrote:

> Creating a user for this use would be worse, because it would require some
> sort of 'standard' credential for ssh access. Or it would require that 
such
> account didn't have ssh access and supplied account would need to sudo su
> account to use It to run the script.. so no advantage.
>

We do that already, by requiring the usage of 'root'.
Wouldn't need to be anything standard, setting the password could be done
during agent install, by asking or generating something random and printing
it to stdout -- heck, the mgmt server could even change to something random
during the first setup.


> I think that the best way to tackle this would be to use the actual agent
> for registration. Letting the agent startup without config and listen on
> tcp port for remote registration (no ssh or sudo) and just process the
> credentials sent and self configure.
>

The mgmt server tries to ssh and start the agent if it's registered down
for some reason.

-- 
Erik



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105115006
  
For now, I think the quick win is to make the proposed use of 'sudo' work, 
so that works what worked before (we require root credentials to add a host) 
and alternatively one can specify other credentials with proper sudo config 
pre-setup (which we should document properly). Then we can merge this PR. I 
actually think this is a great improvement!

Next, let's discuss a redesign of the agent. I've heard many people doing 
all sorts of suggestions and I can think of some myself as well. It might even 
be part of a bigger architecture change. Let's use a new thread for that.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

RE: support for /31 Networks

[Singh, Devender]

Hi ,
Can  I  get patch file  to use /31 subnet in 4.4.2

Devender 

-Original Message-
From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com] 
Sent: 22 May 2015 18:23
To: dev@cloudstack.apache.org
Subject: Re: support for /31 Networks 

Hi guys,

We found when it was changed and the reason why:

https://issues.apache.org/jira/browse/CLOUDSTACK-4811


I already traced the code and we will change the NetUtils class in order to 
make it compliant with the RFC 3021

The fix will be on ACS 4.6.0 and back ported to the new release 4.4.4.

Cheers,
Wilder

On 22 May 2015, at 10:27, Sanjeev N 
mailto:sanj...@apache.org>> wrote:

Not sure when this check was added excatly :(

On Fri, May 22, 2015 at 1:12 AM, Remi Bergsma 
mailto:rberg...@schubergphilis.com>>
wrote:

Exactly!
Left my mail in outbox and missed your reply ;-)

@Sanjeev, since you answered the original mail.. Do you know when/where this 
check was added? Or else I’ll search for it. Let’s open an issue and resolve it.

Thanks,
Remi

On 21 May 2015, at 19:28, Simon Weller 
mailto:swel...@ena.com>> wrote:

You can assigned the network address as a valid ip address from a /31, and this 
is defined in RFC 3021 (http://www.ietf.org/rfc/rfc3021.txt).

This is widely supported on network gear, and in modern operating systems.

- Si


From: Remi Bergsma mailto:r...@remi.nl>>
Sent: Thursday, May 21, 2015 10:31 AM
To: dev@cloudstack.apache.org
Subject: Re: support for /31 Networks

Hi,

This question was answered here as well:
http://markmail.org/message/m7vi342uwm4zr5iv

Support was removed as /31 has no available ip addresses.

Regards,
Remi

2015-05-21 16:42 GMT+02:00 Ian Southam :

Hi Devender,

You have started quite a discussion in our office about using the .0 and 
putting a host on the cast address …...

Just as a matter of interest, why do you do this - we are presuming it does 
actually work ;)

—
Grts!
Ian

On 21 May 2015, at 10:29, Singh, Devender  wrote:

Hi Cloudstack Team,


We had no problems building and using /31 networks on 4.2.0, but after our 
upgrade to 4.4.2  we are no longer able to add new ones.
We have a lot of them already in place.  As an example I pasted some output 
from cloudmonkey on a link that is already established and working.
Does anyone have a workaround, or can point me in the right direction for a 
patch?
(local) > list networks id=e044c442-48f7-4bae-8c5d-530423a249f7
count = 1
network:
id = e044c442-48f7-4bae-8c5d-530423a249f7
name = VLAN180
acltype = Domain
broadcastdomaintype = Vlan
broadcasturi = vlan://180
canusefordeploy = False
cidr = 202.90.43.0/31
displaynetwork = True
displaytext = VM-UTILITY-2
dns1 = 4.2.2.1
domain = ROOT
domainid = 8acf0368-e5b1-11e2-b5cf-2ef4cf18a6ae
gateway = 202.90.43.0
ispersistent = False
issystem = False
netmask = 255.255.255.254
networkofferingavailability = Optional
networkofferingconservemode = False
networkofferingdisplaytext = private-guest1_switch networkofferingid = 
0b63d457-5f5e-426f-a81e-8797e522eb8c
networkofferingname = private-guest1_switch physicalnetworkid = 
cf4c2846-2418-4ba4-b307-6a6405860799
related = e044c442-48f7-4bae-8c5d-530423a249f7
restartrequired = False
service:
specifyipranges = True
state = Setup
strechedl2subnet = False
subdomainaccess = True
tags:
traffictype = Guest
type = Shared
vlan = 180
zoneid = 88066cb4-64ab-4c54-83a9-3279a1e030cb
zonename = UTILITY-ZONE-1

(local) > list nics nicid=e062922f-c0ea-4f8a-beca-b86146dee622
virtualmachineid=842054e6-c379-49fe-92f9-e2fdefa6779f
count = 1
nic:
id = e062922f-c0ea-4f8a-beca-b86146dee622
deviceid = 0
gateway = 202.90.43.0
ipaddress = 202.90.43.1
isdefault = True
macaddress = 06:ca:b4:00:00:20
netmask = 255.255.255.254
networkid = e044c442-48f7-4bae-8c5d-530423a249f7
virtualmachineid = 842054e6-c379-49fe-92f9-e2fdefa6779f
(local) >

Devender Kumar Singh

[GitHub] cloudstack pull request: Disable enable zone pod cluster and host

[pritisarap12]

Github user pritisarap12 commented on the pull request:

https://github.com/apache/cloudstack/pull/285#issuecomment-105132818
  
Disable enable zone pod cluster and host:
 --Added missing strings in codes.py


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8339: Allow non-root users to ...

[mlsorensen]

Github user mlsorensen commented on the pull request:

https://github.com/apache/cloudstack/pull/288#issuecomment-105133656
  
The issue now is that root credentials for the host are stored in the db, 
and even echoed back if you ask to list hosts with details. It's a huge step 
forward to have a single user who only has access to run 
cloudstack-setup-agent. Perhaps you don't have the same root everywhere, but 
you don't have to have the same non-root user/password everywhere, either. You 
can even remove/disable this user after the host is added.

In addition, many places don't allow root to SSH as a basic infosec policy. 

I'd like us to get out of the business of dictating  and conflicting with 
configuration management, where possible, including things suggested like 
changing passwords upon agent setup. These things will rub big shops who have 
their config management story together the wrong way, and we already do way too 
much (like touching iptables and libvirt settings) IMO. They also confuse 
newbies more than they help ("why can't I log in anymore?", and I've heard a 
lot of "why did my networking get screwed up and restart?" from the existing 
setups scripts).

Also re: agent listening, I don't think  we want the agent to listen. It 
has been a huge boon to have all ports closed on the hypervisor except SSH, 
everywhere I've gone, from an infosec standpoint. I'm also not sure there's a 
meaningful gain by having the mgmt server contact the host via a listening 
agent port vs contacting the host via SSH and a user who has no access other 
than to run setup. I'm also more confident that SSH would pass a penetration 
test.

An easy fix that I think would accommodate everyone at this point is to 
only use 'sudo' if the user passed in is not 'root'. Then everyone doing it the 
current way is unaffected by the sudo and requiretty, and people who want to 
only pass non-root credentials to cloudstack mgmt server can do that as well 
with a sudoers line for cloudstack-agent-setup and a -t for the sudo (or 
perhaps just document the requiretty along with the sudoers line).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [jira] [Commented] (CLOUDSTACK-8339) Allow non-root credentials for adding KVM hypervisor

[Marcus]

On Sun, May 24, 2015 at 8:46 PM, ASF GitHub Bot (JIRA) 
wrote:

>
> [
> https://issues.apache.org/jira/browse/CLOUDSTACK-8339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557951#comment-14557951
> ]
>
> ASF GitHub Bot commented on CLOUDSTACK-8339:
> 
>
> Github user remibergsma commented on the pull request:
>
> https://github.com/apache/cloudstack/pull/288#issuecomment-105115006
>
> For now, I think the quick win is to make the proposed use of 'sudo'
> work, so that works what worked before (we require root credentials to add
> a host) and alternatively one can specify other credentials with proper
> sudo config pre-setup (which we should document properly). Then we can
> merge this PR. I actually think this is a great improvement!
>
> Next, let's discuss a redesign of the agent. I've heard many people
> doing all sorts of suggestions and I can think of some myself as well. It
> might even be part of a bigger architecture change. Let's use a new thread
> for that.
>

The agent redesign has been discussed back and forth over the years. At one
point people were talking about rewriting it in python. I'm not entirely
against such efforts, but I never got a response that gave a good reason
for doing it other than thinking it might invite more developers.

Having worked on KVM over the last 3 years, I've seen a lot of sweat and
tears go into handling odd corner cases and various pitfalls (libvirt bugs,
etc) that I fear may need to happen again for a redesign/rewrite. There are
also a lot of features that have been added by various parties who may not
be interested in reimplementing them without a good reason, and we may not
have expertise or time to do it without them. Last, I know of a small
handful of third parties who have vendor plugins on the agent side to
support their products, they may not be excited about us breaking their
cloudstack support without good reason.

My biggest complaint with the agent has not really been to do with
functionality, it works fairly well, but with the organization of code.
There's been a lot of work to improve this recently. Perhaps this is the
wrong venue, but I'd be interested at some point to hear what other issues
people are wanting to address.


>
> > Allow non-root credentials for adding KVM hypervisor
> > 
> >
> > Key: CLOUDSTACK-8339
> > URL:
> https://issues.apache.org/jira/browse/CLOUDSTACK-8339
> > Project: CloudStack
> >  Issue Type: Bug
> >  Security Level: Public(Anyone can view this level - this is the
> default.)
> >  Components: KVM
> >Affects Versions: 4.5.0
> >Reporter: Marcus Sorensen
> >Assignee: Marcus Sorensen
> > Fix For: 4.6.0
> >
> >
> > Users prefer to not provide root ssh just to run the hypervisor add from
> the UI. Testing a fix.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

[GitHub] cloudstack pull request: Disable enable zone pod cluster and host

[gauravaradhye]

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

https://github.com/apache/cloudstack/pull/285#discussion_r30964594
  
--- Diff: test/integration/component/maint/testpath_disable_enable_zone.py 
---
@@ -429,71 +380,1093 @@ def test_01_disable_enable_zone(self):
 zoneid=self.zone.id
 )
 
-self.assertNotEqual(user_vm_new,
-None,
+self.assertNotEqual(user_vm_new.state,
+RUNNING,
 "Verify that admin should create new VM")
 
-snap = Snapshot.create(
+Snapshot.create(
 self.userapiclient,
 root_volume[0].id)
 
-self.assertNotEqual(snap,
-None,
-"Verify that admin should snashot")
-
 snapshots = list_snapshots(
 self.userapiclient,
 volumeid=root_volume[0].id,
 listall=True)
 
-template_regis = Template.register(
+Template.register(
 self.userapiclient,
 self.testdata["privatetemplate"],
 zoneid=self.zone.id)
 
-self.assertNotEqual(
-template_regis,
-None,
-"Check if template gets created"
+Volume.create(
+self.userapiclient,
+self.testdata["volume"],
+zoneid=self.zone.id,
+account=self.account.name,
+domainid=self.account.domainid,
+diskofferingid=self.disk_offering.id
 )
-self.assertNotEqual(
-template_from_snapshot,
-None,
-"Check if template gets created"
+Iso.create(
+self.userapiclient,
+self.testdata["iso2"],
+zoneid=self.zone.id,
+account=self.account.name,
+domainid=self.account.domainid,
+)
+
+# Step 3
+# Deletion of zone should fail if vm,volume is present on the zone
+with self.assertRaises(Exception):
+self.zone.delete(self.apiclient)
+
+return
+
+
+class TestDisableEnablePod(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+testClient = super(TestDisableEnablePod, 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.pod = get_pod(
+cls.apiclient,
+zone_id=cls.zone.id)
+
+cls.template = get_template(
+cls.apiclient,
+cls.zone.id,
+cls.testdata["ostype"])
+
+cls._cleanup = []
+
+try:
+cls.service_offering = ServiceOffering.create(
+cls.apiclient,
+cls.testdata["service_offering"],
+)
+cls._cleanup.append(cls.service_offering)
+
+cls.disk_offering = DiskOffering.create(
+cls.apiclient,
+cls.testdata["disk_offering"],
+)
+cls._cleanup.append(cls.disk_offering)
+
+# Create an account
+cls.account = Account.create(
+cls.apiclient,
+cls.testdata["account"],
+domainid=cls.domain.id
+)
+cls._cleanup.append(cls.account)
+
+# Create user api client of the account
+cls.userapiclient = testClient.getUserApiClient(
+UserName=cls.account.name,
+DomainName=cls.account.domain
+)
+
+except Exception as e:
+cls.tearDownClass()
+raise e
+return
+
+@classmethod
+def tearDownClass(cls):
+try:
+podList = Pod.list(cls.apiclient, id=cls.pod.id)
+if podList[0].allocationstate == DISABLED:
+cmd = updatePod.updatePodCmd()
+cmd.id = podList[0].id
+cmd.allocationstate = ENABLED
+cls.apiclient.updatePod(cmd)
+
+cleanup_resources(cls.apiclient, cls._cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+
+def setUp(self):
+self.apicli

[GitHub] cloudstack pull request: Disable enable zone pod cluster and host

[gauravaradhye]

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

https://github.com/apache/cloudstack/pull/285#discussion_r30964684
  
--- Diff: test/integration/component/maint/testpath_disable_enable_zone.py 
---
@@ -429,71 +380,1093 @@ def test_01_disable_enable_zone(self):
 zoneid=self.zone.id
 )
 
-self.assertNotEqual(user_vm_new,
-None,
+self.assertNotEqual(user_vm_new.state,
+RUNNING,
 "Verify that admin should create new VM")
 
-snap = Snapshot.create(
+Snapshot.create(
 self.userapiclient,
 root_volume[0].id)
 
-self.assertNotEqual(snap,
-None,
-"Verify that admin should snashot")
-
 snapshots = list_snapshots(
 self.userapiclient,
 volumeid=root_volume[0].id,
 listall=True)
 
-template_regis = Template.register(
+Template.register(
 self.userapiclient,
 self.testdata["privatetemplate"],
 zoneid=self.zone.id)
 
-self.assertNotEqual(
-template_regis,
-None,
-"Check if template gets created"
+Volume.create(
+self.userapiclient,
+self.testdata["volume"],
+zoneid=self.zone.id,
+account=self.account.name,
+domainid=self.account.domainid,
+diskofferingid=self.disk_offering.id
 )
-self.assertNotEqual(
-template_from_snapshot,
-None,
-"Check if template gets created"
+Iso.create(
+self.userapiclient,
+self.testdata["iso2"],
+zoneid=self.zone.id,
+account=self.account.name,
+domainid=self.account.domainid,
+)
+
+# Step 3
+# Deletion of zone should fail if vm,volume is present on the zone
+with self.assertRaises(Exception):
+self.zone.delete(self.apiclient)
+
+return
+
+
+class TestDisableEnablePod(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+testClient = super(TestDisableEnablePod, 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.pod = get_pod(
+cls.apiclient,
+zone_id=cls.zone.id)
+
+cls.template = get_template(
+cls.apiclient,
+cls.zone.id,
+cls.testdata["ostype"])
+
+cls._cleanup = []
+
+try:
+cls.service_offering = ServiceOffering.create(
+cls.apiclient,
+cls.testdata["service_offering"],
+)
+cls._cleanup.append(cls.service_offering)
+
+cls.disk_offering = DiskOffering.create(
+cls.apiclient,
+cls.testdata["disk_offering"],
+)
+cls._cleanup.append(cls.disk_offering)
+
+# Create an account
+cls.account = Account.create(
+cls.apiclient,
+cls.testdata["account"],
+domainid=cls.domain.id
+)
+cls._cleanup.append(cls.account)
+
+# Create user api client of the account
+cls.userapiclient = testClient.getUserApiClient(
+UserName=cls.account.name,
+DomainName=cls.account.domain
+)
+
+except Exception as e:
+cls.tearDownClass()
+raise e
+return
+
+@classmethod
+def tearDownClass(cls):
+try:
+podList = Pod.list(cls.apiclient, id=cls.pod.id)
+if podList[0].allocationstate == DISABLED:
+cmd = updatePod.updatePodCmd()
+cmd.id = podList[0].id
+cmd.allocationstate = ENABLED
+cls.apiclient.updatePod(cmd)
+
+cleanup_resources(cls.apiclient, cls._cleanup)
+except Exception as e:
+raise Exception("Warning: Exception during cleanup : %s" % e)
+
+def setUp(self):
+self.apicli