Re: Review Request 16385: Fix for CloudStack JIRA 4406

[Mandar Barve]

> On Dec. 23, 2013, 5:58 p.m., Nitin Mehta wrote:
> > api/src/org/apache/cloudstack/api/BaseCmd.java, line 415
> > 
> >
> > Can you please create names which are more intuitive such as 
> > cmdRequestContainsSensitiveInfo and also better names for getters and 
> > setters ?

Nitin,
 I wanted to keep names short at the same time convey adequate meaning 
hence I chose those names. But I see your point, I could create following 
names. Here the thought is to have intuitive names plus try to follow 
getter/setter existing naming convention. 

Let me know if you have concerns.

Member variables can be named as:
responseHasSensitiveInfo
requestHasSensitiveInfo

The getter/setters can be named as:
getRequestHasSensitiveInfo
setRequestHasSensitiveInfo
getResponseHasSensitiveInfo
setResponseHasSensitiveInfo

Thanks,
Mandar


> On Dec. 23, 2013, 5:58 p.m., Nitin Mehta wrote:
> > api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsCmd.java, 
> > line 53
> > 
> >
> > You shouldn't have to override for every cmd. By default its false and 
> > the cmds having sensitive information can have methods returning true. Also 
> > they do not need to be set in execute. This is static information, doesn't 
> > change per command so why this needs to be set ?

Nitin,
You are right. This was discussed in the earlier discussion thread. You 
should really have to modify only commands that carry sensitive information. 
The problem with that approach as stated earlier is API developer can forget to 
declare command/response sensitivity by implementing a method that sets the 
flags, returns true etc. The wrapper abstract method was introduced essentially 
to ensure new APIs as they get introduced will give compiler error if this 
wrapper is not implemented enforcing the developer to declare such sensitivity 
upfront.
Hope that addresses your concern.

Thanks,
Mandar


- Mandar


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16385/#review30828
---


On Dec. 23, 2013, 6:13 p.m., Mandar Barve wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16385/
> ---
> 
> (Updated Dec. 23, 2013, 6:13 p.m.)
> 
> 
> Review request for cloudstack and daan Hoogland.
> 
> 
> Bugs: CLOUDSTACK-4406
> https://issues.apache.org/jira/browse/CLOUDSTACK-4406
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> JIRA 4406 expects removal of cleanString() call for performance 
> improvements. This is called when building audit trail for command responses 
> and used for removing sensitive data (passwords, secret keys) from the log 
> buffer. All the API responses do not carry such sensitive information so 
> pattern matching done by cleanString against all API response strings can be 
> costly. 
> 
> I propose following for a solution:
> 
> * Modify BaseCmd class to add flags that will store cmd/response sensitivity
> * At init these flags will be set to false indicating no cmd req/resp carries 
> sensitive data
> * any child api cmd class that will carry sensitive data in the req/resp 
> should set the respective flags
> * before calling any logging function the flag should be checked and 
> cleanString should be called only for cmds with flags set
> 
> Pro: This approach will scale well as new cmds get added and no additional 
> changes should be required.
> Con: Big change upfront as it will touch all API cmd classes that carry 
> sensitive information along with BaseCmd class. 
> 
> NOTE: changes should be simple and straightforward though spread across 
> multiple classes.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/api/commands/ListRecurringSnapshotScheduleCmd.java 
> d34c09c 
>   api/src/org/apache/cloudstack/api/BaseCmd.java 0cfb950 
>   api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsCmd.java 
> 48c1e02 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java 
> c5a2d1a 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/DeleteAccountCmd.java 
> 7c1b206 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/DisableAccountCmd.java
>  6fdbefe 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/EnableAccountCmd.java 
> 59d6acd 
>   api/src/org/apache/cloudstack/api/command/admin/account/LockAccountCmd.java 
> 93ec1be 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/UpdateAccountCmd.java 
> a8cf63f 
>   api/src/org/apache/cloudstack/api/command/admin/alert/GenerateAlertCmd.java 
> 620c5ed 
>   
> api/src/org/apache/cloudstack/api/command/adm

Re: Create VM - find out the NIC on KVM host connected to a Network switch

[Pradeep Cloudstack]

I have the NetworkGuru plugin(for orchestarting Juniper Switches) in the 
Management Server.
(1)Create and Add first VM to Network. The Network is assigned a VLAN ID.
(2)The implement() method of NetworkGuru plugin is invoked
Here, I need to figure out the the vNIC to physical NIC mapping for this VM on 
the KVM host. By getting
the physical NIC information, I can figure out the switch-port it is connected 
to using LLDP information on the switch

-Pradeep





On Tuesday, December 24, 2013 4:26 AM, Chiradeep Vittal 
 wrote:
 
Why do you need this information on the MS? Can you detail the steps of the 
algorithm you are trying to design?
E.g., 
AddVMtoNetwork:
Step 1:
Step 2:
Step 3: Aha. Here's where I need this info


From: Pradeep Cloudstack 
Reply-To: Pradeep Cloudstack 
Date: Sunday, December 22, 2013 10:43 PM
To: Chiradeep Vittal , "dev@cloudstack.apache.org" 

Subject: Re: Create VM - find out the NIC on KVM host connected to a Network 
switch


That is fine. But how do we convey this information to the Mgmt Server ?
Without making any enhancements to MgmtSvr/Agent , is it possible to achieve 
this?

-Pradeep





On Saturday, December 21, 2013 4:19 AM, Chiradeep Vittal 
 wrote:

On the KVM host you could parse the output of 'brctl show', but that is
awkward to parse.
Or you might be able to iterate through /sys/devices/virtual/net/* and
work backwards from that.


On 12/19/13 10:16 PM, "Pradeep Cloudstack" 
wrote:

>Hi Chiradeep,
>the LLDP output on the switch looks something like
>
>*
>Local Interface    Parent Interface    Chassis Id          Port info
>    System Name
>ge-0/0/21.0        -                  00:30:48:c9:54:26  eth1
>    bng-p3-vmm-cloudstack.englab.juniper.net
>ge-0/0/20.0        -                  00:30:48:fd:e4:fc  eth1
>    bng-p3-vmm-vde02-dcbg.englab.juniper.net
>me0.0              -                  78:fe:3d:d7:f4:80  ge-0/0/2.0
>    x2-sw39
>*
>
>
>Here  bng-p3-vmm-cloudstack.englab.juniper.net  and
>bng-p3-vmm-vde02-dcbg.englab.juniper.net  are the KVM hosts connected to
>the switch
>
>
>-Pradeep
>
>
>
>
>On Friday, December 20, 2013 5:54 AM, Chiradeep Vittal
> wrote:
> 
>What does the LLDP output look like?
>
>
>On 12/18/13 11:03 PM, "Pradeep Cloudstack" 
>wrote:
>
>>Hi ,
>>on a KVM host, I have a bridge interface - cloudbr1 to which eth1 has
>>been added.
>>This is for guest Network.
>>
>>
>>When we create a VM on the KVM host, the NetworkGuru plugin gets to know
>>about cloudbr1
>>(via the KVM traffic label). But is there any means to figure out the
>>ports (like eth1) that have been
>>attached to the bridge interface(in this case cloudbr1) on the KVM?
>>
>>The reason I want to know this is that the lldp output on the switch
>>gives information about eth1 (and not the bridge interfaces).
>>
>>
>>-Pradeep

Re: [VOTE] 3rd round of voting for ASF 4.2.1 RC

[Abhinandan Prateek]

Thanks Chip, I was not aware of this requirement.

On 23/12/13 7:40 pm, "Chip Childers"  wrote:

>Unfortunately, no...  this vote has not passed yet.  We need 1 more
>PMC vote.  Wei is a committer, but we have to have 3 PMC +1 votes for
>legal reasons.
>
>PMC members, please vote!
>
>On Mon, Dec 23, 2013 at 12:42 AM, Abhinandan Prateek
> wrote:
>> It gives me immense pleasure to inform that the vote to label this ASF
>> 4.2.1 RC as the GA release has been passed with following stats:
>>
>> +1   : 6 votes includes 3 bindings from Daan, Wei and Chip.
>> +/-0 : from Tomasz.
>>
>> Some issues have been pointed out by Tomasz (5422,5332 & 3806) and
>>Andrei
>> (issue with KVM:S3). These will be addresses in the next release (4.3).
>>
>> I would also like to thank team members who persistently tried respins
>>and
>> helped point and fix issues. Also, members who made substantial effort
>>to
>> fix docs, which was the cause of the first respin.
>>
>> Needless to say, that there were many who tirelessly worked behind the
>> scenes to fix bugs, test, manage resources etc in order to make this a
>> quality release.
>>
>> Next steps:
>>
>> 1. Tag the git commit with 4.2.1_GA
>> 2. Building and publishing packages (DEB and RPM)
>> 3. Publishing the docs here cloudstack.apache.org/docs
>> 4. Put the artefacts for download
>> 5. Finalise the release announcement:
>> 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2.1+Release+Anno
>>un
>> cement
>> 6. Announce the release on the website
>>
>> I will take care of 1,5,6
>> In the past Wido took care of 2 (DEB packages) not sure who built the
>>RPMs.
>> Sebastien I am assuming that you will take care of 3.
>> Chip it seems you took care of 4 for 4.2.
>>
>> -abhi
>>
>>
>>
>> On 17/12/13 7:19 pm, "Abhinandan Prateek"
>>
>> wrote:
>>
>>>The 4.2.1 is re-spun mainly because the commit that was used to generate
>>>the previous RC did not get pushed to repo.
>>>
>>>Following are the particulars to vote for this time around:
>>>
>>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=re
>>>fs
>>>/heads/4.2
>>>commit: 1b2b58fe352a19aee1721bd79b9d023d36e80ec5
>>>
>>>List of changes are available in Release Notes, a summary can be
>>>accessed
>>>here:
>>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=
>>>CH
>>>ANGES;hb=4.2
>>>
>>>Source release revision 3911 (checksums and signatures are available at
>>>the same location):
>>>https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/
>>>
>>>PGP release keys (signed using RSA Key ID = 42443AA1):
>>>https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>>
>>>Vote will be open for 72 hours (until 20 Dec 2013 End of day PST).
>>>
>>>For sanity in tallying the vote, can PMC members please be sure to
>>>indicate "(binding)" with their vote?
>>>
>>>[ ] +1  approve
>>>[ ] +0  no opinion
>>>[ ] -1  disapprove (and reason why)
>>>
>>

RE: ssh to ssvm

[Sanjeev Neelarapu]

Hi Yichi,

Try connecting to ssvm using id_rsa instead of id_rsa.cloud

-Sanjeev

-Original Message-
From: Yichi Lu [mailto:yichi...@sungard.com] 
Sent: Tuesday, December 24, 2013 3:27 AM
To: cloudstack
Subject: ssh to ssvm

When I tried to ssh to ssvm, I was asked for passphrase:
[root@xenserver-fpxwzqdr ~]# ssh -i /root/.ssh/id_rsa.cloud -p 3922
root@169.254.2.57
Enter passphrase for key '/root/.ssh/id_rsa.cloud':

What did I do wrong? What is the passphrase? Any help is appreciated.

Yichi

How Getting states in StateMachine2 and StateMachine

[Yitao Jiang]

Hi, guys

Is there any references about StateMachine, since now i am working on
digging the mechanisms of event and alert. I found the code of
statemachine(utils\src\com\cloud\utils\fsm\StateMachine2.java) it's really
confused me.

Thanks,

Yitao

Re: TLSv1 vs TLS vs SSL use throughout CS

[Chiradeep Vittal]

Why not set it to the highest secure protocol level always?

On 12/20/13 12:56 PM, "Demetrius Tsitrelis"  wrote:

>
>
>I was looking at the SSL code in CloudStack
>and noticed that there are about a dozen calls to the
>SSLContext.getInstance() method.  Some of them
>use the  "SSL" protocol while
>others use "TLS" or "TLSv1".   So I'm wondering if it makes sense to
>expose a configuration setting which specifies an organization's minimum
>secure protocol level and then use that in all of CloudStack.  Is there a
>need to maintain distinct protocol configurations for each SSL/TLS
>connection? Here's the
>usage list today:
>
> 
>plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerCon
>nectionPool.java:90:javax.net.ssl.SSLContext sc =
>javax.net.ssl.SSLContext.getInstance("TLS");
>
>plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvp
>Api.java:555:SSLContext sc =
>SSLContext.getInstance("SSL");
>
>plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClientW
>rapper.java:42:SSLContext ctx =
>SSLContext.getInstance("TLS");
>
>plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datasto
>re/util/SolidFireUtil.java:703:SSLContext sslContext =
>SSLContext.getInstance("SSL");
>
> 
>services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxySecur
>eServerFactoryImpl.java:71:sslContext =
>SSLContext.getInstance("TLS");
>
>services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxySecur
>eServerFactoryImpl.java:94:sslContext =
>SSLContext.getInstance("TLS");
>
>services/console-proxy/server/src/com/cloud/consoleproxy/util/RawHTTP.java
>:236:sslContext =
>SSLContext.getInstance("SSL", "SunJSSE");
>
>services/console-proxy-rdp/rdpconsole/src/main/java/streamer/SocketWrapper
>.java:130:SSLContext sslContext =
>SSLContext.getInstance("TLSv1");
>
> utils/src/com/cloud/utils/nio/Link.java:430:sslContext =
>SSLContext.getInstance("TLS");
>
>utils/src/org/apache/commons/httpclient/contrib/ssl/EasySSLProtocolSocketF
>actory.java:114:SSLContext context =
>SSLContext.getInstance("SSL");
>
> vmware-base/src/com/cloud/hypervisor/vmware/util/VmwareClient.java:102:
>  javax.net.ssl.SSLContext sc =
>javax.net.ssl.SSLContext.getInstance("SSL");
>
>vmware-base/src/com/cloud/hypervisor/vmware/util/VmwareContext.java:80:
> javax.net.ssl.SSLContext sc =
>javax.net.ssl.SSLContext.getInstance("SSL");
>
> 

Re: [PROPOSAL] region level VPC and guest network spanning multiple zones

[Chiradeep Vittal]

Ah OK. Just want to make sure that traffic accounting for access to in-DC
services is separate even though it may go through the same interface as
the public traffic.

On 12/20/13 2:09 AM, "Murali Reddy"  wrote:

>On 20/12/13 5:50 AM, "Chiradeep Vittal" 
>wrote:
>
>>Is there any reason to restrict a subnet to a single zone? AFAIK, AWS VPC
>>lets you stretch a subnet across AZ.
>>This way you can replicate *within* the DB tier to another zone.
>
>As per [1] in AWS VPC, "Each subnet must reside entirely within one
>Availability Zone and cannot span zones". However for CS I don't think we
>should have restriction. In the model I am proposing, VPC VR is gateway
>for outbound north-south traffic, then subnet of each tier is stretched at
>least into the zone running VPC VR anyway. So there is no reason to have
>this restriction. I will add tier/subnet stretching multiple zones as
>explicit requirement.
>
>
>[1] 
>http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html#VPC
>S
>ubnet
>
>>
>>Also, once you introduce distributed routing, access to other datacenter
>>services (S3 for instance) from within the VM will still go through the
>>VR?
>
>I am proposing to enable distributed routing only for inter-tier traffic
>for 4.4. So VPC VR still continue to be the gateway. As a future
>enhancement distributed routing for outbound traffic can be done.
>
>>
>>On 12/19/13 4:24 AM, "Murali Reddy"  wrote:
>>
>>>I would like to propose two networking models enhancements for ACS 4.4
>>>release that will enable building highly available applications.
>>>Currently
>>>VPC in CloudStack is a zone level entity. So tiers with in the VPC are
>>>confined to the zone to which VPC belongs. For an application deployed
>>>in
>>>current model of VPC failure of the zone is a single point of failure.
>>>It
>>>is desirable to make VPC a region level entity, where tiers in the VPC
>>>can
>>>be created in different zones of the region. When tiers can be created
>>>in
>>>different zones, application hosted in VPC can be architected to be
>>>highly
>>>available masking zone failures by having redundant tiers in different
>>>zones. While it may be seen as natural extension, there are fundamental
>>>limitations with VLAN/traditional L2 based networking due to which
>>>realizing it would be non-trivial or require special solutions [1].
>>>Overlay networks [2] in the context of SDN & network virtualization
>>>provides a way to build networks that are abstracted from
>>>physical/underlay network. An overlay network is typically built with
>>>tunnels across edge(vSwitch's in hypervisor) and core is plain L3
>>>network.
>>>With requirement that L3 connectivity across zones and tunnels can be
>>>established across the zones, an overlay network that spans multiple
>>>zones
>>>is easily realized.
>>>
>>>Given the range of SDN controllers that are integrated with CS, goal of
>>>this proposal is to leverage advances in SDN & network virtualization
>>>introduce below generic notions into CS.
>>>
>>>- an advanced zone isolated network that can span multiple zones
>>>- a region level VPC where tiers belong to different zones.
>>>
>>>I have opened bugs [3],[4] to track these two enhancements. As part of
>>>the
>>>effort I would like to extend the current OVS plug-in (that builds
>>>overlay
>>>network with GRE tunnels) to realise these two use-cases. I have opened
>>>bug [5] to track this enhancement.
>>>
>>>As long as we establish tunnels across the zones, we can have overlay
>>>networks that are functional, but would be inefficient in handling
>>>east-west traffic [6] and BUM traffic. While the problems exist in the
>>>overlay networks that are confined to a zone as well, they are
>>>compounded
>>>when the network spans multiple zones resulting in high cross-zone
>>>east-west traffic. I would be sending out a complementary proposal to
>>>introduce distributed routing and ACL's for east-west traffic and ARP
>>>localisation that will allow only legitimate cross zone east-west
>>>traffic.
>>>
>>>I will send out a functional specification with detailed requirements,
>>>assumptions, limitation etc once I make progress with these
>>>enhancements.
>>>Please share any feedback and comments.
>>>
>>>[1] 
>>>http://www.networkworld.com/news/tech/2010/090310-layer2-data-center-int
>>>e
>>>r
>>>c
>>>onnect.html
>>>[2] 
>>>http://etherealmind.com/introduction-to-how-overlay-networking-and-tunne
>>>l
>>>-
>>>f
>>>abrics-work/
>>>[3] https://issues.apache.org/jira/browse/CLOUDSTACK-5567
>>>[4] https://issues.apache.org/jira/browse/CLOUDSTACK-5568
>>>[5] https://issues.apache.org/jira/browse/CLOUDSTACK-5569
>>>[6] 
>>>http://blog.ipspace.net/2011/02/traffic-trombone-what-it-is-and-how-you.
>>>h
>>>t
>>>m
>>>l
>>>
>>
>>
>
>

Re: Create VM - find out the NIC on KVM host connected to a Network switch

[Chiradeep Vittal]

Why do you need this information on the MS? Can you detail the steps of the 
algorithm you are trying to design?
E.g.,
AddVMtoNetwork:
Step 1:
Step 2:
Step 3: Aha. Here's where I need this info


From: Pradeep Cloudstack 
mailto:pradeepcloudst...@yahoo.com>>
Reply-To: Pradeep Cloudstack 
mailto:pradeepcloudst...@yahoo.com>>
Date: Sunday, December 22, 2013 10:43 PM
To: Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: Create VM - find out the NIC on KVM host connected to a Network 
switch

That is fine. But how do we convey this information to the Mgmt Server ?
Without making any enhancements to MgmtSvr/Agent , is it possible to achieve 
this?

-Pradeep



On Saturday, December 21, 2013 4:19 AM, Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>> wrote:
On the KVM host you could parse the output of 'brctl show', but that is
awkward to parse.
Or you might be able to iterate through /sys/devices/virtual/net/* and
work backwards from that.

On 12/19/13 10:16 PM, "Pradeep Cloudstack" 
mailto:pradeepcloudst...@yahoo.com>>
wrote:

>Hi Chiradeep,
>the LLDP output on the switch looks something like
>
>*
>Local InterfaceParent InterfaceChassis Id  Port info
>System Name
>ge-0/0/21.0-  00:30:48:c9:54:26  eth1
>bng-p3-vmm-cloudstack.englab.juniper.net
>ge-0/0/20.0-  00:30:48:fd:e4:fc  eth1
>bng-p3-vmm-vde02-dcbg.englab.juniper.net
>me0.0  -  78:fe:3d:d7:f4:80  ge-0/0/2.0
>x2-sw39
>*
>
>
>Here  bng-p3-vmm-cloudstack.englab.juniper.net  and
>bng-p3-vmm-vde02-dcbg.englab.juniper.net  are the KVM hosts connected to
>the switch
>
>
>-Pradeep
>
>
>
>
>On Friday, December 20, 2013 5:54 AM, Chiradeep Vittal
>mailto:chiradeep.vit...@citrix.com>> wrote:
>
>What does the LLDP output look like?
>
>
>On 12/18/13 11:03 PM, "Pradeep Cloudstack" 
>mailto:pradeepcloudst...@yahoo.com>>
>wrote:
>
>>Hi ,
>>on a KVM host, I have a bridge interface - cloudbr1 to which eth1 has
>>been added.
>>This is for guest Network.
>>
>>
>>When we create a VM on the KVM host, the NetworkGuru plugin gets to know
>>about cloudbr1
>>(via the KVM traffic label). But is there any means to figure out the
>>ports (like eth1) that have been
>>attached to the bridge interface(in this case cloudbr1) on the KVM?
>>
>>The reason I want to know this is that the lldp output on the switch
>>gives information about eth1 (and not the bridge interfaces).
>>
>>
>>-Pradeep

Re: ssh to ssvm

[Jeronimo Garcia]

if you are on 4.2 i think the password is somerthing like "password" or
"cloudstack" something easy.


On Mon, Dec 23, 2013 at 6:56 PM, Yichi Lu  wrote:

> When I tried to ssh to ssvm, I was asked for passphrase:
> [root@xenserver-fpxwzqdr ~]# ssh -i /root/.ssh/id_rsa.cloud -p 3922
> root@169.254.2.57
> Enter passphrase for key '/root/.ssh/id_rsa.cloud':
>
> What did I do wrong? What is the passphrase? Any help is appreciated.
>
> Yichi
>

ssh to ssvm

[Yichi Lu]

When I tried to ssh to ssvm, I was asked for passphrase:
[root@xenserver-fpxwzqdr ~]# ssh -i /root/.ssh/id_rsa.cloud -p 3922
root@169.254.2.57
Enter passphrase for key '/root/.ssh/id_rsa.cloud':

What did I do wrong? What is the passphrase? Any help is appreciated.

Yichi

RE: Best wishes this holiday season, and here's to a strong 2014 for CloudStack!

[Prachi Damle]

Wishing all happy holidays and a happy new year!!

Prachi

-Original Message-
From: Chip Childers [mailto:chipchild...@apache.org] 
Sent: Monday, December 23, 2013 6:30 AM
To: dev@cloudstack.apache.org
Subject: Best wishes this holiday season, and here's to a strong 2014 for 
CloudStack!

Hey everybody,

I'd like to wish you all a great holiday season, and a fantastic new year.  
We've been enormously successful as a community this year, and here's to an 
even better 2014 for CloudStack!

-chip

Re: Review Request 16385: Fix for CloudStack JIRA 4406

[Mandar Barve]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16385/
---

(Updated Dec. 23, 2013, 6:13 p.m.)


Review request for cloudstack and daan Hoogland.


Changes
---

Updated the patch with help string in comments.


Bugs: CLOUDSTACK-4406
https://issues.apache.org/jira/browse/CLOUDSTACK-4406


Repository: cloudstack-git


Description
---

JIRA 4406 expects removal of cleanString() call for performance 
improvements. This is called when building audit trail for command responses 
and used for removing sensitive data (passwords, secret keys) from the log 
buffer. All the API responses do not carry such sensitive information so 
pattern matching done by cleanString against all API response strings can be 
costly. 

I propose following for a solution:

* Modify BaseCmd class to add flags that will store cmd/response sensitivity
* At init these flags will be set to false indicating no cmd req/resp carries 
sensitive data
* any child api cmd class that will carry sensitive data in the req/resp should 
set the respective flags
* before calling any logging function the flag should be checked and 
cleanString should be called only for cmds with flags set

Pro: This approach will scale well as new cmds get added and no additional 
changes should be required.
Con: Big change upfront as it will touch all API cmd classes that carry 
sensitive information along with BaseCmd class. 

NOTE: changes should be simple and straightforward though spread across 
multiple classes.


Diffs
-

  api/src/com/cloud/api/commands/ListRecurringSnapshotScheduleCmd.java d34c09c 
  api/src/org/apache/cloudstack/api/BaseCmd.java 0cfb950 
  api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsCmd.java 
48c1e02 
  api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java 
c5a2d1a 
  api/src/org/apache/cloudstack/api/command/admin/account/DeleteAccountCmd.java 
7c1b206 
  
api/src/org/apache/cloudstack/api/command/admin/account/DisableAccountCmd.java 
6fdbefe 
  api/src/org/apache/cloudstack/api/command/admin/account/EnableAccountCmd.java 
59d6acd 
  api/src/org/apache/cloudstack/api/command/admin/account/LockAccountCmd.java 
93ec1be 
  api/src/org/apache/cloudstack/api/command/admin/account/UpdateAccountCmd.java 
a8cf63f 
  api/src/org/apache/cloudstack/api/command/admin/alert/GenerateAlertCmd.java 
620c5ed 
  
api/src/org/apache/cloudstack/api/command/admin/autoscale/CreateCounterCmd.java 
6c4b81b 
  
api/src/org/apache/cloudstack/api/command/admin/autoscale/DeleteCounterCmd.java 
50477f5 
  api/src/org/apache/cloudstack/api/command/admin/cluster/AddClusterCmd.java 
d0e7380 
  api/src/org/apache/cloudstack/api/command/admin/cluster/DeleteClusterCmd.java 
e1bc585 
  api/src/org/apache/cloudstack/api/command/admin/cluster/ListClustersCmd.java 
8640f37 
  api/src/org/apache/cloudstack/api/command/admin/cluster/UpdateClusterCmd.java 
b13f81a 
  api/src/org/apache/cloudstack/api/command/admin/config/ListCfgsByCmd.java 
517807d 
  
api/src/org/apache/cloudstack/api/command/admin/config/ListDeploymentPlannersCmd.java
 1d9d2d9 
  
api/src/org/apache/cloudstack/api/command/admin/config/ListHypervisorCapabilitiesCmd.java
 16adf66 
  api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java 
9bc9b3c 
  
api/src/org/apache/cloudstack/api/command/admin/config/UpdateHypervisorCapabilitiesCmd.java
 5cb5f9c 
  api/src/org/apache/cloudstack/api/command/admin/domain/CreateDomainCmd.java 
4737555 
  api/src/org/apache/cloudstack/api/command/admin/domain/DeleteDomainCmd.java 
b1075c1 
  
api/src/org/apache/cloudstack/api/command/admin/domain/ListDomainChildrenCmd.java
 e1ba178 
  api/src/org/apache/cloudstack/api/command/admin/domain/ListDomainsCmd.java 
5a3786c 
  api/src/org/apache/cloudstack/api/command/admin/domain/UpdateDomainCmd.java 
8acfcd5 
  api/src/org/apache/cloudstack/api/command/admin/host/AddHostCmd.java 363bcd6 
  
api/src/org/apache/cloudstack/api/command/admin/host/AddSecondaryStorageCmd.java
 61f6f49 
  
api/src/org/apache/cloudstack/api/command/admin/host/CancelMaintenanceCmd.java 
46289ee 
  api/src/org/apache/cloudstack/api/command/admin/host/DeleteHostCmd.java 
5a4478e 
  
api/src/org/apache/cloudstack/api/command/admin/host/FindHostsForMigrationCmd.java
 0faf72c 
  api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java 
eda821b 
  
api/src/org/apache/cloudstack/api/command/admin/host/PrepareForMaintenanceCmd.java
 23cfacf 
  api/src/org/apache/cloudstack/api/command/admin/host/ReconnectHostCmd.java 
1ce888b 
  
api/src/org/apache/cloudstack/api/command/admin/host/ReleaseHostReservationCmd.java
 b60feca 
  api/src/org/apache/cloudstack/api/command/admin/host/UpdateHostCmd.java 
d778b37 
  
api/src/org/apache/cloudstack/api/command/admin/host/UpdateHostPasswordCmd.java 
69480b1 
  
api/src/org/apache/clouds

Re: Review Request 16385: Fix for CloudStack JIRA 4406

[Mandar Barve]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16385/
---

(Updated Dec. 23, 2013, 6:11 p.m.)


Review request for cloudstack and daan Hoogland.


Changes
---

Updated the patch with help string in comments.


Bugs: CLOUDSTACK-4406
https://issues.apache.org/jira/browse/CLOUDSTACK-4406


Repository: cloudstack-git


Description
---

JIRA 4406 expects removal of cleanString() call for performance 
improvements. This is called when building audit trail for command responses 
and used for removing sensitive data (passwords, secret keys) from the log 
buffer. All the API responses do not carry such sensitive information so 
pattern matching done by cleanString against all API response strings can be 
costly. 

I propose following for a solution:

* Modify BaseCmd class to add flags that will store cmd/response sensitivity
* At init these flags will be set to false indicating no cmd req/resp carries 
sensitive data
* any child api cmd class that will carry sensitive data in the req/resp should 
set the respective flags
* before calling any logging function the flag should be checked and 
cleanString should be called only for cmds with flags set

Pro: This approach will scale well as new cmds get added and no additional 
changes should be required.
Con: Big change upfront as it will touch all API cmd classes that carry 
sensitive information along with BaseCmd class. 

NOTE: changes should be simple and straightforward though spread across 
multiple classes.


Diffs (updated)
-

  api/src/com/cloud/api/commands/ListRecurringSnapshotScheduleCmd.java d34c09c 
  api/src/org/apache/cloudstack/api/BaseCmd.java 0cfb950 
  api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsCmd.java 
48c1e02 
  api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java 
c5a2d1a 
  api/src/org/apache/cloudstack/api/command/admin/account/DeleteAccountCmd.java 
7c1b206 
  
api/src/org/apache/cloudstack/api/command/admin/account/DisableAccountCmd.java 
6fdbefe 
  api/src/org/apache/cloudstack/api/command/admin/account/EnableAccountCmd.java 
59d6acd 
  api/src/org/apache/cloudstack/api/command/admin/account/LockAccountCmd.java 
93ec1be 
  api/src/org/apache/cloudstack/api/command/admin/account/UpdateAccountCmd.java 
a8cf63f 
  api/src/org/apache/cloudstack/api/command/admin/alert/GenerateAlertCmd.java 
620c5ed 
  
api/src/org/apache/cloudstack/api/command/admin/autoscale/CreateCounterCmd.java 
6c4b81b 
  
api/src/org/apache/cloudstack/api/command/admin/autoscale/DeleteCounterCmd.java 
50477f5 
  api/src/org/apache/cloudstack/api/command/admin/cluster/AddClusterCmd.java 
d0e7380 
  api/src/org/apache/cloudstack/api/command/admin/cluster/DeleteClusterCmd.java 
e1bc585 
  api/src/org/apache/cloudstack/api/command/admin/cluster/ListClustersCmd.java 
8640f37 
  api/src/org/apache/cloudstack/api/command/admin/cluster/UpdateClusterCmd.java 
b13f81a 
  api/src/org/apache/cloudstack/api/command/admin/config/ListCfgsByCmd.java 
517807d 
  
api/src/org/apache/cloudstack/api/command/admin/config/ListDeploymentPlannersCmd.java
 1d9d2d9 
  
api/src/org/apache/cloudstack/api/command/admin/config/ListHypervisorCapabilitiesCmd.java
 16adf66 
  api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java 
9bc9b3c 
  
api/src/org/apache/cloudstack/api/command/admin/config/UpdateHypervisorCapabilitiesCmd.java
 5cb5f9c 
  api/src/org/apache/cloudstack/api/command/admin/domain/CreateDomainCmd.java 
4737555 
  api/src/org/apache/cloudstack/api/command/admin/domain/DeleteDomainCmd.java 
b1075c1 
  
api/src/org/apache/cloudstack/api/command/admin/domain/ListDomainChildrenCmd.java
 e1ba178 
  api/src/org/apache/cloudstack/api/command/admin/domain/ListDomainsCmd.java 
5a3786c 
  api/src/org/apache/cloudstack/api/command/admin/domain/UpdateDomainCmd.java 
8acfcd5 
  api/src/org/apache/cloudstack/api/command/admin/host/AddHostCmd.java 363bcd6 
  
api/src/org/apache/cloudstack/api/command/admin/host/AddSecondaryStorageCmd.java
 61f6f49 
  
api/src/org/apache/cloudstack/api/command/admin/host/CancelMaintenanceCmd.java 
46289ee 
  api/src/org/apache/cloudstack/api/command/admin/host/DeleteHostCmd.java 
5a4478e 
  
api/src/org/apache/cloudstack/api/command/admin/host/FindHostsForMigrationCmd.java
 0faf72c 
  api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java 
eda821b 
  
api/src/org/apache/cloudstack/api/command/admin/host/PrepareForMaintenanceCmd.java
 23cfacf 
  api/src/org/apache/cloudstack/api/command/admin/host/ReconnectHostCmd.java 
1ce888b 
  
api/src/org/apache/cloudstack/api/command/admin/host/ReleaseHostReservationCmd.java
 b60feca 
  api/src/org/apache/cloudstack/api/command/admin/host/UpdateHostCmd.java 
d778b37 
  
api/src/org/apache/cloudstack/api/command/admin/host/UpdateHostPasswordCmd.java 
69480b1 
  
api/src/org/apa

Re: Review Request 16385: Fix for CloudStack JIRA 4406

[Nitin Mehta]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16385/#review30828
---



api/src/org/apache/cloudstack/api/BaseCmd.java


Can you please create names which are more intuitive such as 
cmdRequestContainsSensitiveInfo and also better names for getters and setters ?



api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsCmd.java


You shouldn't have to override for every cmd. By default its false and the 
cmds having sensitive information can have methods returning true. Also they do 
not need to be set in execute. This is static information, doesn't change per 
command so why this needs to be set ?


- Nitin Mehta


On Dec. 19, 2013, 1:45 p.m., Mandar Barve wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16385/
> ---
> 
> (Updated Dec. 19, 2013, 1:45 p.m.)
> 
> 
> Review request for cloudstack and daan Hoogland.
> 
> 
> Bugs: CLOUDSTACK-4406
> https://issues.apache.org/jira/browse/CLOUDSTACK-4406
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> JIRA 4406 expects removal of cleanString() call for performance 
> improvements. This is called when building audit trail for command responses 
> and used for removing sensitive data (passwords, secret keys) from the log 
> buffer. All the API responses do not carry such sensitive information so 
> pattern matching done by cleanString against all API response strings can be 
> costly. 
> 
> I propose following for a solution:
> 
> * Modify BaseCmd class to add flags that will store cmd/response sensitivity
> * At init these flags will be set to false indicating no cmd req/resp carries 
> sensitive data
> * any child api cmd class that will carry sensitive data in the req/resp 
> should set the respective flags
> * before calling any logging function the flag should be checked and 
> cleanString should be called only for cmds with flags set
> 
> Pro: This approach will scale well as new cmds get added and no additional 
> changes should be required.
> Con: Big change upfront as it will touch all API cmd classes that carry 
> sensitive information along with BaseCmd class. 
> 
> NOTE: changes should be simple and straightforward though spread across 
> multiple classes.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/api/commands/ListRecurringSnapshotScheduleCmd.java 
> d34c09c 
>   api/src/org/apache/cloudstack/api/BaseCmd.java 0cfb950 
>   api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsCmd.java 
> 48c1e02 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java 
> c5a2d1a 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/DeleteAccountCmd.java 
> 7c1b206 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/DisableAccountCmd.java
>  6fdbefe 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/EnableAccountCmd.java 
> 59d6acd 
>   api/src/org/apache/cloudstack/api/command/admin/account/LockAccountCmd.java 
> 93ec1be 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/UpdateAccountCmd.java 
> a8cf63f 
>   api/src/org/apache/cloudstack/api/command/admin/alert/GenerateAlertCmd.java 
> 620c5ed 
>   
> api/src/org/apache/cloudstack/api/command/admin/autoscale/CreateCounterCmd.java
>  6c4b81b 
>   
> api/src/org/apache/cloudstack/api/command/admin/autoscale/DeleteCounterCmd.java
>  50477f5 
>   api/src/org/apache/cloudstack/api/command/admin/cluster/AddClusterCmd.java 
> d0e7380 
>   
> api/src/org/apache/cloudstack/api/command/admin/cluster/DeleteClusterCmd.java 
> e1bc585 
>   
> api/src/org/apache/cloudstack/api/command/admin/cluster/ListClustersCmd.java 
> 8640f37 
>   
> api/src/org/apache/cloudstack/api/command/admin/cluster/UpdateClusterCmd.java 
> b13f81a 
>   api/src/org/apache/cloudstack/api/command/admin/config/ListCfgsByCmd.java 
> 517807d 
>   
> api/src/org/apache/cloudstack/api/command/admin/config/ListDeploymentPlannersCmd.java
>  1d9d2d9 
>   
> api/src/org/apache/cloudstack/api/command/admin/config/ListHypervisorCapabilitiesCmd.java
>  16adf66 
>   api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java 
> 9bc9b3c 
>   
> api/src/org/apache/cloudstack/api/command/admin/config/UpdateHypervisorCapabilitiesCmd.java
>  5cb5f9c 
>   api/src/org/apache/cloudstack/api/command/admin/domain/CreateDomainCmd.java 
> 4737555 
>   api/src/org/apache/cloudstack/api/command/admin/domain/DeleteDomainCmd.java 
> b1075c1 
>   
> api/src/org/apache/cloudstack/api/command/admin/domain/ListDomainChildrenCmd.java
>  e1ba178 
>   api/src/org/apache/cloudstack/api/command/admin/domain/ListDomainsCm

Re: Review Request 16385: Fix for CloudStack JIRA 4406

[Mandar Barve]

Sounds good. I will post updated patch.

Thanks,
Mandar


On Mon, Dec 23, 2013 at 8:14 PM, Daan Hoogland wrote:

> H Mandar,
>
> why not just put
>
> /**
>  * cmdHandlesCriticalData method must be implemented for all APIs.
> This method declares if it handles requests and/or responses that carry
> sensitive data such as passwords, secret keys.
>  * Method implementation should call cmdReqIsCritical and/or
> cmdRespIsCritical based on if the API carries such sensitive information in
> its request and/or response. If command doesn't carry any sensitive
> information then this method's implementation can be empty and method need
> not be called.
>  * If API does handle sensitive data then this method should be called
> either from the API command constructor or before processing the command
> from the execute method
>  */
> abstract public void cmdHandlesCriticalData();
>
> in BaseCmd.java?
>
> regards,
> Daan
>
>
> On Mon, Dec 23, 2013 at 12:05 PM, Mandar Barve 
> wrote:
>
>>This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/16385/
>>
>> On December 19th, 2013, 3:58 p.m. UTC, *daan Hoogland* wrote:
>>
>>   
>> api/src/org/apache/cloudstack/api/BaseCmd.java
>>  (Diff
>> revision 1)
>>
>> 427
>>
>> abstract public void cmdHandlesCriticalData();
>>
>>   please make sure a clear and extensive javadoc is present on why and how 
>> this abstract method should be implemented by api devs.
>>
>>  Hi Daan,
>> I couldn't find a suitable predefined annotation that could be added for 
>> abstract methods or methods in general. I also didn't find any annotated 
>> methods as reference. Here is what I could do
>> 1. Add a new annotation type e.g. Implementation that has name, description, 
>> implementation, usage properties and won't be visible in API doc by default 
>> but will be available at RUNTIME
>> 2. I will apply this annotation to the new method as follow:
>> @Implementation(name="cmdHandlesCriticalData",
>> description="cmdHandlesCriticalData method must be 
>> implemented for all APIs. This method declares if i
>> t handles requests and/or responses that carry sensitive data such as 
>> passwords, secret keys.",
>> implementation= "Method implementation should call 
>> cmdReqIsCritical and/or cmdRespIsCritical based on
>> if the API carries such sensitive information in its request and/or 
>> response. If command doesn't carry any sensitive infor
>> mation then this method's implementation can be empty and method need not be 
>> called.",
>> usage="If API does handle sensitive data then this 
>> method should be called either from the API command
>>  constructor or before processing the command from the execute method")
>>
>> Please let me know what you think.
>>
>> Thanks,
>> Mandar
>>
>>
>> - Mandar
>>
>> On December 19th, 2013, 1:45 p.m. UTC, Mandar Barve wrote:
>>   Review request for cloudstack and daan Hoogland.
>> By Mandar Barve.
>>
>> *Updated Dec. 19, 2013, 1:45 p.m.*
>>  *Bugs: * 
>> CLOUDSTACK-4406
>>  *Repository: * cloudstack-git
>> Description
>>
>> JIRA 4406 expects removal of cleanString() call for performance 
>> improvements. This is called when building audit trail for command responses 
>> and used for removing sensitive data (passwords, secret keys) from the log 
>> buffer. All the API responses do not carry such sensitive information so 
>> pattern matching done by cleanString against all API response strings can be 
>> costly.
>>
>> I propose following for a solution:
>>
>> * Modify BaseCmd class to add flags that will store cmd/response sensitivity
>> * At init these flags will be set to false indicating no cmd req/resp 
>> carries sensitive data
>> * any child api cmd class that will carry sensitive data in the req/resp 
>> should set the respective flags
>> * before calling any logging function the flag should be checked and 
>> cleanString should be called only for cmds with flags set
>>
>> Pro: This approach will scale well as new cmds get added and no additional 
>> changes should be required.
>> Con: Big change upfront as it will touch all API cmd classes that carry 
>> sensitive information along with BaseCmd class.
>>
>> NOTE: changes should be simple and straightforward though spread across 
>> multiple classes.
>>
>>
>>   Testing
>>
>> Using CloudMonkey following commands have been tested to make sure secret 
>> key/password is stripped from the response
>> list users
>> list accounts
>> list virtualmachines
>> create user
>> update user
>> create sshkeypair
>>
>>   Diffs
>>
>>- api/src/com/cloud/api/commands/ListRecurringSnapshotScheduleCmd.java
>>(d34c09c)
>>- api/src/org/apache/cloudstack/api/BaseCmd.java (0cfb950)
>>- 
>> api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsC

Regarding contribution to CloudStack project

[Abhinav Koppula]

Hi all,

I am Abhinav Koppula, a senior undergraduate student pursuing my Bachelors
in India. I am interested in contributing towards the Apache CloudStack
project. I would be really glad if anyone could guide me on how I can get
started.
Also, I wanted to know if there are any pre-requisites(in terms of computer
science concepts) which I need to cover before starting off.

I am skilled in Java but however I do not have prior experience of working
on cloud computing platforms. What books/resources should I refer which
would help me in understanding the code-base easily?

Thanks,
Abhinav Koppula

Re: Darwin Development

[Daan Hoogland]

guess that's a 'no' Alex,

On Wed, Dec 11, 2013 at 11:42 PM, Alex Hitchins
 wrote:
> Has anyone successfully built a development environment with Darwin, the
> Open Source OS X version?
>
>
>
>
>
>
>
> Alexander Hitchins
>
> 
>
> Personal Email :   a...@alexhitchins.com
>
> Apache Email   :   a...@alexhitchins.com
>
> Website:   http://alexhitchins.com
>
> Mobile : 07788 423 969
>
>
>

Re: [VOTE] 3rd round of voting for ASF 4.2.1 RC

[Andrei Mikhailovsky]

Right, done some more testing and indeed, the vms created from templates that 
were created from snapshots are not working. I get the following error in the 
management server logs: 


2013-12-23 15:54:11,088 DEBUG [agent.transport.Request] 
(AgentManager-Handler-11:null) Seq 1-2082880489: Processing: { Ans: , MgmtId: 
238402986947284, via: 1, Ver: v1, Flags: 110, 
[{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
 Failed to copy 
/mnt/08452456-d626-307b-9cbe-c028ae633435/59dfab5d-832e-4160-8f8e-47efb2d23d3e.raw
 to 0756278c-5abc-4e6c-b9ae-37033194d31a","wait":0}}] } 
2013-12-23 15:54:11,088 DEBUG [agent.manager.AgentAttache] 
(AgentManager-Handler-11:null) Seq 1-2082880489: No more commands found 
2013-12-23 15:54:11,088 DEBUG [agent.transport.Request] 
(Job-Executor-113:job-548 = [ dc47c0ce-eb8b-4230-b58a-047ab55950fb ]) Seq 
1-2082880489: Received: { Ans: , MgmtId: 238402986947284, via: 1, Ver: v1, 
Flags: 110, { CopyCmdAnswer } } 
2013-12-23 15:54:11,093 INFO [storage.volume.VolumeServiceImpl] 
(Job-Executor-113:job-548 = [ dc47c0ce-eb8b-4230-b58a-047ab55950fb ]) releasing 
lock for VMTemplateStoragePool 12 
2013-12-23 15:54:11,093 WARN [utils.db.Merovingian2] (Job-Executor-113:job-548 
= [ dc47c0ce-eb8b-4230-b58a-047ab55950fb ]) Was unable to find lock for the key 
template_spool_ref12 and thread id 291724899 
2013-12-23 15:54:11,093 DEBUG [cloud.storage.VolumeManagerImpl] 
(Job-Executor-113:job-548 = [ dc47c0ce-eb8b-4230-b58a-047ab55950fb ]) Unable to 
create Vol[504|vm=508|ROOT]:com.cloud.utils.exception.CloudRuntimeException: 
Failed to copy 
/mnt/08452456-d626-307b-9cbe-c028ae633435/59dfab5d-832e-4160-8f8e-47efb2d23d3e.raw
 to 0756278c-5abc-4e6c-b9ae-37033194d31a 
2013-12-23 15:54:11,093 INFO [cloud.vm.VirtualMachineManagerImpl] 
(Job-Executor-113:job-548 = [ dc47c0ce-eb8b-4230-b58a-047ab55950fb ]) Unable to 
contact resource. 
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:2] is 
unreachable: Unable to create 
Vol[504|vm=508|ROOT]:com.cloud.utils.exception.CloudRuntimeException: Failed to 
copy 
/mnt/08452456-d626-307b-9cbe-c028ae633435/59dfab5d-832e-4160-8f8e-47efb2d23d3e.raw
 to 0756278c-5abc-4e6c-b9ae-37033194d31a 
at 
com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2544) 
at com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592) 
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:889)
 
at 
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578)
 
at 
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
 
at 
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
 
at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406) 
at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966) 
at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952) 
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 
at 
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
 
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) 
at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) 
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) 
at java.util.concurrent.FutureTask.run(FutureTask.java:166) 
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:701) 


The template file is there: 

# find ./ |grep 59dfab5d-832e-4160-8f8e-47efb2d23d3e.raw 
./template/tmpl/5/217/59dfab5d-832e-4160-8f8e-47efb2d23d3e.raw 


As i've mentioned earlier, there is no problem when doing: root_disk > template 
> vm. The problem seems to be when I perform: root_disk > snapshot > template > 
vm. 

There seems to be a difference in the saved format types. A template created 
directly from a root volume is saved as QCOW2 whereas a template created from a 
snapshot is created as RAW according to the database: 


mysql> select * from vm_template where id=216 or id=217; 
+-+---+---+--++--+--+-+--+--++-+-++--+---+-+---+-+--+-+-+-+-++--+--+-+---+--+-+-

Re: Question about XenServer Snapshots

[Mike Tutkowski]

Hey Donal,

OK, I left the JIRA ticket for CloudStack:

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

Thanks!


On Mon, Dec 23, 2013 at 3:01 AM, Donal Lafferty
wrote:

> That might have been a misunderstanding.
>
> I was referring to a group of contributors who happened to work for Citrix.
>
> Since there they were clearing JIRA tickets, I thought it a good idea to
> create one for the issue.
>
> DL
>
>
> > -Original Message-
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: 20 December 2013 16:05
> > To: dev@cloudstack.apache.org
> > Subject: Re: Question about XenServer Snapshots
> >
> > Donal mentioned that this is actually code written by the XenServer
> group, so
> > I will need to remove the CloudStack ticket I opened and open one for the
> > XenServer group.
> >
> >
> > On Thu, Dec 19, 2013 at 10:11 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > > It looks like I found the issue: Insufficient space in the storage
> > > repository.
> > >
> > > From the XenServer vmopsSnapshot plug-in's revert_memory_snapshot
> > > method (which is invoked by the XenServer server resource):
> > >
> > > [root@XenServer-6 ~]# xe snapshot-revert
> > > snapshot-uuid=82e33f6d-59f3-a26d-4171-d51cd58716d8
> > > Error code: SR_BACKEND_FAILURE_44
> > > Error parameters: , There is insufficient space,
> > >
> > > I'm thinking an error should be returned from the plug-in instead of
> "0".
> > >
> > > I can log a JIRA ticket.
> > >
> > >
> > > On Thu, Dec 19, 2013 at 3:10 PM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com> wrote:
> > >
> > >> Hi,
> > >>
> > >> I have been experimenting with VM snapshots on XenServer and have
> > >> noticed a problem that I hope someone might be able to shed some light
> > on.
> > >>
> > >> In a normal flow of taking a VM snapshot, reverting to it, then
> > >> deleting the VM snapshot, I have observed the following (which looks
> just
> > fine):
> > >>
> > >> *SR:*
> > >>
> > >> uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> > >>   name-label ( RW): Test
> > >> name-description ( RW): iSCSI SR [10.10.8.108
> > >> (iqn.2010-01.com.solidfire:3y8w.test.15; LUN 0:
> > >> 33793877000ff47acc01: 93.1 GB (SolidFir))]
> > >> host ( RO): XenServer-6.1-Tut-2
> > >> type ( RO): lvmoiscsi
> > >> content-type ( RO):
> > >>
> > >>
> > >>- *Before VM snap:*
> > >>
> > >>
> > >>  *Active:*
> > >>
> > >> uuid ( RO): b4587018-9679-4fe7-ba72-5523cb988cec
> > >>   name-label ( RW): i-2-21-VM-DATA
> > >> name-description ( RW):
> > >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> > >> virtual-size ( RO): 16106127360
> > >> sharable ( RO): false
> > >>read-only ( RO): false
> > >>
> > >>
> > >>- *After VM snap:*
> > >>
> > >>
> > >>  *Base copy (contains the data of the previously active VDI):*
> > >>
> > >> uuid ( RO): d167952d-deb4-4942-9ea8-c8b3777d885e
> > >>   name-label ( RW): base copy
> > >> name-description ( RW):
> > >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> > >> virtual-size ( RO): 16106127360
> > >> sharable ( RO): false
> > >>read-only ( RO): true
> > >>
> > >> *Snapshot:*
> > >>
> > >> uuid ( RO): 613dc799-cf69-445a-a2fe-611653e0b0c9
> > >>   name-label ( RW): i-2-21-VM-DATA
> > >> name-description ( RW):
> > >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> > >> virtual-size ( RO): 16106127360
> > >> sharable ( RO): false
> > >>read-only ( RO): false
> > >>
> > >> *Active (has the same UUID as the previously active VDI):*
> > >>
> > >>  uuid ( RO): b4587018-9679-4fe7-ba72-5523cb988cec
> > >>   name-label ( RW): i-2-21-VM-DATA
> > >> name-description ( RW):
> > >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> > >> virtual-size ( RO): 16106127360
> > >> sharable ( RO): false
> > >>read-only ( RO): false
> > >>
> > >>
> > >>- *After revert to VM snap:*
> > >>
> > >>
> > >> *Base copy:*
> > >>
> > >> uuid ( RO): d167952d-deb4-4942-9ea8-c8b3777d885e
> > >>   name-label ( RW): base copy
> > >> name-description ( RW):
> > >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> > >> virtual-size ( RO): 16106127360
> > >> sharable ( RO): false
> > >>read-only ( RO): true
> > >>
> > >> *Snapshot (this VDI is un-touched):*
> > >>
> > >> uuid ( RO): 613dc799-cf69-445a-a2fe-611653e0b0c9
> > >>   name-label ( RW): i-2-21-VM-DATA
> > >> name-description ( RW):
> > >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> > >> virtual-size ( RO): 16106127360
> > >> sharable ( RO): false
> > >>

[Responsiveness report] users 2013w51

[Daan Hoogland]

http://markmail.org/message/tps6kxpleom76oi5 CloudStack 4.2 Advance
zone - KVM hypervisor by motty cruz

for an explanation of this report see
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Responsiveness+report

Re: Issue in accessing Windows and Linux VM

[Daan Hoogland]

Jitendra,

I am not sure what you expect as an answer but it seems to me you want
to configure those machines in the console and then create shapshots
and then new templates from those. Correct?

Otherwise I don't see how these are cloudstack questions,
regards

On Mon, Dec 9, 2013 at 8:48 PM, jitendra shelar
 wrote:
> Hi All,
>
> Can someone please tell me how to add drivers to the windows VM created
> from windows ISO?
>
> Also please tell me how to configure this windows VM to make it accessible
> via RDP.
>
> And what all changes I need to make on linux vm to make it accessible via
> putty?
>
> Thanks in advance.
>
> Regards,
> Jitendra

Re: [VOTE] 3rd round of voting for ASF 4.2.1 RC

[Andrei Mikhailovsky]

There is definitely an issue with snapshotting for kvm. 


I've been done some tests, but not finished yet. What i've discovered is that 
if you take a snapshot of a live server, the snapshot creation works perfectly 
well for me. The snapshot is created and saved without an error. However, i've 
tried to convert the snapshot into a template and create a new vm using this 
template. The snapshot to template works fine. However, creating a vm from that 
template did not work. 


If I try to create a template from a stopped server directly without using the 
snapshot, the vm creation from the template works perfectly well. 


I've not done much investigation, however, i've noticed that when I am doing vm 
creation using snapshot and template process the database shows QCOW2 as the 
file format. Doing directly via the template is showing RAW file format. I will 
do some more testing to verify and post management server logs. 


Andrei 


- Original Message -

From: "Nux!"  
To: dev@cloudstack.apache.org 
Sent: Monday, 23 December, 2013 2:34:31 PM 
Subject: Re: [VOTE] 3rd round of voting for ASF 4.2.1 RC 

On 23.12.2013 05:42, Abhinandan Prateek wrote: 
> It gives me immense pleasure to inform that the vote to label this ASF 
> 4.2.1 RC as the GA release has been passed with following stats: 

Can someone check KVM volume snapshots before declaring this GA? It's 
been consistently broken for me in 4.2.1-SNAPSHOT with NFS as well as 
GlusterFS shared mount point. 
It was working in 4.2.0 afaicr. 

I've sent several emails about this as well as bothering people in 
CLOUDSTACK-5393. 
http://www.mail-archive.com/dev@cloudstack.apache.org/msg20123.html 

HTH 
Lucian 

-- 
Sent from the Delta quadrant using Borg technology! 

Nux! 
www.nux.ro 

Re: Review Request 16385: Fix for CloudStack JIRA 4406

[Daan Hoogland]

H Mandar,

why not just put

/**
 * cmdHandlesCriticalData method must be implemented for all APIs. This
method declares if it handles requests and/or responses that carry
sensitive data such as passwords, secret keys.
 * Method implementation should call cmdReqIsCritical and/or
cmdRespIsCritical based on if the API carries such sensitive information in
its request and/or response. If command doesn't carry any sensitive
information then this method's implementation can be empty and method need
not be called.
 * If API does handle sensitive data then this method should be called
either from the API command constructor or before processing the command
from the execute method
 */
abstract public void cmdHandlesCriticalData();

in BaseCmd.java?

regards,
Daan


On Mon, Dec 23, 2013 at 12:05 PM, Mandar Barve wrote:

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16385/
>
> On December 19th, 2013, 3:58 p.m. UTC, *daan Hoogland* wrote:
>
>   
> api/src/org/apache/cloudstack/api/BaseCmd.java
>  (Diff
> revision 1)
>
> 427
>
> abstract public void cmdHandlesCriticalData();
>
>   please make sure a clear and extensive javadoc is present on why and how 
> this abstract method should be implemented by api devs.
>
>  Hi Daan,
> I couldn't find a suitable predefined annotation that could be added for 
> abstract methods or methods in general. I also didn't find any annotated 
> methods as reference. Here is what I could do
> 1. Add a new annotation type e.g. Implementation that has name, description, 
> implementation, usage properties and won't be visible in API doc by default 
> but will be available at RUNTIME
> 2. I will apply this annotation to the new method as follow:
> @Implementation(name="cmdHandlesCriticalData",
> description="cmdHandlesCriticalData method must be 
> implemented for all APIs. This method declares if i
> t handles requests and/or responses that carry sensitive data such as 
> passwords, secret keys.",
> implementation= "Method implementation should call 
> cmdReqIsCritical and/or cmdRespIsCritical based on
> if the API carries such sensitive information in its request and/or response. 
> If command doesn't carry any sensitive infor
> mation then this method's implementation can be empty and method need not be 
> called.",
> usage="If API does handle sensitive data then this method 
> should be called either from the API command
>  constructor or before processing the command from the execute method")
>
> Please let me know what you think.
>
> Thanks,
> Mandar
>
>
> - Mandar
>
> On December 19th, 2013, 1:45 p.m. UTC, Mandar Barve wrote:
>   Review request for cloudstack and daan Hoogland.
> By Mandar Barve.
>
> *Updated Dec. 19, 2013, 1:45 p.m.*
>  *Bugs: * 
> CLOUDSTACK-4406
>  *Repository: * cloudstack-git
> Description
>
> JIRA 4406 expects removal of cleanString() call for performance 
> improvements. This is called when building audit trail for command responses 
> and used for removing sensitive data (passwords, secret keys) from the log 
> buffer. All the API responses do not carry such sensitive information so 
> pattern matching done by cleanString against all API response strings can be 
> costly.
>
> I propose following for a solution:
>
> * Modify BaseCmd class to add flags that will store cmd/response sensitivity
> * At init these flags will be set to false indicating no cmd req/resp carries 
> sensitive data
> * any child api cmd class that will carry sensitive data in the req/resp 
> should set the respective flags
> * before calling any logging function the flag should be checked and 
> cleanString should be called only for cmds with flags set
>
> Pro: This approach will scale well as new cmds get added and no additional 
> changes should be required.
> Con: Big change upfront as it will touch all API cmd classes that carry 
> sensitive information along with BaseCmd class.
>
> NOTE: changes should be simple and straightforward though spread across 
> multiple classes.
>
>
>   Testing
>
> Using CloudMonkey following commands have been tested to make sure secret 
> key/password is stripped from the response
> list users
> list accounts
> list virtualmachines
> create user
> update user
> create sshkeypair
>
>   Diffs
>
>- api/src/com/cloud/api/commands/ListRecurringSnapshotScheduleCmd.java
>(d34c09c)
>- api/src/org/apache/cloudstack/api/BaseCmd.java (0cfb950)
>- 
> api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsCmd.java
>(48c1e02)
>- 
> api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java
>(c5a2d1a)
>- 
> api/src/org/apache/cloudstack/api/command/admin/account/DeleteAccountCmd.java
>(7c1b206)
>- 
> api/src/org/apache/cloudst

Re: [VOTE] 3rd round of voting for ASF 4.2.1 RC

[Nux!]

On 23.12.2013 05:42, Abhinandan Prateek wrote:

It gives me immense pleasure to inform that the vote to label this ASF
4.2.1 RC as the GA release has been passed with following stats:


Can someone check KVM volume snapshots before declaring this GA? It's 
been consistently broken for me in 4.2.1-SNAPSHOT with NFS as well as 
GlusterFS shared mount point.

It was working in 4.2.0 afaicr.

I've sent several emails about this as well as bothering people in 
CLOUDSTACK-5393.

http://www.mail-archive.com/dev@cloudstack.apache.org/msg20123.html

HTH
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Best wishes this holiday season, and here's to a strong 2014 for CloudStack!

[Chip Childers]

Hey everybody,

I'd like to wish you all a great holiday season, and a fantastic new
year.  We've been enormously successful as a community this year, and
here's to an even better 2014 for CloudStack!

-chip

Re: Distributed locking mechanism?

[Chip Childers]

On Mon, Dec 23, 2013 at 1:44 AM, Mike Tutkowski
 wrote:
> Yeah, at first I was thinking both simultaneous calls would succeed and two
> accounts would be created (this is what happens when two volumes with the
> same name are created because the volume ID is what really matters).
>
> However, with accounts, the first will succeed and the others fail, which
> can be used to control the flow in this situation.

I'd be careful about assuming that won't change in the future, right?
Best to use the ACS locking mechanism than rely on something you can't
control in the remote device.

>
>
> On Sun, Dec 22, 2013 at 9:03 PM, Koushik Das  wrote:
>
>> What is the account creation logic on Solidfire SAN if you try to create
>> the same simultaneously? I am assuming there should be some unique
>> constraint like account name/id etc. Try to see if this can be utilised so
>> that one of the account creation call fails with appropriate
>> error/exception.
>>
>> -Koushik
>>
>> On 23-Dec-2013, at 1:55 AM, Mike Tutkowski 
>> wrote:
>>
>> > Hi,
>> >
>> > I was wondering how we control access to shared resources that are being
>> > utilized by different management servers at the same time.
>> >
>> > For example:
>> >
>> > When a user attaches a volume (that's based on the SolidFire plug-in) to
>> a
>> > VM, my plug-in looks at the CloudStack account that is requesting the
>> > operation. If this CloudStack account does not have a corresponding
>> account
>> > on the SolidFire SAN, I must create one (there is a 1:1 mapping between
>> > CloudStack and SolidFire accounts).
>> >
>> > How can I protect against a situation where my plug-in is running in
>> > multiple management servers and performing this kind of operation at the
>> > same time (in other words, I don't want both instances of the plug-in to
>> > see no SolidFire account and then they each end up creating one, which
>> > breaks the 1:1 mapping between a CloudStack account and a SolidFire
>> > account)?
>> >
>> > Thanks!
>> >
>> > --
>> > *Mike Tutkowski*
>> > *Senior CloudStack Developer, SolidFire Inc.*
>> > e: mike.tutkow...@solidfire.com
>> > o: 303.746.7302
>> > Advancing the way the world uses the
>> > cloud
>> > *™*
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*

Re: [VOTE] 3rd round of voting for ASF 4.2.1 RC

[Chip Childers]

Unfortunately, no...  this vote has not passed yet.  We need 1 more
PMC vote.  Wei is a committer, but we have to have 3 PMC +1 votes for
legal reasons.

PMC members, please vote!

On Mon, Dec 23, 2013 at 12:42 AM, Abhinandan Prateek
 wrote:
> It gives me immense pleasure to inform that the vote to label this ASF
> 4.2.1 RC as the GA release has been passed with following stats:
>
> +1   : 6 votes includes 3 bindings from Daan, Wei and Chip.
> +/-0 : from Tomasz.
>
> Some issues have been pointed out by Tomasz (5422,5332 & 3806) and Andrei
> (issue with KVM:S3). These will be addresses in the next release (4.3).
>
> I would also like to thank team members who persistently tried respins and
> helped point and fix issues. Also, members who made substantial effort to
> fix docs, which was the cause of the first respin.
>
> Needless to say, that there were many who tirelessly worked behind the
> scenes to fix bugs, test, manage resources etc in order to make this a
> quality release.
>
> Next steps:
>
> 1. Tag the git commit with 4.2.1_GA
> 2. Building and publishing packages (DEB and RPM)
> 3. Publishing the docs here cloudstack.apache.org/docs
> 4. Put the artefacts for download
> 5. Finalise the release announcement:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2.1+Release+Announ
> cement
> 6. Announce the release on the website
>
> I will take care of 1,5,6
> In the past Wido took care of 2 (DEB packages) not sure who built the RPMs.
> Sebastien I am assuming that you will take care of 3.
> Chip it seems you took care of 4 for 4.2.
>
> -abhi
>
>
>
> On 17/12/13 7:19 pm, "Abhinandan Prateek" 
> wrote:
>
>>The 4.2.1 is re-spun mainly because the commit that was used to generate
>>the previous RC did not get pushed to repo.
>>
>>Following are the particulars to vote for this time around:
>>
>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs
>>/heads/4.2
>>commit: 1b2b58fe352a19aee1721bd79b9d023d36e80ec5
>>
>>List of changes are available in Release Notes, a summary can be accessed
>>here:
>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CH
>>ANGES;hb=4.2
>>
>>Source release revision 3911 (checksums and signatures are available at
>>the same location):
>>https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/
>>
>>PGP release keys (signed using RSA Key ID = 42443AA1):
>>https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>
>>Vote will be open for 72 hours (until 20 Dec 2013 End of day PST).
>>
>>For sanity in tallying the vote, can PMC members please be sure to
>>indicate "(binding)" with their vote?
>>
>>[ ] +1  approve
>>[ ] +0  no opinion
>>[ ] -1  disapprove (and reason why)
>>
>

Re: Review Request 16373: SecurityProfile for NiciraNvpApi, including Unit and Integration tests

[daan Hoogland]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16373/#review30825
---

Ship it!


dad42494983bb2ada670d18cb25cdae4e3cec63b

- daan Hoogland


On Dec. 23, 2013, 12:10 p.m., Antonio Fornie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16373/
> ---
> 
> (Updated Dec. 23, 2013, 12:10 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> SecurityProfile for NiciraNvpApi, including Unit and
>  Integration tests
> 
> 
> Diffs
> -
> 
>   plugins/network-elements/nicira-nvp/pom.xml 3bc8d14 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AccessConfiguration.java
>  PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AccessRule.java
>  PRE-CREATION 
>   plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/Acl.java 
> PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AclRule.java 
> PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java
>  6f695ad 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/SecurityProfile.java
>  PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/SecurityRule.java
>  PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NiciraNvpApiIT.java
>  PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NiciraNvpApiTest.java
>  26517b5 
>   plugins/network-elements/nicira-nvp/test/resources/config.properties 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/16373/diff/
> 
> 
> Testing
> ---
> 
> Unit and Integration Tests, both builds for this single submodule and for the 
> whole stack with both default and integration profiles
> 
> 
> Thanks,
> 
> Antonio Fornie
> 
>

Re: Review Request 16346: release in a branch instead of a commit to revert

[daan Hoogland]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16346/#review30824
---

Ship it!


in master as 3da5de545e034aa5fea82c7bced68c5b4f06fe94 please cherry-pick as 
needed

- daan Hoogland


On Dec. 18, 2013, 8:59 a.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16346/
> ---
> 
> (Updated Dec. 18, 2013, 8:59 a.m.)
> 
> 
> Review request for cloudstack, Animesh Chaturvedi and Abhinandan Prateek.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> At the moment releases are created in a commit that sets the version to the 
> right string. This commit is then reverted to put back the snapshot version. 
> This can (and should) be done in a (release-)branch
> 
> 
> Diffs
> -
> 
>   tools/build/build_asf.sh 6170cd5 
> 
> Diff: https://reviews.apache.org/r/16346/diff/
> 
> 
> Testing
> ---
> 
> test release created locally (not pushed)
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: [Doc] [4.3] Pluggable VM Snapshot for Review

[SuichII, Christopher]

Hm. I may just be missing it, but I don’t see a section on implementing 
VMSnapshotStrategy…

-Chris
-- 
Chris Suich
chris.su...@netapp.com
NetApp Software Engineer
Data Center Platforms – Cloud Solutions
Citrix, Cisco & Red Hat

On Dec 22, 2013, at 5:33 AM, Radhika Puthiyetath 
 wrote:

> Hi,
> 
> 4.3 Documentation is getting ready to be reviewed. Please review sections 
> Working with Snapshots, Virtual Machine Snapshots, and Implementing 
> VMSnapshotStrategy.
> 
> The documentation is uploaded at 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4945.
> 
> Regards
> -Radhika

Re: Review Request 16424: some net util for dealing with isolation ids

[daan Hoogland]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16424/#review30821
---


added as 94abbb1367bc817bae98f369e78679f0ddb7727f to 4.3 (not in master yet)

- daan Hoogland


On Dec. 20, 2013, 4:41 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16424/
> ---
> 
> (Updated Dec. 20, 2013, 4:41 p.m.)
> 
> 
> Review request for cloudstack, bharat kumar, Chiradeep Vittal, and Sheng Yang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> dealing with identifying vlans and other isolation networks.
> vlan numbers now limited to 1-4094 according to spec (was 0-4096)
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/net/NetUtils.java f6f6285 
> 
> Diff: https://reviews.apache.org/r/16424/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request 16438: CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to update in 4.3 upgrade setup

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16438/#review30819
---


Commit 6897984970df1455fa1ee0490157758ccfb68cff in branch refs/heads/4.3 from 
Harikrishna Patnala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6897984 ]

CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to 
update in 4.3 upgrade setup


- ASF Subversion and Git Services


On Dec. 23, 2013, 11:05 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16438/
> ---
> 
> (Updated Dec. 23, 2013, 11:05 a.m.)
> 
> 
> Review request for cloudstack and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-5608
> https://issues.apache.org/jira/browse/CLOUDSTACK-5608
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need 
> to update in 4.3 upgrade setup
> 1) Hyperv default builtin template is missing
> 2) Hyperv System vm template entry is missing or having invalid URL.
> 
> 
> Diffs
> -
> 
>   setup/db/db/schema-421to430.sql 574f510 
>   setup/db/templates.sql 0f7958f 
> 
> Diff: https://reviews.apache.org/r/16438/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Faulty method isNetworkAWithinNetworkB ?

[Jayapal Reddy Uradi]

Hi Saksham,

Always the higher suffix cidr will be in lower suffix cidr.
10.1.1.0/24 will have 256 addresses and 10.1.1.0/25 will have 128 addresses[1].

/25 will be completely in /24 but not wise versa. 

The below are incorrect.
> isNetworkAWithinNetworkB("10.1.1.0/24", "10.1.1.0/25") returns true
> isNetworkAWithinNetworkB("10.1.1.0/22", "10.1.1.0/23") returns true

I think you can change isNetworkAWithinNetworkB method to compare respective ip 
ranges for cidrs.

What about changing method name isNetworkACompletelyWithinNetworkB() ?

[1]https://www.dan.me.uk/ipsubnets?ip=10.1.1.0


Thanks,
Jayapal

On 13-Dec-2013, at 4:49 PM, Saksham Srivastava  
wrote:

> Hi,
> 
> I encountered a method isNetworkAWithinNetworkB(cidrA, cidrB) in 
> NetUtils.java which should return true if cidrA is a subset of cidrB.
> The method returns flawed output in many scenarios. After unittesting it I 
> found :
> 
> isNetworkAWithinNetworkB("10.1.1.0/24", "10.1.1.0/25") returns true
> isNetworkAWithinNetworkB("10.1.1.0/25", "10.1.1.0/24") returns true
> isNetworkAWithinNetworkB("10.1.1.0/23", "10.1.1.0/22") returns true
> isNetworkAWithinNetworkB("10.1.1.0/22", "10.1.1.0/23") returns true
> 
> Due to this I am able to create VPC tiers with cidr 10.1.0.0/24 even when the 
> VPC super cidr has been defined as 10.1.1.0/25
> IMO the simpler/cleaner way to compare cidrs should be to compare the 
> respective IP ranges. I have an old patch [1] in RB which uses the IP ranges 
> to compare 2 cidrs.
> We could leverage that to replace isNetworkAWithinNetworkB() or in case of 
> any other suggestions please share.
> 
> Thanks,
> Saksham
> 
> [1] https://reviews.apache.org/r/14124/diff/#index_header
> 

Re: Review Request 16386: CLOUDSTACK-5518: Fixing non contiguous vlan test case

[Girish Shilamkar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16386/#review30818
---

Ship it!


Committed to 4.3 and master

- Girish Shilamkar


On Dec. 19, 2013, 3:34 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16386/
> ---
> 
> (Updated Dec. 19, 2013, 3:34 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5518
> https://issues.apache.org/jira/browse/CLOUDSTACK-5518
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The issue in 5518 is, if newly added vlan range is getting used by other test 
> cases, then that range will get considered as used and we are trying to 
> remove the unused range.
> The problem reported by Rayees is not the exact issue. I have updated the 
> comments in the bug accordingly.
> 
> I have changed the code in test case to minimize the time interval between 
> adding the new range and removing it so as to minimize the probability of it 
> getting used by other test cases dynamically.
> 
> Also cleaned up the imports and improved other test case.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_non_contiguous_vlan.py 5ef1ec7 
> 
> Diff: https://reviews.apache.org/r/16386/diff/
> 
> 
> Testing
> ---
> 
> Tested locally:
> 
> Log:
> test_01_add_non_contiguous_ranges 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_02_add_existing_vlan_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_03_extend_contiguous_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_04_remove_unused_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_05_remove_used_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> 
> --
> Ran 5 tests in 304.525s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 16324: CLOUDSTACK-4780: Changes related to checking snapshot on NFS server

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16324/#review30814
---


Commit 80ab47c86945f8949612cbea0e169c4ca9e096bb in branch refs/heads/4.3 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=80ab47c ]

CLOUDSTACK-4780: Changes related to checking snapshot path
 on NFS server, also made marvin import paths specific


- ASF Subversion and Git Services


On Dec. 23, 2013, 11:41 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16324/
> ---
> 
> (Updated Dec. 23, 2013, 11:41 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-4780
> https://issues.apache.org/jira/browse/CLOUDSTACK-4780
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes:
> 
> 1) Appended snapshot extension to the snapshot path coming from database. As 
> discussed with Harikrishna, Product bug (5135) is invalid, snapshot path in 
> database won't contain the extension of the snapshot. So changing the code so 
> as to append the extension based on hypervisor type.
> 
> 2) Code movement and cleanup - Moved function get_hypervisor_type from common 
> to utils to avoid cyclic dependency of libraries. Also, cleaned up the 
> imports.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_add_remove_network.py f1508e1 
>   test/integration/component/test_assign_vm.py cbdce73 
>   test/integration/component/test_cpu_domain_limits.py 4e8fc6d 
>   test/integration/component/test_cpu_limits.py d721a45 
>   test/integration/component/test_cpu_max_limits.py 9161cee 
>   test/integration/component/test_cpu_project_limits.py 63d1a98 
>   test/integration/component/test_egress_fw_rules.py 09e1dd6 
>   test/integration/component/test_haproxy.py c734012 
>   test/integration/component/test_mm_domain_limits.py c856087 
>   test/integration/component/test_mm_max_limits.py b1ebbb4 
>   test/integration/component/test_mm_project_limits.py ffeb20a 
>   test/integration/component/test_snapshots.py d3fac42 
>   test/integration/component/test_vpc_network_lbrules.py e7cb823 
>   test/integration/component/test_vpc_network_pfrules.py 0d8e2f1 
>   test/integration/component/test_vpc_network_staticnatrule.py dd3d249 
>   test/integration/component/test_vpn_users.py 9ee907b 
>   tools/marvin/marvin/integration/lib/common.py 096b073 
>   tools/marvin/marvin/integration/lib/utils.py d046235 
> 
> Diff: https://reviews.apache.org/r/16324/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on VMware. KVM should not have impact of this change as the 
> snapshot created on KVM was found not to have any extension.
> 
> Log:
> test_01_snapshot_root_disk (test_snapshots.TestSnapshotRootDisk)
> Test Snapshot Root Disk ... ok
> 
> --
> Ran 1 test in 513.783s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 16324: CLOUDSTACK-4780: Changes related to checking snapshot on NFS server

[Girish Shilamkar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16324/#review30816
---

Ship it!


Committed to 4.3 and master

- Girish Shilamkar


On Dec. 23, 2013, 11:41 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16324/
> ---
> 
> (Updated Dec. 23, 2013, 11:41 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-4780
> https://issues.apache.org/jira/browse/CLOUDSTACK-4780
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes:
> 
> 1) Appended snapshot extension to the snapshot path coming from database. As 
> discussed with Harikrishna, Product bug (5135) is invalid, snapshot path in 
> database won't contain the extension of the snapshot. So changing the code so 
> as to append the extension based on hypervisor type.
> 
> 2) Code movement and cleanup - Moved function get_hypervisor_type from common 
> to utils to avoid cyclic dependency of libraries. Also, cleaned up the 
> imports.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_add_remove_network.py f1508e1 
>   test/integration/component/test_assign_vm.py cbdce73 
>   test/integration/component/test_cpu_domain_limits.py 4e8fc6d 
>   test/integration/component/test_cpu_limits.py d721a45 
>   test/integration/component/test_cpu_max_limits.py 9161cee 
>   test/integration/component/test_cpu_project_limits.py 63d1a98 
>   test/integration/component/test_egress_fw_rules.py 09e1dd6 
>   test/integration/component/test_haproxy.py c734012 
>   test/integration/component/test_mm_domain_limits.py c856087 
>   test/integration/component/test_mm_max_limits.py b1ebbb4 
>   test/integration/component/test_mm_project_limits.py ffeb20a 
>   test/integration/component/test_snapshots.py d3fac42 
>   test/integration/component/test_vpc_network_lbrules.py e7cb823 
>   test/integration/component/test_vpc_network_pfrules.py 0d8e2f1 
>   test/integration/component/test_vpc_network_staticnatrule.py dd3d249 
>   test/integration/component/test_vpn_users.py 9ee907b 
>   tools/marvin/marvin/integration/lib/common.py 096b073 
>   tools/marvin/marvin/integration/lib/utils.py d046235 
> 
> Diff: https://reviews.apache.org/r/16324/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on VMware. KVM should not have impact of this change as the 
> snapshot created on KVM was found not to have any extension.
> 
> Log:
> test_01_snapshot_root_disk (test_snapshots.TestSnapshotRootDisk)
> Test Snapshot Root Disk ... ok
> 
> --
> Ran 1 test in 513.783s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 16386: CLOUDSTACK-5518: Fixing non contiguous vlan test case

[Girish Shilamkar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16386/#review30817
---

Ship it!


Ship It!

- Girish Shilamkar


On Dec. 19, 2013, 3:34 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16386/
> ---
> 
> (Updated Dec. 19, 2013, 3:34 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5518
> https://issues.apache.org/jira/browse/CLOUDSTACK-5518
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The issue in 5518 is, if newly added vlan range is getting used by other test 
> cases, then that range will get considered as used and we are trying to 
> remove the unused range.
> The problem reported by Rayees is not the exact issue. I have updated the 
> comments in the bug accordingly.
> 
> I have changed the code in test case to minimize the time interval between 
> adding the new range and removing it so as to minimize the probability of it 
> getting used by other test cases dynamically.
> 
> Also cleaned up the imports and improved other test case.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_non_contiguous_vlan.py 5ef1ec7 
> 
> Diff: https://reviews.apache.org/r/16386/diff/
> 
> 
> Testing
> ---
> 
> Tested locally:
> 
> Log:
> test_01_add_non_contiguous_ranges 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_02_add_existing_vlan_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_03_extend_contiguous_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_04_remove_unused_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_05_remove_used_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> 
> --
> Ran 5 tests in 304.525s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 16324: CLOUDSTACK-4780: Changes related to checking snapshot on NFS server

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16324/#review30815
---


Commit a160b46cd47a1fb19f19546bcaf8bd4701d447bc in branch refs/heads/master 
from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a160b46 ]

CLOUDSTACK-4780: Changes related to checking snapshot path
 on NFS server, also made marvin import paths specific


- ASF Subversion and Git Services


On Dec. 23, 2013, 11:41 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16324/
> ---
> 
> (Updated Dec. 23, 2013, 11:41 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-4780
> https://issues.apache.org/jira/browse/CLOUDSTACK-4780
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes:
> 
> 1) Appended snapshot extension to the snapshot path coming from database. As 
> discussed with Harikrishna, Product bug (5135) is invalid, snapshot path in 
> database won't contain the extension of the snapshot. So changing the code so 
> as to append the extension based on hypervisor type.
> 
> 2) Code movement and cleanup - Moved function get_hypervisor_type from common 
> to utils to avoid cyclic dependency of libraries. Also, cleaned up the 
> imports.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_add_remove_network.py f1508e1 
>   test/integration/component/test_assign_vm.py cbdce73 
>   test/integration/component/test_cpu_domain_limits.py 4e8fc6d 
>   test/integration/component/test_cpu_limits.py d721a45 
>   test/integration/component/test_cpu_max_limits.py 9161cee 
>   test/integration/component/test_cpu_project_limits.py 63d1a98 
>   test/integration/component/test_egress_fw_rules.py 09e1dd6 
>   test/integration/component/test_haproxy.py c734012 
>   test/integration/component/test_mm_domain_limits.py c856087 
>   test/integration/component/test_mm_max_limits.py b1ebbb4 
>   test/integration/component/test_mm_project_limits.py ffeb20a 
>   test/integration/component/test_snapshots.py d3fac42 
>   test/integration/component/test_vpc_network_lbrules.py e7cb823 
>   test/integration/component/test_vpc_network_pfrules.py 0d8e2f1 
>   test/integration/component/test_vpc_network_staticnatrule.py dd3d249 
>   test/integration/component/test_vpn_users.py 9ee907b 
>   tools/marvin/marvin/integration/lib/common.py 096b073 
>   tools/marvin/marvin/integration/lib/utils.py d046235 
> 
> Diff: https://reviews.apache.org/r/16324/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on VMware. KVM should not have impact of this change as the 
> snapshot created on KVM was found not to have any extension.
> 
> Log:
> test_01_snapshot_root_disk (test_snapshots.TestSnapshotRootDisk)
> Test Snapshot Root Disk ... ok
> 
> --
> Ran 1 test in 513.783s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 16386: CLOUDSTACK-5518: Fixing non contiguous vlan test case

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16386/#review30812
---


Commit 0faf772635cbc6ca26cdb52fbbe7d008db0e2277 in branch refs/heads/4.3 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0faf772 ]

CLOUDSTACK-5518: Fixing non contiguous vlan test case


- ASF Subversion and Git Services


On Dec. 19, 2013, 3:34 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16386/
> ---
> 
> (Updated Dec. 19, 2013, 3:34 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5518
> https://issues.apache.org/jira/browse/CLOUDSTACK-5518
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The issue in 5518 is, if newly added vlan range is getting used by other test 
> cases, then that range will get considered as used and we are trying to 
> remove the unused range.
> The problem reported by Rayees is not the exact issue. I have updated the 
> comments in the bug accordingly.
> 
> I have changed the code in test case to minimize the time interval between 
> adding the new range and removing it so as to minimize the probability of it 
> getting used by other test cases dynamically.
> 
> Also cleaned up the imports and improved other test case.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_non_contiguous_vlan.py 5ef1ec7 
> 
> Diff: https://reviews.apache.org/r/16386/diff/
> 
> 
> Testing
> ---
> 
> Tested locally:
> 
> Log:
> test_01_add_non_contiguous_ranges 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_02_add_existing_vlan_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_03_extend_contiguous_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_04_remove_unused_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_05_remove_used_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> 
> --
> Ran 5 tests in 304.525s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 16386: CLOUDSTACK-5518: Fixing non contiguous vlan test case

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16386/#review30813
---


Commit 5d03fa83a23fa79599401ebd289d0e09a1f66d28 in branch refs/heads/master 
from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5d03fa8 ]

CLOUDSTACK-5518: Fixing non contiguous vlan test case


- ASF Subversion and Git Services


On Dec. 19, 2013, 3:34 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16386/
> ---
> 
> (Updated Dec. 19, 2013, 3:34 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5518
> https://issues.apache.org/jira/browse/CLOUDSTACK-5518
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The issue in 5518 is, if newly added vlan range is getting used by other test 
> cases, then that range will get considered as used and we are trying to 
> remove the unused range.
> The problem reported by Rayees is not the exact issue. I have updated the 
> comments in the bug accordingly.
> 
> I have changed the code in test case to minimize the time interval between 
> adding the new range and removing it so as to minimize the probability of it 
> getting used by other test cases dynamically.
> 
> Also cleaned up the imports and improved other test case.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_non_contiguous_vlan.py 5ef1ec7 
> 
> Diff: https://reviews.apache.org/r/16386/diff/
> 
> 
> Testing
> ---
> 
> Tested locally:
> 
> Log:
> test_01_add_non_contiguous_ranges 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_02_add_existing_vlan_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_03_extend_contiguous_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_04_remove_unused_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> test_05_remove_used_range 
> (test_non_contiguous_vlan_fixed.TestNonContiguousVLANRanges) ... ok
> 
> --
> Ran 5 tests in 304.525s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 16373: SecurityProfile for NiciraNvpApi, including Unit and Integration tests

[Antonio Fornie]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16373/
---

(Updated Dec. 23, 2013, 12:10 p.m.)


Review request for cloudstack, daan Hoogland and Hugo Trippaers.


Changes
---

Just remove a comment line that is not really helping.


Repository: cloudstack-git


Description
---

SecurityProfile for NiciraNvpApi, including Unit and
 Integration tests


Diffs (updated)
-

  plugins/network-elements/nicira-nvp/pom.xml 3bc8d14 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AccessConfiguration.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AccessRule.java
 PRE-CREATION 
  plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/Acl.java 
PRE-CREATION 
  plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AclRule.java 
PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java
 6f695ad 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/SecurityProfile.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/SecurityRule.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NiciraNvpApiIT.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NiciraNvpApiTest.java
 26517b5 
  plugins/network-elements/nicira-nvp/test/resources/config.properties 
PRE-CREATION 

Diff: https://reviews.apache.org/r/16373/diff/


Testing
---

Unit and Integration Tests, both builds for this single submodule and for the 
whole stack with both default and integration profiles


Thanks,

Antonio Fornie

Re: Review Request 16324: CLOUDSTACK-4780: Changes related to checking snapshot on NFS server

[Gaurav Aradhye]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16324/
---

(Updated Dec. 23, 2013, 5:11 p.m.)


Review request for cloudstack and Girish Shilamkar.


Changes
---

Updated the patch by correcting the imports. In many files imports were not 
specified correctly, but they were working fine because the objects were 
somehow getting imported from chaining of imports (import *). When imports in 
the Marvin got corrected with previous patch, many suits failed in nose while 
picking up the tests due to this.

I have corrected the imports in all other files, specifically related to 
"cleanup_resources" function.


Bugs: CLOUDSTACK-4780
https://issues.apache.org/jira/browse/CLOUDSTACK-4780


Repository: cloudstack-git


Description
---

Changes:

1) Appended snapshot extension to the snapshot path coming from database. As 
discussed with Harikrishna, Product bug (5135) is invalid, snapshot path in 
database won't contain the extension of the snapshot. So changing the code so 
as to append the extension based on hypervisor type.

2) Code movement and cleanup - Moved function get_hypervisor_type from common 
to utils to avoid cyclic dependency of libraries. Also, cleaned up the imports.


Diffs (updated)
-

  test/integration/component/test_add_remove_network.py f1508e1 
  test/integration/component/test_assign_vm.py cbdce73 
  test/integration/component/test_cpu_domain_limits.py 4e8fc6d 
  test/integration/component/test_cpu_limits.py d721a45 
  test/integration/component/test_cpu_max_limits.py 9161cee 
  test/integration/component/test_cpu_project_limits.py 63d1a98 
  test/integration/component/test_egress_fw_rules.py 09e1dd6 
  test/integration/component/test_haproxy.py c734012 
  test/integration/component/test_mm_domain_limits.py c856087 
  test/integration/component/test_mm_max_limits.py b1ebbb4 
  test/integration/component/test_mm_project_limits.py ffeb20a 
  test/integration/component/test_snapshots.py d3fac42 
  test/integration/component/test_vpc_network_lbrules.py e7cb823 
  test/integration/component/test_vpc_network_pfrules.py 0d8e2f1 
  test/integration/component/test_vpc_network_staticnatrule.py dd3d249 
  test/integration/component/test_vpn_users.py 9ee907b 
  tools/marvin/marvin/integration/lib/common.py 096b073 
  tools/marvin/marvin/integration/lib/utils.py d046235 

Diff: https://reviews.apache.org/r/16324/diff/


Testing
---

Tested locally on VMware. KVM should not have impact of this change as the 
snapshot created on KVM was found not to have any extension.

Log:
test_01_snapshot_root_disk (test_snapshots.TestSnapshotRootDisk)
Test Snapshot Root Disk ... ok

--
Ran 1 test in 513.783s

OK


Thanks,

Gaurav Aradhye

Re: Review Request 16385: Fix for CloudStack JIRA 4406

[Mandar Barve]

> On Dec. 19, 2013, 3:58 p.m., daan Hoogland wrote:
> > api/src/org/apache/cloudstack/api/BaseCmd.java, line 427
> > 
> >
> > please make sure a clear and extensive javadoc is present on why and 
> > how this abstract method should be implemented by api devs.

Hi Daan,
I couldn't find a suitable predefined annotation that could be added for 
abstract methods or methods in general. I also didn't find any annotated 
methods as reference. Here is what I could do
1. Add a new annotation type e.g. Implementation that has name, description, 
implementation, usage properties and won't be visible in API doc by default but 
will be available at RUNTIME
2. I will apply this annotation to the new method as follow:
@Implementation(name="cmdHandlesCriticalData",
description="cmdHandlesCriticalData method must be 
implemented for all APIs. This method declares if i
t handles requests and/or responses that carry sensitive data such as 
passwords, secret keys.",
implementation= "Method implementation should call 
cmdReqIsCritical and/or cmdRespIsCritical based on
if the API carries such sensitive information in its request and/or response. 
If command doesn't carry any sensitive infor
mation then this method's implementation can be empty and method need not be 
called.",
usage="If API does handle sensitive data then this method 
should be called either from the API command
 constructor or before processing the command from the execute method")

Please let me know what you think.

Thanks,
Mandar


- Mandar


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16385/#review30699
---


On Dec. 19, 2013, 1:45 p.m., Mandar Barve wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16385/
> ---
> 
> (Updated Dec. 19, 2013, 1:45 p.m.)
> 
> 
> Review request for cloudstack and daan Hoogland.
> 
> 
> Bugs: CLOUDSTACK-4406
> https://issues.apache.org/jira/browse/CLOUDSTACK-4406
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> JIRA 4406 expects removal of cleanString() call for performance 
> improvements. This is called when building audit trail for command responses 
> and used for removing sensitive data (passwords, secret keys) from the log 
> buffer. All the API responses do not carry such sensitive information so 
> pattern matching done by cleanString against all API response strings can be 
> costly. 
> 
> I propose following for a solution:
> 
> * Modify BaseCmd class to add flags that will store cmd/response sensitivity
> * At init these flags will be set to false indicating no cmd req/resp carries 
> sensitive data
> * any child api cmd class that will carry sensitive data in the req/resp 
> should set the respective flags
> * before calling any logging function the flag should be checked and 
> cleanString should be called only for cmds with flags set
> 
> Pro: This approach will scale well as new cmds get added and no additional 
> changes should be required.
> Con: Big change upfront as it will touch all API cmd classes that carry 
> sensitive information along with BaseCmd class. 
> 
> NOTE: changes should be simple and straightforward though spread across 
> multiple classes.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/api/commands/ListRecurringSnapshotScheduleCmd.java 
> d34c09c 
>   api/src/org/apache/cloudstack/api/BaseCmd.java 0cfb950 
>   api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsCmd.java 
> 48c1e02 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java 
> c5a2d1a 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/DeleteAccountCmd.java 
> 7c1b206 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/DisableAccountCmd.java
>  6fdbefe 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/EnableAccountCmd.java 
> 59d6acd 
>   api/src/org/apache/cloudstack/api/command/admin/account/LockAccountCmd.java 
> 93ec1be 
>   
> api/src/org/apache/cloudstack/api/command/admin/account/UpdateAccountCmd.java 
> a8cf63f 
>   api/src/org/apache/cloudstack/api/command/admin/alert/GenerateAlertCmd.java 
> 620c5ed 
>   
> api/src/org/apache/cloudstack/api/command/admin/autoscale/CreateCounterCmd.java
>  6c4b81b 
>   
> api/src/org/apache/cloudstack/api/command/admin/autoscale/DeleteCounterCmd.java
>  50477f5 
>   api/src/org/apache/cloudstack/api/command/admin/cluster/AddClusterCmd.java 
> d0e7380 
>   
> api/src/org/apache/cloudstack/api/command/admin/cluster/DeleteClusterCmd.java 
> e1bc585 
>   
> api/src/org/apache/cloudstack/api/command/admin/cluster

Re: Review Request 16438: CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to update in 4.3 upgrade setup

[Harikrishna Patnala]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16438/
---

(Updated Dec. 23, 2013, 11:05 a.m.)


Review request for cloudstack and Rajesh Battala.


Bugs: CLOUDSTACK-5608
https://issues.apache.org/jira/browse/CLOUDSTACK-5608


Repository: cloudstack-git


Description
---

CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to 
update in 4.3 upgrade setup
1) Hyperv default builtin template is missing
2) Hyperv System vm template entry is missing or having invalid URL.


Diffs (updated)
-

  setup/db/db/schema-421to430.sql 574f510 
  setup/db/templates.sql 0f7958f 

Diff: https://reviews.apache.org/r/16438/diff/


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request 16373: SecurityProfile for NiciraNvpApi, including Unit and Integration tests

[Antonio Fornie]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16373/
---

(Updated Dec. 23, 2013, 10:32 a.m.)


Review request for cloudstack, daan Hoogland and Hugo Trippaers.


Changes
---

Missing license


Repository: cloudstack-git


Description
---

SecurityProfile for NiciraNvpApi, including Unit and
 Integration tests


Diffs (updated)
-

  plugins/network-elements/nicira-nvp/pom.xml 3bc8d14 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AccessConfiguration.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AccessRule.java
 PRE-CREATION 
  plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/Acl.java 
PRE-CREATION 
  plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/AclRule.java 
PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java
 6f695ad 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/SecurityProfile.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/SecurityRule.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NiciraNvpApiIT.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/test/com/cloud/network/nicira/NiciraNvpApiTest.java
 26517b5 
  plugins/network-elements/nicira-nvp/test/resources/config.properties 
PRE-CREATION 

Diff: https://reviews.apache.org/r/16373/diff/


Testing
---

Unit and Integration Tests, both builds for this single submodule and for the 
whole stack with both default and integration profiles


Thanks,

Antonio Fornie

Re: Review Request 16438: CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to update in 4.3 upgrade setup

[Harikrishna Patnala]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16438/
---

(Updated Dec. 23, 2013, 10:27 a.m.)


Review request for cloudstack and Rajesh Battala.


Bugs: CLOUDSTACK-5608
https://issues.apache.org/jira/browse/CLOUDSTACK-5608


Repository: cloudstack-git


Description
---

CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to 
update in 4.3 upgrade setup
1) Hyperv default builtin template is missing
2) Hyperv System vm template entry is missing or having invalid URL.


Diffs
-

  setup/db/db/schema-421to430.sql 574f510 

Diff: https://reviews.apache.org/r/16438/diff/


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request 16438: CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to update in 4.3 upgrade setup

[Harikrishna Patnala]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16438/
---

(Updated Dec. 23, 2013, 10:27 a.m.)


Review request for cloudstack and Rajesh Battala.


Bugs: CLOUDSTACK-5608
https://issues.apache.org/jira/browse/CLOUDSTACK-5608


Repository: cloudstack-git


Description
---

CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to 
update in 4.3 upgrade setup
1) Hyperv default builtin template is missing
2) Hyperv System vm template entry is missing or having invalid URL.


Diffs
-

  setup/db/db/schema-421to430.sql 574f510 

Diff: https://reviews.apache.org/r/16438/diff/


Testing
---


Thanks,

Harikrishna Patnala

Review Request 16438: CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to update in 4.3 upgrade setup

[Harikrishna Patnala]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16438/
---

Review request for cloudstack and Rajesh Battala.


Bugs: CLOUDSTACK-5608
https://issues.apache.org/jira/browse/CLOUDSTACK-5608


Repository: cloudstack-git


Description
---

CLOUDSTACK-5608: HyperV Builtin and System vm template entries missing/need to 
update in 4.3 upgrade setup
1) Hyperv default builtin template is missing
2) Hyperv System vm template entry is missing or having invalid URL.


Diffs
-

  setup/db/db/schema-421to430.sql 574f510 

Diff: https://reviews.apache.org/r/16438/diff/


Testing
---


Thanks,

Harikrishna Patnala

RE: Question about XenServer Snapshots

[Donal Lafferty]

That might have been a misunderstanding.

I was referring to a group of contributors who happened to work for Citrix.  

Since there they were clearing JIRA tickets, I thought it a good idea to create 
one for the issue.

DL


> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: 20 December 2013 16:05
> To: dev@cloudstack.apache.org
> Subject: Re: Question about XenServer Snapshots
> 
> Donal mentioned that this is actually code written by the XenServer group, so
> I will need to remove the CloudStack ticket I opened and open one for the
> XenServer group.
> 
> 
> On Thu, Dec 19, 2013 at 10:11 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> 
> > It looks like I found the issue: Insufficient space in the storage
> > repository.
> >
> > From the XenServer vmopsSnapshot plug-in's revert_memory_snapshot
> > method (which is invoked by the XenServer server resource):
> >
> > [root@XenServer-6 ~]# xe snapshot-revert
> > snapshot-uuid=82e33f6d-59f3-a26d-4171-d51cd58716d8
> > Error code: SR_BACKEND_FAILURE_44
> > Error parameters: , There is insufficient space,
> >
> > I'm thinking an error should be returned from the plug-in instead of "0".
> >
> > I can log a JIRA ticket.
> >
> >
> > On Thu, Dec 19, 2013 at 3:10 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> Hi,
> >>
> >> I have been experimenting with VM snapshots on XenServer and have
> >> noticed a problem that I hope someone might be able to shed some light
> on.
> >>
> >> In a normal flow of taking a VM snapshot, reverting to it, then
> >> deleting the VM snapshot, I have observed the following (which looks just
> fine):
> >>
> >> *SR:*
> >>
> >> uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> >>   name-label ( RW): Test
> >> name-description ( RW): iSCSI SR [10.10.8.108
> >> (iqn.2010-01.com.solidfire:3y8w.test.15; LUN 0:
> >> 33793877000ff47acc01: 93.1 GB (SolidFir))]
> >> host ( RO): XenServer-6.1-Tut-2
> >> type ( RO): lvmoiscsi
> >> content-type ( RO):
> >>
> >>
> >>- *Before VM snap:*
> >>
> >>
> >>  *Active:*
> >>
> >> uuid ( RO): b4587018-9679-4fe7-ba72-5523cb988cec
> >>   name-label ( RW): i-2-21-VM-DATA
> >> name-description ( RW):
> >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> >> virtual-size ( RO): 16106127360
> >> sharable ( RO): false
> >>read-only ( RO): false
> >>
> >>
> >>- *After VM snap:*
> >>
> >>
> >>  *Base copy (contains the data of the previously active VDI):*
> >>
> >> uuid ( RO): d167952d-deb4-4942-9ea8-c8b3777d885e
> >>   name-label ( RW): base copy
> >> name-description ( RW):
> >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> >> virtual-size ( RO): 16106127360
> >> sharable ( RO): false
> >>read-only ( RO): true
> >>
> >> *Snapshot:*
> >>
> >> uuid ( RO): 613dc799-cf69-445a-a2fe-611653e0b0c9
> >>   name-label ( RW): i-2-21-VM-DATA
> >> name-description ( RW):
> >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> >> virtual-size ( RO): 16106127360
> >> sharable ( RO): false
> >>read-only ( RO): false
> >>
> >> *Active (has the same UUID as the previously active VDI):*
> >>
> >>  uuid ( RO): b4587018-9679-4fe7-ba72-5523cb988cec
> >>   name-label ( RW): i-2-21-VM-DATA
> >> name-description ( RW):
> >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> >> virtual-size ( RO): 16106127360
> >> sharable ( RO): false
> >>read-only ( RO): false
> >>
> >>
> >>- *After revert to VM snap:*
> >>
> >>
> >> *Base copy:*
> >>
> >> uuid ( RO): d167952d-deb4-4942-9ea8-c8b3777d885e
> >>   name-label ( RW): base copy
> >> name-description ( RW):
> >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> >> virtual-size ( RO): 16106127360
> >> sharable ( RO): false
> >>read-only ( RO): true
> >>
> >> *Snapshot (this VDI is un-touched):*
> >>
> >> uuid ( RO): 613dc799-cf69-445a-a2fe-611653e0b0c9
> >>   name-label ( RW): i-2-21-VM-DATA
> >> name-description ( RW):
> >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> >> virtual-size ( RO): 16106127360
> >> sharable ( RO): false
> >>read-only ( RO): false
> >>
> >> *Active (this is a new VDI - the old active VDI was deleted):*
> >>
> >> uuid ( RO): b21284fa-347a-459a-a8bf-0fcd7717a134
> >>   name-label ( RW): i-2-21-VM-DATA
> >> name-description ( RW):
> >>  sr-uuid ( RO): 2a06-a8c8-11db-4a8b-f8d519f9ac3e
> >> virtual-size ( RO): 16106127360
> >> sharable ( RO): false
> >>read-only ( RO): fa

Re: Error running cloudstack-setup-management in 4.2

[Nguyen Anh Tu]

Still got this issue with 4.2. Anyone can help?

Thanks,

--Tuna


On Tue, Dec 17, 2013 at 2:35 PM, Nguyen Anh Tu  wrote:

> Dear guys,
>
> I do a fresh setup cloudstack version 4.2 from repo. I'm using Centos 6.4.
> When setting up MS, I get this error:
>
> bash-4.1# *cloudstack-setup-management*
> Starting to configure CloudStack Management Server:
> Configure sudoers ... [OK]
> Configure Firewall ...[OK]
> Configure CloudStack Management Server ...[Failed]
> Failed to configure CloudStack Management Server, please see the
> /var/log/cloudstack/setupManagement.log for detail
> Try to restore your system:
> Restore sudoers ...   [OK]
> Restore Firewall ...  [OK]
> Restore CloudStack Management Server ...[OK]
>
> Log from /var/log/cloudstack/management/setupManagement.log:
> (/var/log/cloudstack/setupManagement.log doesn't exist)
>
> DEBUG:root:execute:hostname -f
> DEBUG:root:execute:iptables-save|grep INPUT|grep -w 8080
> DEBUG:root:execute:iptables-save|grep INPUT|grep -w 7080
> DEBUG:root:execute:iptables-save|grep INPUT|grep -w 8250
> DEBUG:root:execute:iptables-save|grep INPUT|grep -w 9090
> DEBUG:root:execute:iptables-save > /etc/sysconfig/iptables
> DEBUG:root:execute:service iptables status
> DEBUG:root:execute:service iptables status
> DEBUG:root:execute:service iptables start
> DEBUG:root:execute:rm -f /etc/cloudstack/management/server.xml
> DEBUG:root:execute:rm -f /etc/cloudstack/management/tomcat6.conf
> DEBUG:root:execute:ln -s /etc/cloudstack/management/server-nonssl.xml
> /etc/cloudstack/management/server.xml
> DEBUG:root:execute:ln -s /etc/cloudstack/management/tomcat6-nonssl.conf
> /etc/cloudstack/management/tomcat6.conf
> DEBUG:root:execute:hostname --fqdn
> DEBUG:root:execute:mkdir /var/log/cloudstack-management/
> DEBUG:root:Failed to execute:mkdir: cannot create directory
> `/var/log/cloudstack-management/': File exists
> DEBUG:root:execute:service tomcat6 status
> DEBUG:root:Failed to execute:tomcat6 is stopped[  OK  ]
> DEBUG:root:execute:chkconfig --del tomcat6
> DEBUG:root:execute:service cloudstack-management status
> DEBUG:root:Failed to execute:cloudstack-management is stopped
> The pid file locates at /var/run/cloudstack-management.pid and lock file
> at /var/lock/subsys/cloudstack-management.
> Starting cloudstack-management will take care of them or you can
> manually clean up.
> DEBUG:root:execute:chkconfig --level 2345 cloudstack-management on
> DEBUG:root:execute:service cloudstack-management status
> DEBUG:root:Failed to execute:cloudstack-management is stopped
> The pid file locates at /var/run/cloudstack-management.pid and lock file
> at /var/lock/subsys/cloudstack-management.
> Starting cloudstack-management will take care of them or you can
> manually clean up.
> DEBUG:root:execute:service cloudstack-management start
> DEBUG:root:Failed to execute:Starting cloudstack-management[FAILED]code 4
> DEBUG:root:None
>
> What's error code 4?
>
> I found a similar issue from jira:
> https://issues.apache.org/jira/browse/CLOUDSTACK-1694
>
> However it's not my situation.
>
> Need help,
>
>
> --Tuna
>