Re: my two cents on RBAC/authorization

[Koushik Das]

I think it is important to identify what is exclusively for Cloudstack and what 
all can be reused across multiple services.

1. Authentication - Typically enterprises/service providers would like to reuse 
their existing authentication systems. So an easy mechanism needs to be 
provided for integrating with them. A built-in authentication provider can be 
there as it is today.
2. Mapping the user identity to a role - Once the user identity is established, 
it is mapped to a role based on some well defined policies/rules. This is again 
something that can be reused across multiple services and enterprises would 
already have it. So the same thing applies as #1.
3. Authorization - This is something that is specific to a service. Once the 
role is established, it is up to the specific service to determine what kind of 
access control needs to be enforced. The request that comes to Cloudstack will 
have some authorization token with the role information. Now based on this role 
a decision is to be made whether to allow or deny. This needs to be 
customizable.
4. Audit - This is again specific to a service and can be as simple as logging. 
But there needs to be a way to customize this as well to take some specific 
action.

-Koushik


On 29-Sep-2013, at 9:21 AM, Darren Shepherd  wrote:

> I've noticed there's a rbac branch and things are being committed
> there.  I didn't see any documentation about the design or anything
> (maybe it exists and I looked in the wrong place), so I'm just going
> to give you my two cents on authorization systems.  Hopefully this
> falls in line with what is being implemented, if not, at least we'll
> avoid the awkward conversation when its finish when I say the code is
> marginally useful and should be rewritten.
> 
> When talking about authorization there's a bunch of terms like
> principal, permission, subject, action, policy, etc.  I want to focus
> on policy.  Policy is central to an authorization system.  The policy
> is the collection of permissions that grant or deny access to some
> resource or action for a given subject.  RBAC is a really just a means
> to generate a policy.  Once you know the user, group, roles, and the
> permissions of those entities that aggregation of information forms
> the policy.  You then take that policy and use it determine if the
> given resource/action is granted/denied to a particular subject.
> 
> It is really important that policy is a first class object in an
> authorization system.  This is important to understand because usually
> in a big fat enterprise-y company, they really want you to enforce the
> policy, but not necessarily maintain it.  For example, you'll go to
> your fortune 500 company and they'll tell you they need RBAC.  So you
> go and create an RBAC system.  The problem is that the fortune 500
> company probably already has a RBAC system, and its probably AD based.
> So when they said they need RBAC, the really meant you need to
> enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
> your good, if you implemented RBAC - > Authorization, your kinda
> screwed. Now you need to create a system to sync the two RBACs.  And
> keeping data in two places and trying to sync them is never a good
> idea.  Now if you implemented your system as having a policy as a
> first class object, you can just swap your RBAC for theirs and all is
> still swell.
> 
> So if I was to implement this, this is how I'd do it.  (And if this
> sounds a lot like IAM, its because it is.  If Amazon got anything
> right, it's IAM).  The authenticator should be able to implement
> another interface that allows it to supply a Policy object during
> authentication.  This is logical in that the authentication systems
> quite often hold authorization information too.  If the authenticator
> doesn't implement the interface we fall back to generating the policy
> ourself.  The policy is then consulted to see if the API command and
> the resulting entities are granted/denied.  So far none of this has
> anything to do with RBAC.  So the RBAC is implemented in that default
> fallback implemenation that generates the policy.  You map the current
> user/account to groups and roles and get the policies of those
> entities to construct the policy.
> 
> Now for storing the policies I wouldn't do it in a traditional
> normalized form.  All you need is tables for user/group/role and the
> mappings for each.  The for user, group, and role you can specify a
> policy JSON blob and that gets stored in the database as a mediumtext
> field on the user/group/role row.  From an API perspective (just like
> IAM), you just let people upload the JSON blobs for each.
> 
> So if we do it this way, we can have our own simple RBAC but then be
> able to plug into far more complex and powerful authorization systems.
> Hopefully that all made sense.
> 
> Darren

Re: [MAJOR][BUG] ACS powers off some VMs in vSphere - when MS service is restarted

[Koushik Das]

Ilya,
Can you check in the MS logs if more than one thread tries to process connect 
for the same host simultaneously? In case of XS I had seen that there is a 
possibility of the vm states getting incorrectly determined (during vm sync) in 
case more than one thread tries to process connect to the host simultaneously. 
The fix for 4636 can be added to the 4.1.x branch but if the root cause turns 
out to be the same.

-Koushik

On 26-Sep-2013, at 9:18 PM, "Musayev, Ilya"  wrote:

> ++Koushik
> 
> Thanks Sowmya
> 
> Koushik 
> 
> Any reason why this is cannot be applied to ACS 4.1?  Since I'm Release 
> Manager for 4.1.x branch, I will work on testing and releasing 4.1.2
> 
> Thanks
> ilya
> 
>> -Original Message-
>> From: Sowmya Krishnan [mailto:sowmya.krish...@citrix.com]
>> Sent: Thursday, September 26, 2013 3:03 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [MAJOR][BUG] ACS powers off some VMs in vSphere - when MS
>> service is restarted
>> 
>> Ilya,
>> Is this similar to this issue:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-4636
>> Fix for this has gone in 4.2-forward and master. As stated in the bug, this
>> could happen if more than one thread tries to process the same host post
>> MS restart.
>> 
>>> -Original Message-
>>> From: Musayev, Ilya [mailto:imusa...@webmd.net]
>>> Sent: Thursday, September 26, 2013 3:43 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: [MAJOR][BUG] ACS powers off some VMs in vSphere - when
>> MS
>>> service is restarted
>>> 
>>> Sorry if the error log is abit hard to read, as an example, please
>>> track the vmname i-2-262-acs-docs-fc17.
>>> 
>>> 2013-09-25 14:35:49,928 DEBUG [vmware.resource.VmwareResource]
>>> (AgentTaskPool-1:null) Detecting a new state but couldn't find a old
>>> state so adding it to the changes: i-2-262-acs-docs-fc17
>>> 2013-09-25 14:35:53,614 DEBUG [cloud.vm.VirtualMachineManagerImpl]
>>> (AgentTaskPool-1:null) VM i-2-262-acs-docs-fc17: cs state = Running
>>> and realState = Stopped
>>> 2013-09-25 14:35:53,614 DEBUG [cloud.vm.VirtualMachineManagerImpl]
>>> (AgentTaskPool-1:null) VM i-2-262-acs-docs-fc17: cs state = Running
>>> and realState = Stopped
>>> 2013-09-25 14:35:53,614 INFO  [cloud.ha.HighAvailabilityManagerImpl]
>>> (AgentTaskPool-1:null) Skip HA for VMware VM i-2-262-acs-docs-fc17
>>> 2013-09-25 14:35:53,694 DEBUG [agent.transport.Request]
>>> (AgentTaskPool-
>>> 1:null) Seq 11-1418264581: Sending  { Cmd , MgmtId: 345049078181, via:
>>> 11,
>>> Ver: v1, Flags: 100101,
>>> [{"StopCommand":{"isProxy":false,"vmName":"i-2-262-
>>> acs-docs-fc17","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-
>>> 2-
>>> 278-demo01t-ops-
>>> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-281-acs-
>>> appliance","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-28
>>> 3-
>>> vmbld01l-ops-
>> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"
>>> i-2-
>>> 285-ossec01l-ops-08","wait":0}}] }
>>> 2013-09-25 14:35:53,695 DEBUG [agent.transport.Request]
>>> (AgentTaskPool-
>>> 1:null) Seq 11-1418264581: Executing:  { Cmd , MgmtId: 345049078181,
>>> via: 11,
>>> Ver: v1, Flags: 100101,
>>> [{"StopCommand":{"isProxy":false,"vmName":"i-2-262-
>>> acs-docs-fc17","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-
>>> 2-
>>> 278-demo01t-ops-
>>> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-281-acs-
>>> appliance","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-28
>>> 3-
>>> vmbld01l-ops-
>> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"
>>> i-2-
>>> 285-ossec01l-ops-08","wait":0}}] }
>>> 2013-09-25 14:35:53,702 INFO  [vmware.resource.VmwareResource]
>>> (DirectAgent-3:vmha62d-ops-08.portal.webmd.com) Executing resource
>>> StopCommand:
>>> {"isProxy":false,"vmName":"i-2-262-acs-docs-fc17","wait":0}
>>> 2013-09-25 14:35:53,703 DEBUG [vmware.mo.HostMO] (DirectAgent-
>>> 3:vmha62d-ops-08.portal.webmd.com) find VM i-2-262-acs-docs-fc17 on
>>> host
>>> 2013-09-25 14:35:54,753 INFO  [vmware.resource.VmwareResource]
>>> (DirectAgent-3:vmha62d-ops-08.portal.webmd.com) VM
>>> i-2-262-acs-docs-fc17 is already in stopped state
>>> 
 -Original Message-
 From: Musayev, Ilya [mailto:imusa...@webmd.net]
 Sent: Wednesday, September 25, 2013 6:08 PM
 To: dev@cloudstack.apache.org
 Subject: [MAJOR][BUG] ACS powers off some VMs in vSphere - when MS
 service is restarted
 
 Hi All,
 
 I'd like to raise an awareness on the issue with ACS 4.1.1 (I assume
 other versions are affected - since I could not find any changes in
 the latest code that would state otherwise).
 
 On MS server start/restart, it checks all the VMs for their state,
 if some reason state is either not found or comes as stopped - which
 is inaccurate, the vms will *power off*.
 
 On todays occurrence, half of my plant  went down because ACS
 invoked StopCommand on the vms that either had no state or for some
 reason agentState 

Re: [PROPOSAL] Service monitoring tool in virtual router

[Koushik Das]

This is a very useful feature. Can this be extended to the other system VMs? 
SSVM and CPVM

Based on the discussion I see that there is an assumption that restarting 
services/rebooting should fix the issues. Is that always true? What if the 
service fails to restart after repeated attempts? What is the fallback?

-Koushik


On 01-Oct-2013, at 3:15 AM, Chiradeep Vittal  
wrote:

> Good idea. If x and y and z are borked, initiate shutdown?
> 
> More generically, it seems we need some form of in-VM automation that can
> co-ordinate with top-level orchestration
> 
> On 9/28/13 4:14 AM, "Daan Hoogland"  wrote:
> 
>> Even when always restarting on every glitch we need to monitor the inside
>> of the vr to know when to restart/respin a new vr. There is much
>> functionality present on the vr an for us it is not possible to say for
>> sure what is important to a customer installation so the admin should be
>> able to define the minimal reqs that will stop us from spinning up a new
>> vr. And there must be tools present for monitoring these reqs.
>> 
>> makes sense?
>> 
>> 
>> On Thu, Sep 26, 2013 at 10:01 PM, David Nalley  wrote:
>> 
>>> For what it's worth we created an ACS-specific MIB (beneath the
>>> org.apache MIB) so really this is just a matter of defining and
>>> publishing it.
>>> 
>>> But lets think about monit being used to restart services - with HA,
>>> Redundant VR, are we sure that we want to inject yet another point of
>>> control into things? Is it better to just respawn an instance since
>>> they are essentially stateless? I don't know, but management server,
>>> local daemons, and other SysVMs making decisions seems like we are
>>> increasing complexity.
>>> 
>>> --David
>>> 
>>> On Thu, Sep 26, 2013 at 10:31 AM, Chiradeep Vittal
>>>  wrote:
 In this case you would have to invent another enterprise MIB. Not too
 hard, but I'd argue that it needs to be proxied through some other
>>> service
 anyway and it represents a different integration point with ACS.
>>> Depends
 on whether you consider the system vm part of the ACS deployment, or
>>> an
 entity like a host.
 
 On 9/26/13 10:27 AM, "Alex Huang"  wrote:
 
> Using SNMP for alert notification is not a bad idea though.  I don't
>>> see
> why we can't do that instead of posting to the management server.
>>> This
> is specifically referring to the second part of the proposal.  Why
> reinvent that part of it?
> 
> --Alex
> 
>> -Original Message-
>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> Sent: Wednesday, September 25, 2013 10:28 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>> 
>> SNMP wouldn't restart a failed process nor would it generate
>>> alerts. It
>> is
>> simply too generic for the requirements outlined here. The proposal
>>> does
>> not talk about modifying monit, just using it. That wouldn't trigger
>> the AGPL.
>> I think the idea is to have a tight monitoring loop that scales: so
>> executing the
>> monitoring loop in-situ makes sense.
>> 
>> 
>> On 9/25/13 9:53 PM, "David Nalley"  wrote:
>> 
>>> On Wed, Sep 25, 2013 at 9:30 AM, Jayapal Reddy Uradi
>>>  wrote:
 Hi,
 
 Currently in virtual router there is no way to recover and
>>> notify if
 some service goes down unexpectedly.
 
 This feature is about monitoring all the services rendered by the
 virtual router, ensure that the services are running through the
>>> life
 time of the VR.
 
 On service failure:
 1. Generate an alert and event indicating failure 2. Restart the
 service
 
 Services to be monitored:
 DHCP, DNS, haproxy, password server etc.
 
 As part of monitoring there are two activities
 
 1. One is monitoring the services in VR and log the events. Using
 monit for monitoring services  2. Second part is pushing alerts
>>> from
 router to  MS server. Thinking on POST the logs to web server in
>>> MS.
 
 I will be updating more details and FS in this thread.
 
 I created enhancement bug for this.
 https://issues.apache.org/jira/browse/CLOUDSTACK-4736
 
 Thanks,
 Jayapal
>>> 
>>> So several things - why not make this via SNMP? Query processes,
>>> and
>>> many other things. This should be relatively simple, is well known,
>>> can
>>> be locked down (or could be monitored for many other things by
>>> external
>>> monitoring packages) and is the defacto standard for monitoring
>>> hosts.
>>> Second - monit is Affero GPL licensed - which is a cat-x license.
>>> While I expect that we would merely use this and not do any
>>> hacking on
>>> it - I think its inclusion might be a surprise (and fo

Re: A question on vm migrations when hosts are set into a maintenance mode.

[Koushik Das]

It is already a global setting in 4.2. The name of the setting is 
"execute.in.sequence.hypervisor.commands".

Check out Config.java

ExecuteInSequence("Advanced", ManagementServer.class, Boolean.class, 
"execute.in.sequence.hypervisor.commands", "true", "If set to true, 
StartCommand, StopCommand, CopyCommand will be synchronized on the agent side." 
+
" If set to false, these commands become asynchronous. Default value is 
true.", null),


-Koushik

On 02-Oct-2013, at 10:43 PM, Alex Ough 
mailto:alex.o...@sungard.com>> wrote:

Thanks for the reply, Marcus.

What about the option #3, which is to make it as a global setting?
I think it can prevent side effects if exist.

Alex Ough


On Wed, Oct 2, 2013 at 11:37 AM, Marcus Sorensen 
mailto:shadow...@gmail.com>>wrote:

Not sure. I don't know the history well enough to know if there were
issues in the past, it might be that some hypervisors were fine and
others weren't.

On Wed, Oct 2, 2013 at 9:21 AM, Alex Ough 
mailto:alex.o...@sungard.com>> wrote:
Marcus/Kelven,

Any thoughts on my suggestions?

Thanks
Alex Ough


On Tue, Sep 24, 2013 at 12:09 PM, Alex Ough 
mailto:alex.o...@sungard.com>>
wrote:

Oh, sorry for the confusion. I must have reversed the flags.
As Kelven pointed, it is set as 'TRUE', which makes the process as
sequential.

So my questions are
1. If there is any reason why the method have been defined to return
'TRUE' always?
2. Do we expect any side effects and/or malfunctioning if we change it
to
returning 'FALSE'?
3. For a resolution without breaking possible flows, can we add the
value
of 'executeInSequence' to the global setting if #2 answers YES?


On Tue, Sep 24, 2013 at 11:19 AM, Marcus Sorensen 
mailto:shadow...@gmail.com>>
wrote:

I thought executeInSequence of 'true' made it go serially, or
sequentially. In my codebase for 4.1,4.2,master it's been 'true' since
August of 2010:

2010-08-11 09:13:29 -0700 19) public class MigrateCommand extends
Command
{
2010-08-11 09:13:29 -0700 20) String vmName;
2010-08-11 09:13:29 -0700 21) String destIp;
2011-08-10 10:26:04 -0700 22) String hostGuid;
2010-08-11 09:13:29 -0700 23) boolean isWindows;
2010-08-11 09:13:29 -0700 24)
2010-08-11 09:13:29 -0700 25)
2010-08-11 09:13:29 -0700 26) protected MigrateCommand() {
2010-08-11 09:13:29 -0700 27) }
2012-12-03 22:06:41 -0800 28)
2010-08-11 09:13:29 -0700 29) public MigrateCommand(String vmName,
String destIp, boolean isWindows)
2010-08-11 09:13:29 -0700 30) this.vmName = vmName;
2010-08-11 09:13:29 -0700 31) this.destIp = destIp;
2010-08-11 09:13:29 -0700 32) this.isWindows = isWindows;
2010-08-11 09:13:29 -0700 33) }
2012-12-03 22:06:41 -0800 34)
2010-08-11 09:13:29 -0700 35) public boolean isWindows() {
2010-08-11 09:13:29 -0700 36) return isWindows;
2010-08-11 09:13:29 -0700 37) }
2012-12-03 22:06:41 -0800 38)
2010-08-11 09:13:29 -0700 39) public String getDestinationIp() {
2010-08-11 09:13:29 -0700 40) return destIp;
2010-08-11 09:13:29 -0700 41) }
2012-12-03 22:06:41 -0800 42)
2010-08-11 09:13:29 -0700 43) public String getVmName() {
2010-08-11 09:13:29 -0700 44) return vmName;
2010-08-11 09:13:29 -0700 45) }
2012-12-03 22:06:41 -0800 46)
2011-08-10 10:26:04 -0700 47) public void setHostGuid(String guid)
{
2011-08-10 10:26:04 -0700 48) this.hostGuid = guid;
2011-08-10 10:26:04 -0700 49) }
2012-12-03 22:06:41 -0800 50)
2011-08-10 10:26:04 -0700 51) public String getHostGuid() {
2011-08-10 10:26:04 -0700 52) return this.hostGuid;
2011-08-10 10:26:04 -0700 53) }
2010-08-11 09:13:29 -0700 54)
2010-08-11 09:13:29 -0700 55) @Override
2010-08-11 09:13:29 -0700 56) public boolean executeInSequence() {
2010-08-11 09:13:29 -0700 57) return true;
2010-08-11 09:13:29 -0700 58) }
2010-08-11 09:13:29 -0700 59) }

On Tue, Sep 24, 2013 at 9:58 AM, Chip Childers
mailto:chip.child...@sungard.com>> wrote:
Hey Kelven - This topic was discussed briefly in the past [1].  Are
you
able to provide any thoughts on Alex's ideas below?

-chip


[1] http://markmail.org/message/fznrszaswruvlmuy



On Tue, Sep 24, 2013 at 10:53:04AM -0500, Alex Ough wrote:
For a resolution without breaking possible flows, I'd like to add
the
value
of 'executeInSequence' to the global setting.
Is there any reason not to do this?

Thanks
Alex Ough


On Mon, Sep 23, 2013 at 12:57 PM, Alex Ough 
mailto:alex.o...@sungard.com>>
wrote:

All,

After a little more investigation, I found that the
'MigrateCommand'
defined its 'executeInSequence' method to return 'FALSE', which
seems to
make the vm migrations as serial even if the migration requests
are
dispatched to ha_worker in parallel.
You can confirm this in line 56 of
'/cloudstack/core/src/com/cloud/agent/api/MigrateCommand.java'

So my question is if there is any reason why the method have been
defined to return 'FALSE' always?
And do we expect any side effects and/or malfunctioning if we

Re: Hi

[Koushik Das]

Hi Steve,

Welcome to CloudStack. Looking forward to working with you.


On 02-Oct-2013, at 6:10 PM, Chip Childers  wrote:

> Welcome Steve!
> 
> 
> On Wed, Oct 2, 2013 at 12:38 AM, Steve Wilson wrote:
> 
>> Hi Everyone,
>> 
>> I just wanted to take a second and introduce myself.  I recently joined
>> Citrix as the VP of Cloud Engineering, and I'm responsible for the Citrix
>> CloudPlatofrm (powered by Apache CloudStack).  I just joined the list and
>> am looking forward to working with everyone in the community.  Feel free to
>> drop me a note if you have suggestions for me on how Citrix can best work
>> with the Apache CloudStack community.
>> 
>> Thanks,
>> 
>> -Steve
>> twitter: @virtualsteve
>> email: steve.wil...@citrix.com
>> 

Re: A question on vm migrations when hosts are set into a maintenance mode.

[Koushik Das]

Alena,
I see that you had added this config setting. Any specific reason that this 
only for Start/Stop/Copy and not for all the commands as Alex mentioned? The 
name of the setting looks generic.

-Koushik

On 03-Oct-2013, at 8:10 PM, Alex Ough  wrote:

> Hi Koushik,
> 
> Thanks for your reply, but unfortunately, this setting does NOT cover
> 'MigrateCommand'.
> As you specified, it seems to be effective only in Start/Stop/CopyCommand.
> 
> So can we include 'MigrateCommand' in that setting?
> 
> Thanks
> Alex Ough
> 
> 
> On Wed, Oct 2, 2013 at 11:44 PM, Koushik Das  wrote:
> 
>> It is already a global setting in 4.2. The name of the setting is
>> "execute.in.sequence.hypervisor.commands".
>> 
>> Check out Config.java
>> 
>>ExecuteInSequence("Advanced", ManagementServer.class, Boolean.class,
>> "execute.in.sequence.hypervisor.commands", "true", "If set to true,
>> StartCommand, StopCommand, CopyCommand will be synchronized on the agent
>> side." +
>>" If set to false, these commands become asynchronous. Default value
>> is true.", null),
>> 
>> 
>> -Koushik
>> 
>> On 02-Oct-2013, at 10:43 PM, Alex Ough > alex.o...@sungard.com>> wrote:
>> 
>> Thanks for the reply, Marcus.
>> 
>> What about the option #3, which is to make it as a global setting?
>> I think it can prevent side effects if exist.
>> 
>> Alex Ough
>> 
>> 
>> On Wed, Oct 2, 2013 at 11:37 AM, Marcus Sorensen > <mailto:shadow...@gmail.com>>wrote:
>> 
>> Not sure. I don't know the history well enough to know if there were
>> issues in the past, it might be that some hypervisors were fine and
>> others weren't.
>> 
>> On Wed, Oct 2, 2013 at 9:21 AM, Alex Ough > alex.o...@sungard.com>> wrote:
>> Marcus/Kelven,
>> 
>> Any thoughts on my suggestions?
>> 
>> Thanks
>> Alex Ough
>> 
>> 
>> On Tue, Sep 24, 2013 at 12:09 PM, Alex Ough > alex.o...@sungard.com>>
>> wrote:
>> 
>> Oh, sorry for the confusion. I must have reversed the flags.
>> As Kelven pointed, it is set as 'TRUE', which makes the process as
>> sequential.
>> 
>> So my questions are
>> 1. If there is any reason why the method have been defined to return
>> 'TRUE' always?
>> 2. Do we expect any side effects and/or malfunctioning if we change it
>> to
>> returning 'FALSE'?
>> 3. For a resolution without breaking possible flows, can we add the
>> value
>> of 'executeInSequence' to the global setting if #2 answers YES?
>> 
>> 
>> On Tue, Sep 24, 2013 at 11:19 AM, Marcus Sorensen > <mailto:shadow...@gmail.com>>
>> wrote:
>> 
>> I thought executeInSequence of 'true' made it go serially, or
>> sequentially. In my codebase for 4.1,4.2,master it's been 'true' since
>> August of 2010:
>> 
>> 2010-08-11 09:13:29 -0700 19) public class MigrateCommand extends
>> Command
>> {
>> 2010-08-11 09:13:29 -0700 20) String vmName;
>> 2010-08-11 09:13:29 -0700 21) String destIp;
>> 2011-08-10 10:26:04 -0700 22) String hostGuid;
>> 2010-08-11 09:13:29 -0700 23) boolean isWindows;
>> 2010-08-11 09:13:29 -0700 24)
>> 2010-08-11 09:13:29 -0700 25)
>> 2010-08-11 09:13:29 -0700 26) protected MigrateCommand() {
>> 2010-08-11 09:13:29 -0700 27) }
>> 2012-12-03 22:06:41 -0800 28)
>> 2010-08-11 09:13:29 -0700 29) public MigrateCommand(String vmName,
>> String destIp, boolean isWindows)
>> 2010-08-11 09:13:29 -0700 30) this.vmName = vmName;
>> 2010-08-11 09:13:29 -0700 31) this.destIp = destIp;
>> 2010-08-11 09:13:29 -0700 32) this.isWindows = isWindows;
>> 2010-08-11 09:13:29 -0700 33) }
>> 2012-12-03 22:06:41 -0800 34)
>> 2010-08-11 09:13:29 -0700 35) public boolean isWindows() {
>> 2010-08-11 09:13:29 -0700 36) return isWindows;
>> 2010-08-11 09:13:29 -0700 37) }
>> 2012-12-03 22:06:41 -0800 38)
>> 2010-08-11 09:13:29 -0700 39) public String getDestinationIp() {
>> 2010-08-11 09:13:29 -0700 40) return destIp;
>> 2010-08-11 09:13:29 -0700 41) }
>> 2012-12-03 22:06:41 -0800 42)
>> 2010-08-11 09:13:29 -0700 43) public String getVmName() {
>> 2010-08-11 09:13:29 -0700 44) return vmName;
>> 2010-08-11 09:13:29 -0700 45) }
>> 2012-12-03 22:06:41 -0800 46)
>> 2011-08-10 10:26:04 -0700 47) public vo

Re: Back end volume names in KVM

[Koushik Das]

On 10-Oct-2013, at 9:27 AM, Marcus Sorensen  wrote:

> Does anyone have any reservations about changing the volume identifier in
> KVM's volume creation command to be the uuid of the volume? Currently for
> new volumes it generates a random uuid and passes that back to be stored in
> the database. From an admin perspective, the only way to link a volume on
> the back end (be it a qcow2 image or an LVM volume) to one as reported is
> to look in the DB and see what this 'secondary uuid' is and look for THAT
> as the filename/image name on the back end. It would simply remove a layer
> of translating uuid to another hidden uuid to get file/volume name.
> 

The 'uuid' field in volumes table was added later on. Since previously there 
was no uuid for a volume it was done that way.
+1 for the change.

> It shouldn't disrupt or change current volumes, just new ones.
> 
> The only caveat I can think of so far is if we wanted multiple files/images
> on the back end to map to one volume, but I don't see that as a blocker
> since it would probably have lots of other implications to the tracking
> volume objects.

Re: [PROPOSAL] Remove Setters from *JoinVO

[Koushik Das]

Views are meant to be read only. So +1 for removing setters.

On 04-Oct-2013, at 10:59 PM, "SuichII, Christopher"  
wrote:

> *JoinVOs are used to store entries from MySQL views, which are not editable. 
> I think removing setters from the *JoinVOs may help avoid some potential 
> confusion as setters seem to imply that the fields are editable, which they 
> really aren't.
> 
> I started looking around and it looks like most setters in *JoinVOs aren't 
> actually used since the creation of *VOs is handled by java reflection. 
> Please let me know if this is not the case or if I'm misunderstanding the way 
> the MySQL views work.
> 
> -Chris
> -- 
> Chris Suich
> chris.su...@netapp.com
> NetApp Software Engineer
> Data Center Platforms – Cloud Solutions
> Citrix, Cisco & Red Hat
> 

Possible bug in DeploymentPlanner?

[Koushik Das]

I was making some changes in the storage pool allocators related to some bug 
fix and came across this code snippet in planDeplyment() method of 
DeploymentPlanningManagerImpl.java.
In this if the checkClustersforDestination() returns null and the 'avoids' 
parameter is not correctly updated (one such place can be the storage 
allocators) then the while loop will never terminate. Is there any  assumption 
about how the 'avoids' parameter needs to be updated? From the code it is not 
very intuitive. I saw some places in the storage pool allocators where this 
will not get updated.

Wanted to understand the reason for doing it this way? Can the while (true) 
condition be replaced with something more intuitive?

while (true) {
if (planner instanceof DeploymentClusterPlanner) {
ExcludeList plannerAvoidInput = new 
ExcludeList(avoids.getDataCentersToAvoid(),
avoids.getPodsToAvoid(), 
avoids.getClustersToAvoid(), avoids.getHostsToAvoid(),
avoids.getPoolsToAvoid());

clusterList = ((DeploymentClusterPlanner) 
planner).orderClusters(vmProfile, plan, avoids);
if (clusterList != null && !clusterList.isEmpty()) {
// planner refactoring. call allocators to list hosts
ExcludeList plannerAvoidOutput = new 
ExcludeList(avoids.getDataCentersToAvoid(),
avoids.getPodsToAvoid(), 
avoids.getClustersToAvoid(), avoids.getHostsToAvoid(),
avoids.getPoolsToAvoid());

resetAvoidSet(plannerAvoidOutput, plannerAvoidInput);

dest = checkClustersforDestination(clusterList, 
vmProfile, plan, avoids, dc,
getPlannerUsage(planner, vmProfile, plan, 
avoids), plannerAvoidOutput);
if (dest != null) {
return dest;
}
// reset the avoid input to the planners
resetAvoidSet(avoids, plannerAvoidOutput);

} else {
return null;
}
} else {


}
}

Re: Possible bug in DeploymentPlanner?

[Koushik Das]

Thanks for the explanation Prachi.

Here is one issue I see with what you explained below. If an allocator is not 
suppose to handle a particular scenario how should it deal with the avoid set. 
Should it put all available pools in the avoid set. In that case subsequent 
allocators won't get a chance to do anything as all pools are in avoid set. If 
more than one allocator can operate on a particular pool then the situation 
becomes tricky.

To give an example, if there is a request for volume on shared storage and 
first allocator to get called is the local allocator. Since it is not going to 
handle this case it will return empty/null list. Now should it put all the 
other shared pools in avoid set or only the local pools in avoid set? Similarly 
if the request is for a local volume and the request first goes to zone or 
cluster-wide storage allocator what should be there in the avoid set?



On 15-Oct-2013, at 11:31 PM, Prachi Damle 
 wrote:

> Koushik,
> 
> The deployment planning process is divided between DeploymentPlanners and 
> Allocators. The planners are supposed to feed a list of clusters the 
> allocators should look into to find a potential destination. While the 
> allocators should provide a avoid set back to the planners consisting of any 
> resource not considered.
> 
> Reasoning how the planners work:
> Planners can set/reset clusters into avoid set depending on the heuristics 
> they implement and the order in which they want the clusters to be traversed.
> When all options of the planner are exhausted they should return an empty 
> cluster list halting the search.
> 
> What should the allocators do?
> Iterate over the given cluster list and in each cluster find out suitable 
> resources - all other resources not considered AND not suitable MUST be added 
> to the avoid set so that the planners get the correct avoid input.
> This is necessary for the logic to not enter an infinite loop.
> 
> As you see, only planners can halt the search process by referring to the 
> avoid set provided by the allocators. If you see any case not following this, 
> that needs to be fixed. 
> 
> Also, I do think in general it will be safe to add a configurable retry limit 
> on this loop to have control in case any new logic in allocators don't follow 
> this reasoning. I will add that limit.
> 
> Thanks,
> Prachi
> 
> 
> 
> -Original Message-
> From: Koushik Das [mailto:koushik@citrix.com] 
> Sent: Tuesday, October 15, 2013 9:19 AM
> To: 
> Subject: Possible bug in DeploymentPlanner?
> 
> I was making some changes in the storage pool allocators related to some bug 
> fix and came across this code snippet in planDeplyment() method of 
> DeploymentPlanningManagerImpl.java.
> In this if the checkClustersforDestination() returns null and the 'avoids' 
> parameter is not correctly updated (one such place can be the storage 
> allocators) then the while loop will never terminate. Is there any  
> assumption about how the 'avoids' parameter needs to be updated? From the 
> code it is not very intuitive. I saw some places in the storage pool 
> allocators where this will not get updated.
> 
> Wanted to understand the reason for doing it this way? Can the while (true) 
> condition be replaced with something more intuitive?
> 
>while (true) {
>if (planner instanceof DeploymentClusterPlanner) {
>ExcludeList plannerAvoidInput = new 
> ExcludeList(avoids.getDataCentersToAvoid(),
>avoids.getPodsToAvoid(), 
> avoids.getClustersToAvoid(), avoids.getHostsToAvoid(),
>avoids.getPoolsToAvoid());
> 
>clusterList = ((DeploymentClusterPlanner) 
> planner).orderClusters(vmProfile, plan, avoids);
>if (clusterList != null && !clusterList.isEmpty()) {
>// planner refactoring. call allocators to list hosts
>ExcludeList plannerAvoidOutput = new 
> ExcludeList(avoids.getDataCentersToAvoid(),
>avoids.getPodsToAvoid(), 
> avoids.getClustersToAvoid(), avoids.getHostsToAvoid(),
>avoids.getPoolsToAvoid());
> 
>resetAvoidSet(plannerAvoidOutput, plannerAvoidInput);
> 
>dest = checkClustersforDestination(clusterList, 
> vmProfile, plan, avoids, dc,
>getPlannerUsage(planner, vmProfile, plan, 
> avoids), plannerAvoidOutput);
>if (dest != null) {
>return dest;
>}
>// reset the avoid input to the planners
>resetAvoidSet(avoids, plannerAvoidOutput);
> 
>} else {
>return null;
>}
>} else {
> 
> 
>}
>}
> 
> 
> 
> 
> 
> 

Re: Possible bug in DeploymentPlanner?

[Koushik Das]

On 16-Oct-2013, at 3:12 AM, Prachi Damle  wrote:

> 
> -Original Message-
> From: Koushik Das [mailto:koushik@citrix.com] 
> Sent: Tuesday, October 15, 2013 11:43 AM
> To: 
> Subject: Re: Possible bug in DeploymentPlanner?
> 
> 
> Thanks for the explanation Prachi.
> 
> Here is one issue I see with what you explained below. If an allocator is not 
> suppose to handle a particular scenario how should it deal with the avoid 
> set. Should it put all available pools in the avoid set. In that case 
> subsequent allocators won't get a chance to do anything as all pools are in 
> avoid set. If more than one allocator can operate on a particular pool then 
> the situation becomes tricky.
> 
> To give an example, if there is a request for volume on shared storage and 
> first allocator to get called is the local allocator. Since it is not going 
> to handle this case it will return empty/null list. Now should it put all the 
> other shared pools in avoid set or only the local pools in avoid set? 
> Similarly if the request is for a local volume and the request first goes to 
> zone or cluster-wide storage allocator what should be there in the avoid set?
> 
> 
> [Prachi] I see the bug you are thinking about - deploymentPlanningManager :: 
> canAvoidCluster  is only checking the shared storages and thus does not put 
> the cluster in avoid set in case the local storage is not a match for the 
> host.
> 
> I think the storage allocators should put the resources not considered, in 
> avoid set, that are within their scope. Also they should do so only when they 
> are supposed to handle the request. Thus local allocator sees only local 
> pools, so it should place them into avoid set if not considered and only when 
> this allocator is supposed to handle the scenario. While the 
> zone-wide/cluster-wide should set those within their scope.
> Also, the allocators have a defined order in which they get invoked and we 
> need to maintain the order defined in the componentContext.xml
> 
> Now to solve the bug, the deploymentPlanningManager :: canAvoidCluster  needs 
> to consider which scenario applies for the given vmprofile - i.e whether its 
> local storage or shared to correctly figure out if cluster can be avoided by 
> considering applicable pools only.
> Does this work fine for your scenario?
> 
> 
[Koushik] Not sure if canAvoidCluster() is the right place. Shared and local 
pools can belong to the same cluster, so the cluster cannot be put in avoid 
set. Only the pools needs to be selectively added to avoid set.

> 
> On 15-Oct-2013, at 11:31 PM, Prachi Damle 
> wrote:
> 
>> Koushik,
>> 
>> The deployment planning process is divided between DeploymentPlanners and 
>> Allocators. The planners are supposed to feed a list of clusters the 
>> allocators should look into to find a potential destination. While the 
>> allocators should provide a avoid set back to the planners consisting of any 
>> resource not considered.
>> 
>> Reasoning how the planners work:
>> Planners can set/reset clusters into avoid set depending on the heuristics 
>> they implement and the order in which they want the clusters to be traversed.
>> When all options of the planner are exhausted they should return an empty 
>> cluster list halting the search.
>> 
>> What should the allocators do?
>> Iterate over the given cluster list and in each cluster find out suitable 
>> resources - all other resources not considered AND not suitable MUST be 
>> added to the avoid set so that the planners get the correct avoid input.
>> This is necessary for the logic to not enter an infinite loop.
>> 
>> As you see, only planners can halt the search process by referring to the 
>> avoid set provided by the allocators. If you see any case not following 
>> this, that needs to be fixed. 
>> 
>> Also, I do think in general it will be safe to add a configurable retry 
>> limit on this loop to have control in case any new logic in allocators don't 
>> follow this reasoning. I will add that limit.
>> 
>> Thanks,
>> Prachi
>> 
>> 
>> 
>> -Original Message-
>> From: Koushik Das [mailto:koushik@citrix.com] 
>> Sent: Tuesday, October 15, 2013 9:19 AM
>> To: 
>> Subject: Possible bug in DeploymentPlanner?
>> 
>> I was making some changes in the storage pool allocators related to some bug 
>> fix and came across this code snippet in planDeplyment() method of 
>> DeploymentPlanningManagerImpl.java.
>> In this if the checkClustersforDestination() returns null and the 'avoids' 
>> parameter is not correctly updated 

Re: Cloudstack collab Hackathons

[Koushik Das]

Agree with Marcus here.
If we are planning to rewrite, I think that there should be some discussion 
around the possibility of making it a direct agent like XS/Vmware. If this is 
possible then installing the KVM agent on individual hosts will be eliminated.


On 17-Oct-2013, at 8:49 PM, Marcus Sorensen  wrote:

> I'm not at all against it, I just haven't heard anyone give any reason
> as to why.  Keep in mind that we'd essentially be asking anyone who
> has written code for the agent to re-do their work (midonet, vxlan,
> storage plugins).  My impression is that people just like the 'feel'
> of it being in Python, and for good reason, but that ignores the fact
> that 1) we've already done the work, and 2) features still require
> java knowledge since the agent doesn't do anything the mgmt server
> doesn't ask for.  Without anyone explaining why, it just sort of feels
> like rearranging deck chairs on a boat with serious leaks going on
> below deck. Worse, people brought their own chairs, and we threw them
> overboard because they're now the wrong color.
> 
> On Wed, Oct 16, 2013 at 6:54 PM, Darren Shepherd
>  wrote:
>> +1 for kvm in python.  I'd like to take it a step further.  I'd like to 
>> create a framework for adding compute and storage with python drivers. The 
>> first implementation should just happen to be libvirt/kvm.  So yeah, I'll be 
>> interested in this.  I'll be landing around 10am so don't know what time 
>> I'll get to the hackathon.
>> 
>> Darren
>> 
>>> On Oct 14, 2013, at 9:29 AM, Marcus Sorensen  wrote:
>>> 
 On Mon, Oct 14, 2013 at 8:22 AM, Sebastien Goasguen  
 wrote:
 
> On Oct 11, 2013, at 4:43 AM, Hugo Trippaers  wrote:
> 
> Hey Guys,
> 
> The CloudStack collaboration conference is right around the corner. The 
> first day of the conference will be dedicated to workshops and a 
> hackathon.
> 
> I'm curious which developers are planning to attend the hackthon and what 
> subjects you are interested in. In Santa Clara we had a short list of 
> some subjects to discuss and some tables and discussions were already 
> prepared in advance. In the upcoming conference we can do the same, so if 
> you have a discussion or project idea that you want to work on at the 
> hackthon let us know with a reply in this thread.
> 
> I'm also curious if there are any aspiring developers that would like to 
> have a sort of introduction into cloudstack development during the 
> hackathon.
> 
> If you have any other ideas, just shout.
> 
> Cheers,
> 
> Hugo
 
 I am adding couple topics that I would like to see:
 
 -API interfaces (AWS refactor, GCE, OCCI&CIMI standard): Discuss the state 
 of our interfaces, plans for future, needs etc. AWS interface might need a 
 refactor, GCE is a new interface, OCCI is a standard and Isaac Chiang has 
 developed an interface. We are missing a CIMI interface.
 
 -DOCs: We are having lots of talks about docs, they have been split in a 
 separate repo, we need to discuss format, release life cycle, format etc.
 
 -KVM agent: There has been discussions/wishes to re-write the KVM agent in 
 something else than Java. Review architecture, define a plan, find 
 developers :)
>>> 
>>> What? First I've heard of it!  I'm not sure how I feel about that. On
>>> one side, it seems reasonable to do it in something like python and
>>> remove the java dependency on the KVM host. On the other hand, there's
>>> a lot of technical debt in what's been built already, while it would
>>> probably be almost trivial to set up a basic working agent, it seems
>>> like a significant amount of work to transfer all of the
>>> functionality, special code that works around libvirt bugs, etc. Not
>>> to mention agent plugins that have already had a significant amount of
>>> effort put into them. On top of that, I'm not sure there's a whole lot
>>> of value if the motive is to attract non-java guys or admins, when the
>>> agent's features rely on what the mgmt server can do (new
>>> features/capabilities would require java code anyway, or at the very
>>> least coordinated effort between multiple devs who want the same
>>> feature).
>>> 
 
 -Ecosystem: The are lots of tools in the cloud ecosystem, we should talk 
 about docker, ansible, cloud foundry/bosh…etc.and define a plan to have 
 great cloudstack support in all of those.
 
 -sebastien
 
 

Re: Possible bug in DeploymentPlanner?

[Koushik Das]

Prachi,

I am planning to add the following code in findSuitablePoolsForVolumes() 
method. If the VM has a local disk and the cluster doesn't have a local pool 
then the cluster will be added to avoid set. Let me know if you see any issues 
with this.

if (useLocalStorage) {
List allPoolsInCluster = 
_storagePoolDao.findPoolsByTags(plan.getDataCenterId(), plan.getPodId(), 
plan.getClusterId(), null);
boolean localStoragePoolExists = false;
for (StoragePoolVO pool : allPoolsInCluster) {
if (pool.isLocal()) {
localStoragePoolExists = true;
break;
}
}
if (!localStoragePoolExists) {
avoid.addCluster(plan.getClusterId());
}
}

-Koushik

On 17-Oct-2013, at 3:21 AM, Prachi Damle 
mailto:prachi.da...@citrix.com>> wrote:



-Original Message-
From: Koushik Das [mailto:koushik@citrix.com<http://citrix.com>]
Sent: Wednesday, October 16, 2013 5:21 AM
To: mailto:dev@cloudstack.apache.org>>
Subject: Re: Possible bug in DeploymentPlanner?


On 16-Oct-2013, at 3:12 AM, Prachi Damle 
mailto:prachi.da...@citrix.com>> wrote:


-Original Message-
From: Koushik Das [mailto:koushik@citrix.com<http://citrix.com>]
Sent: Tuesday, October 15, 2013 11:43 AM
To: mailto:dev@cloudstack.apache.org>>
Subject: Re: Possible bug in DeploymentPlanner?


Thanks for the explanation Prachi.

Here is one issue I see with what you explained below. If an allocator is not 
suppose to handle a particular scenario how should it deal with the avoid set. 
Should it put all available pools in the avoid set. In that case subsequent 
allocators won't get a chance to do anything as all pools are in avoid set. If 
more than one allocator can operate on a particular pool then the situation 
becomes tricky.

To give an example, if there is a request for volume on shared storage and 
first allocator to get called is the local allocator. Since it is not going to 
handle this case it will return empty/null list. Now should it put all the 
other shared pools in avoid set or only the local pools in avoid set? Similarly 
if the request is for a local volume and the request first goes to zone or 
cluster-wide storage allocator what should be there in the avoid set?


[Prachi] I see the bug you are thinking about - deploymentPlanningManager :: 
canAvoidCluster  is only checking the shared storages and thus does not put the 
cluster in avoid set in case the local storage is not a match for the host.

I think the storage allocators should put the resources not considered, in 
avoid set, that are within their scope. Also they should do so only when they 
are supposed to handle the request. Thus local allocator sees only local pools, 
so it should place them into avoid set if not considered and only when this 
allocator is supposed to handle the scenario. While the zone-wide/cluster-wide 
should set those within their scope.
Also, the allocators have a defined order in which they get invoked and we need 
to maintain the order defined in the componentContext.xml

Now to solve the bug, the deploymentPlanningManager :: canAvoidCluster  needs 
to consider which scenario applies for the given vmprofile - i.e whether its 
local storage or shared to correctly figure out if cluster can be avoided by 
considering applicable pools only.
Does this work fine for your scenario?


[Koushik] Not sure if canAvoidCluster() is the right place. Shared and local 
pools can belong to the same cluster, so the cluster cannot be put in avoid 
set. Only the pools needs to be selectively added to avoid set.

[Prachi] Allocators add  the resources to avoid set and then DPM can figure out 
if a cluster is done searching looking at the avoid set, so that the planner 
need not choose that cluster on next try.
So two changes are needed: Storage Allocators should set resources in avoid set 
within their scope and DPM should  check if a cluster is done accordingly.
Can you let me know the specific bug you want to change allocators for? I will 
add the above change in a separate ticket if already not done for your bug.


On 15-Oct-2013, at 11:31 PM, Prachi Damle 
mailto:prachi.da...@citrix.com>>
wrote:

Koushik,

The deployment planning process is divided between DeploymentPlanners and 
Allocators. The planners are supposed to feed a list of clusters the allocators 
should look into to find a potential destination. While the allocators should 
provide a avoid set back to the planners consisting of any resource not 
considered.

Reasoning how the planners work:
Planners can set/reset clusters into avoid set depending on the heuristics they 
implement and the order in which they want the clusters to be traversed.
When all options of the planner are exhausted they should return an empty 
cluster list halting

Re: Possible bug in DeploymentPlanner?

[Koushik Das]

On 17-Oct-2013, at 11:29 PM, Prachi Damle 
 wrote:

> Koushik,
> 
> I don't think you should add this check before calling allocators. It is the 
> allocators output that should tell that local storage pools were not found. 
> For your case where you need to put cluster in avoid set when no local pool 
> is present:
> a) Only local storage allocator should get invoked, all other allocators need 
> to have a check at the start saying they can process only 'shared' storage 
> request - This will make sure you do not get any pools from any other 
> allocator for your local storage request.

[Koushik] I made the changes for this and after this the planner bug got 
uncovered where it went in a infinite loop trying to deploy VM with local disk 
when no local pool is available.
 
> b) canAvoidCluster() need to be changed to compare only 'local' or 'shared' 
> pool set to the avoid output of the allocators to see if all pools are in 
> avoid set - Or if there are no pools then  directly avoid the cluster.

[Koushik] Ok. I will make the necessary changes for this but this closely ties 
the allocators and the assumption in canAvoidCluster(). The scenario I am 
seeing is the latter where there is no pools in the allocator avoid set. So as 
you suggested in this case as well the cluster needs to be in avoid set.

> 
> Prachi
> 
> -Original Message-
> From: Koushik Das [mailto:koushik@citrix.com] 
> Sent: Thursday, October 17, 2013 9:23 AM
> To: 
> Subject: Re: Possible bug in DeploymentPlanner?
> 
> Prachi,
> 
> I am planning to add the following code in findSuitablePoolsForVolumes() 
> method. If the VM has a local disk and the cluster doesn't have a local pool 
> then the cluster will be added to avoid set. Let me know if you see any 
> issues with this.
> 
>if (useLocalStorage) {
>List allPoolsInCluster = 
> _storagePoolDao.findPoolsByTags(plan.getDataCenterId(), plan.getPodId(), 
> plan.getClusterId(), null);
>boolean localStoragePoolExists = false;
>for (StoragePoolVO pool : allPoolsInCluster) {
>if (pool.isLocal()) {
>localStoragePoolExists = true;
>break;
>}
>}
>if (!localStoragePoolExists) {
>avoid.addCluster(plan.getClusterId());
>    }
>    }
> 
> -Koushik
> 
> On 17-Oct-2013, at 3:21 AM, Prachi Damle 
> mailto:prachi.da...@citrix.com>> wrote:
> 
> 
> 
> -Original Message-
> From: Koushik Das [mailto:koushik@citrix.com<http://citrix.com>]
> Sent: Wednesday, October 16, 2013 5:21 AM
> To: mailto:dev@cloudstack.apache.org>>
> Subject: Re: Possible bug in DeploymentPlanner?
> 
> 
> On 16-Oct-2013, at 3:12 AM, Prachi Damle 
> mailto:prachi.da...@citrix.com>> wrote:
> 
> 
> -Original Message-
> From: Koushik Das [mailto:koushik@citrix.com<http://citrix.com>]
> Sent: Tuesday, October 15, 2013 11:43 AM
> To: mailto:dev@cloudstack.apache.org>>
> Subject: Re: Possible bug in DeploymentPlanner?
> 
> 
> Thanks for the explanation Prachi.
> 
> Here is one issue I see with what you explained below. If an allocator is not 
> suppose to handle a particular scenario how should it deal with the avoid 
> set. Should it put all available pools in the avoid set. In that case 
> subsequent allocators won't get a chance to do anything as all pools are in 
> avoid set. If more than one allocator can operate on a particular pool then 
> the situation becomes tricky.
> 
> To give an example, if there is a request for volume on shared storage and 
> first allocator to get called is the local allocator. Since it is not going 
> to handle this case it will return empty/null list. Now should it put all the 
> other shared pools in avoid set or only the local pools in avoid set? 
> Similarly if the request is for a local volume and the request first goes to 
> zone or cluster-wide storage allocator what should be there in the avoid set?
> 
> 
> [Prachi] I see the bug you are thinking about - deploymentPlanningManager :: 
> canAvoidCluster  is only checking the shared storages and thus does not put 
> the cluster in avoid set in case the local storage is not a match for the 
> host.
> 
> I think the storage allocators should put the resources not considered, in 
> avoid set, that are within their scope. Also they should do so only when they 
> are supposed to handle the request. Thus local allocator sees only local 
> pools, so it should place them into avoid set if not considered and only when 
> this allocator is suppo

Re: Review Request 14305: CLOUDSTACK-4493: registerSSHKeyPair API doc contains wrong API response (private key)

[Koushik Das]

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



api/src/org/apache/cloudstack/api/response/SSHKeyPairResponse.java
<https://reviews.apache.org/r/14305/#comment52933>

Why this is changed to protected?



api/src/org/apache/cloudstack/api/response/SSHKeyPairResponse.java
<https://reviews.apache.org/r/14305/#comment52934>

Protected? This is not required


- Koushik Das


On Oct. 18, 2013, 12:43 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14305/
> ---
> 
> (Updated Oct. 18, 2013, 12:43 p.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-4493
> https://issues.apache.org/jira/browse/CLOUDSTACK-4493
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4493:  registerSSHKeyPair API doc contains wrong API response 
> (private key) 
> Changing the response object of register and list ssh keypairs APIs
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/ssh/CreateSSHKeyPairCmd.java 
> 56bec7e 
>   api/src/org/apache/cloudstack/api/response/CreateSSHKeyPairResponse.java 
> PRE-CREATION 
>   api/src/org/apache/cloudstack/api/response/SSHKeyPairResponse.java 2791853 
> 
> Diff: https://reviews.apache.org/r/14305/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 14305: CLOUDSTACK-4493: registerSSHKeyPair API doc contains wrong API response (private key)

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On Oct. 21, 2013, 5:14 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14305/
> ---
> 
> (Updated Oct. 21, 2013, 5:14 a.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-4493
> https://issues.apache.org/jira/browse/CLOUDSTACK-4493
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4493:  registerSSHKeyPair API doc contains wrong API response 
> (private key) 
> Changing the response object of register and list ssh keypairs APIs
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/ssh/CreateSSHKeyPairCmd.java 
> 56bec7e 
>   api/src/org/apache/cloudstack/api/response/CreateSSHKeyPairResponse.java 
> PRE-CREATION 
>   api/src/org/apache/cloudstack/api/response/SSHKeyPairResponse.java 2791853 
> 
> Diff: https://reviews.apache.org/r/14305/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: [ANNOUNCE] New PMC member: Animesh Chaturvedi

[Koushik Das]

Congrats Animesh!

On 22-Oct-2013, at 12:31 AM, Chip Childers  wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked
> Animesh Chaturvedi to join the PMC and we are pleased to announce that they
> have accepted.
> 
> Join me in congratulating Animesh!
> 
> -The CloudStack PMC

Command sequence logic in agent code

[Koushik Das]

I was looking at the command sequencing logic in the agent code.

Each agent maintains a sequence that gets initialised based on following logic

private static final Random s_rand = new Random(System.currentTimeMillis());
_nextSequence = s_rand.nextInt(Short.MAX_VALUE) << 48;

For every command that gets processed by the agent the sequence is incremented 
by 1. If commands are to be executed in sequence then they are queued up based 
on this sequence

protected synchronized void addRequest(Request req) {
int index = findRequest(req);
assert (index < 0) : "How can we get index again? " + index + ":" + 
req.toString();
_requests.add(-index - 1, req);
}

The above works fine in case of a single MS scenario. In case of a clustered MS 
setup things change slightly.

The command can originate at any MS and based on the ownership of the agent, it 
gets forwarded to the correct MS which then handles the command. Now command 
sequences are local to individual agents in MS. In this case the originating MS 
agent tags the request with a sequence. This gets forwarded to the owning MS 
and based on if 'executedInSequence' flag is set, gets added to the list based 
on the sequence number. Now here lies the problem, commands are not inserted in 
the order in which they arrive but based on the sequence number. In case of a 
forwarded command the sequence is different from the local sequence. If the 
starting sequence of forwarded commands is much less than that of the locally 
generated commands then there is a possibility of local commands getting 
starved if there is a steady arrival of forwarded commands. Similarly it can 
also happen the other way round. Also if the the starting sequence for a agent 
in local and peer MS is not spread far apart then there may be overlaps and a 
new request will override the old one.

Not sure if anyone encountered any issues due to this. The correct way looks 
like to implement the queue model rather than doing a add based on the above 
code.

Comments?

-Koushik

Re: [ANNOUNCE] New Committer: Talluri, Srikanteswara

[Koushik Das]

Congrats Talluri!

On 23-Oct-2013, at 4:07 PM, Prasanna Santhanam  wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked 
> Srikanteswara
> Talluri to become a committer and we are pleased to announce that they have
> accepted.
> 
> Being a committer allows many contributors to contribute more autonomously. 
> For
> developers, it makes it easier to submit changes and eliminates the need to
> have contributions reviewed via the patch submission process. Whether
> contributions are development-related or otherwise, it is a recognition of a
> contributor's participation in the project and commitment to the project and
> the Apache Way.
> 
> Please join me in congratulating Talluri!
> 
> --
> Prasanna.,
> on behalf of the Apache CloudStack PMC
> 
> 
> Powered by BigRock.com
> 

Re: [ANNOUNCE] New Committer: Krishnan, Sowmya

[Koushik Das]

Congrats Sowmya!

On 23-Oct-2013, at 4:16 PM, Prasanna Santhanam  wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked Sowmya
> Krishnan to become a committer and we are pleased to announce that they have
> accepted.
> 
> Being a committer allows many contributors to contribute more autonomously. 
> For
> developers, it makes it easier to submit changes and eliminates the need to
> have contributions reviewed via the patch submission process. Whether
> contributions are development-related or otherwise, it is a recognition of a
> contributor's participation in the project and commitment to the project and
> the Apache Way.
> 
> Please join me in congratulating Sowmya!
> 
> --
> Prasanna.,
> on behalf of the Apache CloudStack PMC
> 
> 
> Powered by BigRock.com
> 

Re: [ANNOUNCE] New Committer: Shilamkar, Girish

[Koushik Das]

Congrats Girish!

On 23-Oct-2013, at 4:08 PM, Prasanna Santhanam  wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked Girish
> Shilamkar to become a committer and we are pleased to announce that they have
> accepted.
> 
> Being a committer allows many contributors to contribute more autonomously. 
> For
> developers, it makes it easier to submit changes and eliminates the need to
> have contributions reviewed via the patch submission process. Whether
> contributions are development-related or otherwise, it is a recognition of a
> contributor's participation in the project and commitment to the project and
> the Apache Way.
> 
> Please join me in congratulating Girish!
> 
> --
> Prasanna.,
> on behalf of the Apache CloudStack PMC
> 
> 
> Powered by BigRock.com
> 

Re: Command sequence logic in agent code

[Koushik Das]

Created https://issues.apache.org/jira/browse/CLOUDSTACK-4944 to track this 
issue.

Alex, Any reason for adding requests based on sequence and not doing FIFO? Do 
you see any issues if request always gets added to the end of the queue?


On 23-Oct-2013, at 6:26 PM, Koushik Das  wrote:

> I was looking at the command sequencing logic in the agent code.
> 
> Each agent maintains a sequence that gets initialised based on following logic
> 
>private static final Random s_rand = new 
> Random(System.currentTimeMillis());
>_nextSequence = s_rand.nextInt(Short.MAX_VALUE) << 48;
> 
> For every command that gets processed by the agent the sequence is 
> incremented by 1. If commands are to be executed in sequence then they are 
> queued up based on this sequence
> 
>protected synchronized void addRequest(Request req) {
>int index = findRequest(req);
>assert (index < 0) : "How can we get index again? " + index + ":" + 
> req.toString();
>_requests.add(-index - 1, req);
>}
> 
> The above works fine in case of a single MS scenario. In case of a clustered 
> MS setup things change slightly.
> 
> The command can originate at any MS and based on the ownership of the agent, 
> it gets forwarded to the correct MS which then handles the command. Now 
> command sequences are local to individual agents in MS. In this case the 
> originating MS agent tags the request with a sequence. This gets forwarded to 
> the owning MS and based on if 'executedInSequence' flag is set, gets added to 
> the list based on the sequence number. Now here lies the problem, commands 
> are not inserted in the order in which they arrive but based on the sequence 
> number. In case of a forwarded command the sequence is different from the 
> local sequence. If the starting sequence of forwarded commands is much less 
> than that of the locally generated commands then there is a possibility of 
> local commands getting starved if there is a steady arrival of forwarded 
> commands. Similarly it can also happen the other way round. Also if the the 
> starting sequence for a agent in local and peer MS is not spread far apart 
> then there may be overlaps and a new request will override the old one.
> 
> Not sure if anyone encountered any issues due to this. The correct way looks 
> like to implement the queue model rather than doing a add based on the above 
> code.
> 
> Comments?
> 
> -Koushik
> 
> 
> 
> 
> 

Re: Command sequence logic in agent code

[Koushik Das]

I came across some MS logs which showed that commands originating locally are 
getting starved (timed out and then cancelled since it never got a chance to 
execute) and the forwarded commands from another MS gets executed even though 
the local commands got scheduled earlier. A huge number of forwarded commands 
arrived in a quick succession. The sequence numbers of the forwarded commands 
were much less than the local commands and so the forwarded commands always got 
added ahead of the local ones.
  
On 24-Oct-2013, at 9:34 PM, Alex Huang  wrote:

> I only took a quick look here.  I think when commands originate from the 
> management server, it doesn't go through this code.  This is if the command 
> came from the agent which doesn't matter if there's multiple management 
> servers.
> 
> --Alex
> 
>> -----Original Message-
>> From: Koushik Das
>> Sent: Thursday, October 24, 2013 2:11 AM
>> To: 
>> Cc: Alex Huang
>> Subject: Re: Command sequence logic in agent code
>> 
>> Created https://issues.apache.org/jira/browse/CLOUDSTACK-4944 to track
>> this issue.
>> 
>> Alex, Any reason for adding requests based on sequence and not doing FIFO?
>> Do you see any issues if request always gets added to the end of the queue?
>> 
>> 
>> On 23-Oct-2013, at 6:26 PM, Koushik Das  wrote:
>> 
>>> I was looking at the command sequencing logic in the agent code.
>>> 
>>> Each agent maintains a sequence that gets initialised based on following
>> logic
>>> 
>>>   private static final Random s_rand = new
>> Random(System.currentTimeMillis());
>>>   _nextSequence = s_rand.nextInt(Short.MAX_VALUE) << 48;
>>> 
>>> For every command that gets processed by the agent the sequence is
>> incremented by 1. If commands are to be executed in sequence then they
>> are queued up based on this sequence
>>> 
>>>   protected synchronized void addRequest(Request req) {
>>>   int index = findRequest(req);
>>>   assert (index < 0) : "How can we get index again? " + index + ":" +
>> req.toString();
>>>   _requests.add(-index - 1, req);
>>>   }
>>> 
>>> The above works fine in case of a single MS scenario. In case of a clustered
>> MS setup things change slightly.
>>> 
>>> The command can originate at any MS and based on the ownership of the
>> agent, it gets forwarded to the correct MS which then handles the command.
>> Now command sequences are local to individual agents in MS. In this case
>> the originating MS agent tags the request with a sequence. This gets
>> forwarded to the owning MS and based on if 'executedInSequence' flag is
>> set, gets added to the list based on the sequence number. Now here lies the
>> problem, commands are not inserted in the order in which they arrive but
>> based on the sequence number. In case of a forwarded command the
>> sequence is different from the local sequence. If the starting sequence of
>> forwarded commands is much less than that of the locally generated
>> commands then there is a possibility of local commands getting starved if
>> there is a steady arrival of forwarded commands. Similarly it can also happen
>> the other way round. Also if the the starting sequence for a agent in local 
>> and
>> peer MS is not spread far apart then there may be overlaps and a new
>> request will override the old one.
>>> 
>>> Not sure if anyone encountered any issues due to this. The correct way
>> looks like to implement the queue model rather than doing a add based on
>> the above code.
>>> 
>>> Comments?
>>> 
>>> -Koushik
>>> 
>>> 
>>> 
>>> 
>>> 
> 

Review Request 15080: CLOUDSTACK-4855: Throttle based on the # of outstanding requests to the directly managed HV host (direct agents)

[Koushik Das]

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

Review request for cloudstack, Alex Huang, Chiradeep Vittal, and Darren 
Shepherd.


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


Repository: cloudstack-git


Description
---

Cloudstack sends requests to directly managed HV hosts (direct agents) using 
the direct agent thread pool. The size of the pool is determined by global 
config direct.agent.pool.size defaulted to 500.

Currently there is no restriction on the number of threads a direct agent can 
use from this shared thread pool to send requests to the host. This is fine as 
long as the host is responding to requests
in a reasonable amount of time. But if there is a considerable delay in getting 
response, the thread remain blocked for that much time. As more commands are 
send to the slow host threads keep getting
blocked. This can eventually lead to a situation where requests to healthy 
hosts cannot be processed as there are not enough free threads.

The problem being addressed here is to localize the impact of few bad hosts, so 
that entire management server is not affected.

One such way is to throttle based on the # of outstanding requests on per host 
basis. The outstanding requests to a host will be a % of direct agent pool 
size. This is configurable based on
direct.agent.thread.cap. This will ensure that the impacted host will be bound 
by a upper cap on the number of threads it can use to process requests and not 
the entire pool.


Note: The reason for checking the outstanding request count in the Task.run() 
method is to take into account cron jobs that gets scheduled at agent startup.


Diffs
-

  engine/orchestration/src/com/cloud/agent/manager/AgentAttache.java ff35255 
  engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java 
3e684cc 
  engine/orchestration/src/com/cloud/agent/manager/DirectAgentAttache.java 
7d3f765 

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


Testing
---

Verified by tweaking the per agent upper cap to a value of 1 and checked that 
the requests are getting scheduled but the executor thread simply bails out.


Thanks,

Koushik Das

Re: Review Request 15173: Dynamic compute offering.

[Koushik Das]

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



api/src/org/apache/cloudstack/api/command/admin/offering/CreateServiceOfferingCmd.java
<https://reviews.apache.org/r/15173/#comment54664>

Is the customized flag required? Since you have made cpu/memory as optional.




api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java
<https://reviews.apache.org/r/15173/#comment54666>

Please keep the cpu related parameters together for better readability



api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java
<https://reviews.apache.org/r/15173/#comment54665>

typo feild



api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java
<https://reviews.apache.org/r/15173/#comment54667>

Please follow identical naming convention. rootdisksize -> rootDiskSize



api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java
<https://reviews.apache.org/r/15173/#comment54668>

Where is the check to see if the service offering is dynamic or not? If a 
static service offering is specified and also the values of cpu/memory is 
provided it should fail with exception



api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java
<https://reviews.apache.org/r/15173/#comment54672>

For root disk size should there be any validation based on template size?



engine/api/src/org/apache/cloudstack/engine/service/api/OrchestrationService.java
<https://reviews.apache.org/r/15173/#comment54669>

Can we have a consistent naming for the parameters?



engine/components-api/src/com/cloud/configuration/ConfigurationManager.java
<https://reviews.apache.org/r/15173/#comment54670>

Why is vmId manadatory here?



engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
<https://reviews.apache.org/r/15173/#comment54671>

Isn't root disk size optional for deploy vm using template? From this 
change looks like mandatory.



engine/schema/src/com/cloud/service/ServiceOfferingVO.java
<https://reviews.apache.org/r/15173/#comment54673>

Why do you need this field? If any of cpu/memory is not specified then 
'isDynamic' can be inferred.



engine/schema/src/com/cloud/service/ServiceOfferingVO.java
<https://reviews.apache.org/r/15173/#comment54675>

Again this is not required



engine/schema/src/com/cloud/service/dao/ServiceOfferingDaoImpl.java
<https://reviews.apache.org/r/15173/#comment54674>

ordering of parameter is not correct. optional parameters should be at the 
end


- Koushik Das


On Nov. 1, 2013, 5:40 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15173/
> -------
> 
> (Updated Nov. 1, 2013, 5:40 a.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-4738
> https://issues.apache.org/jira/browse/CLOUDSTACK-4738
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4738
> Dynamic compute Offering.
> 
> Still need to test this. Facing some auto wiring problems when 
> UsageEventUtils bean is created. 
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/ServiceOffering.java 9f7bf8e 
>   api/src/com/cloud/vm/UserVmService.java 0b142e8 
>   api/src/org/apache/cloudstack/api/ApiConstants.java b1bfcfb 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateServiceOfferingCmd.java
>  decac29 
>   api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java 8a6cea7 
>   
> engine/api/src/org/apache/cloudstack/engine/orchestration/service/VolumeOrchestrationService.java
>  a773ac4 
>   
> engine/api/src/org/apache/cloudstack/engine/service/api/OrchestrationService.java
>  64ef063 
>   engine/components-api/src/com/cloud/configuration/ConfigurationManager.java 
> 03a549f 
>   engine/components-api/src/com/cloud/event/UsageEventUtils.java b44ed32 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> b74b4c5 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/CloudOrchestrator.java
>  2fd10b6 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  0821c81 
>   engine/schema/src/com/cloud/event/UsageEventDetailsVO.java PRE-CREATION 
>   engine/schema/src/com/cloud/event/dao/UsageEventDetailsDao.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/event/dao/UsageEventDetailsDaoImpl.java

Re: Review Request 15018: CLOUDSTACK-4908: CPU socket count of host

[Koushik Das]

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



api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java
<https://reviews.apache.org/r/15018/#comment54677>

Why is this change required for CPU sockets?



core/src/com/cloud/agent/api/StartupRoutingCommand.java
<https://reviews.apache.org/r/15018/#comment54678>

Why Integer and not int?



plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
<https://reviews.apache.org/r/15018/#comment54679>

Why Integer? Can this be null?



server/src/com/cloud/api/query/QueryManagerImpl.java
<https://reviews.apache.org/r/15018/#comment54680>

This change doesn't look related



setup/db/db/schema-421to430.sql
<https://reviews.apache.org/r/15018/#comment54681>

Simply drop and recreate the view


- Koushik Das


On Oct. 31, 2013, 10:14 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15018/
> ---
> 
> (Updated Oct. 31, 2013, 10:14 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-4908
> https://issues.apache.org/jira/browse/CLOUDSTACK-4908
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4908: CPU socket count of host 
> Adding cpu socket count of the host in hostresponse
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/host/Host.java 17b0ba8 
>   api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java 
> 95b9ac3 
>   api/src/org/apache/cloudstack/api/response/HostResponse.java 687687d 
>   core/src/com/cloud/agent/api/StartupRoutingCommand.java d52666b 
>   core/test/org/apache/cloudstack/api/agent/test/CheckOnHostCommandTest.java 
> 1b68276 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/datacenter/entity/api/db/EngineHostVO.java
>  249c2db 
>   engine/schema/src/com/cloud/host/HostVO.java c814b94 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  8d3a0e9 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  423abe6 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  3323a15 
>   server/src/com/cloud/api/query/QueryManagerImpl.java 51ee249 
>   server/src/com/cloud/api/query/dao/HostJoinDaoImpl.java 97f8bf9 
>   server/src/com/cloud/api/query/vo/HostJoinVO.java fbc59cd 
>   server/src/com/cloud/resource/ResourceManagerImpl.java e9d5193 
>   setup/db/db/schema-421to430.sql 803f1d9 
>   vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java 108a3ec 
>   vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHost.java 
> f7288f1 
>   
> vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHostResourceSummary.java
>  fa11dc3 
> 
> Diff: https://reviews.apache.org/r/15018/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 15018: CLOUDSTACK-4908: CPU socket count of host

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On Nov. 5, 2013, 10:34 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15018/
> ---
> 
> (Updated Nov. 5, 2013, 10:34 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-4908
> https://issues.apache.org/jira/browse/CLOUDSTACK-4908
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4908: CPU socket count of host 
> Adding cpu socket count of the host in hostresponse
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/host/Host.java 17b0ba8 
>   api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java 
> 95b9ac3 
>   api/src/org/apache/cloudstack/api/response/HostResponse.java 687687d 
>   core/src/com/cloud/agent/api/StartupRoutingCommand.java d52666b 
>   core/test/org/apache/cloudstack/api/agent/test/CheckOnHostCommandTest.java 
> 1b68276 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/datacenter/entity/api/db/EngineHostVO.java
>  249c2db 
>   engine/schema/src/com/cloud/host/HostVO.java c814b94 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  e3f60f2 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  f6f84f6 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  ccb27ea 
>   server/src/com/cloud/api/query/QueryManagerImpl.java 735bbc9 
>   server/src/com/cloud/api/query/dao/HostJoinDaoImpl.java 97f8bf9 
>   server/src/com/cloud/api/query/vo/HostJoinVO.java fbc59cd 
>   server/src/com/cloud/resource/ResourceManagerImpl.java e9d5193 
>   setup/db/db/schema-421to430.sql 1c99e3f 
>   vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java 108a3ec 
>   vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHost.java 
> f7288f1 
>   
> vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHostResourceSummary.java
>  fa11dc3 
> 
> Diff: https://reviews.apache.org/r/15018/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 15173: Dynamic compute offering.

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On Nov. 7, 2013, 6:24 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15173/
> ---
> 
> (Updated Nov. 7, 2013, 6:24 a.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-4738
> https://issues.apache.org/jira/browse/CLOUDSTACK-4738
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4738
> Dynamic compute Offering.
> 
> Still need to test this. Facing some auto wiring problems when 
> UsageEventUtils bean is created. 
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/ServiceOffering.java 9f7bf8e 
>   api/src/com/cloud/vm/UserVmService.java 0b142e8 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 8ab6c5e 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateServiceOfferingCmd.java
>  decac29 
>   api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java 8a6cea7 
>   
> engine/api/src/org/apache/cloudstack/engine/orchestration/service/VolumeOrchestrationService.java
>  a773ac4 
>   
> engine/api/src/org/apache/cloudstack/engine/service/api/OrchestrationService.java
>  64ef063 
>   engine/components-api/src/com/cloud/event/UsageEventUtils.java b44ed32 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> b74b4c5 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/CloudOrchestrator.java
>  2fd10b6 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  ab626c8 
>   
> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
>  98ef018 
>   engine/schema/src/com/cloud/event/UsageEventDetailsVO.java PRE-CREATION 
>   engine/schema/src/com/cloud/event/dao/UsageEventDao.java 01979e1 
>   engine/schema/src/com/cloud/event/dao/UsageEventDaoImpl.java 4333903 
>   engine/schema/src/com/cloud/event/dao/UsageEventDetailsDao.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/event/dao/UsageEventDetailsDaoImpl.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/service/ServiceOfferingVO.java 9a262c5 
>   engine/schema/src/com/cloud/service/dao/ServiceOfferingDao.java 7da7208 
>   engine/schema/src/com/cloud/service/dao/ServiceOfferingDaoImpl.java f807f0d 
>   
> plugins/deployment-planners/implicit-dedication/test/org/apache/cloudstack/implicitplanner/ImplicitPlannerTest.java
>  f1fa71c 
>   
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetalPxeManagerImpl.java
>  ef6ec31 
>   
> server/src/com/cloud/agent/manager/allocator/impl/UserConcentratedAllocator.java
>  0da2c92 
>   server/src/com/cloud/api/query/QueryManagerImpl.java f34e60e 
>   server/src/com/cloud/capacity/CapacityManagerImpl.java 1c5f189 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java a31d06f 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> 9b35a4b 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 9e69962 
>   server/test/com/cloud/capacity/CapacityManagerTest.java 3faa32f 
>   server/test/com/cloud/vm/UserVmManagerTest.java df676d3 
>   
> server/test/org/apache/cloudstack/networkoffering/CreateNetworkOfferingTest.java
>  f2ebf67 
>   server/test/org/apache/cloudstack/service/ServiceOfferingVOTest.java 
> PRE-CREATION 
>   server/test/resources/createNetworkOffering.xml 9d684ba 
>   setup/db/db/schema-421to430.sql 980650d 
> 
> Diff: https://reviews.apache.org/r/15173/diff/
> 
> 
> Testing
> ---
> 
> Tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 15173: Dynamic compute offering.

[Koushik Das]

> On Nov. 7, 2013, 7:17 a.m., Koushik Das wrote:
> > Ship It!

commit 7095ea2b5e497620c8c879517565046e3b46e493


- Koushik


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


On Nov. 7, 2013, 6:24 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15173/
> ---
> 
> (Updated Nov. 7, 2013, 6:24 a.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-4738
> https://issues.apache.org/jira/browse/CLOUDSTACK-4738
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4738
> Dynamic compute Offering.
> 
> Still need to test this. Facing some auto wiring problems when 
> UsageEventUtils bean is created. 
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/ServiceOffering.java 9f7bf8e 
>   api/src/com/cloud/vm/UserVmService.java 0b142e8 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 8ab6c5e 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateServiceOfferingCmd.java
>  decac29 
>   api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java 8a6cea7 
>   
> engine/api/src/org/apache/cloudstack/engine/orchestration/service/VolumeOrchestrationService.java
>  a773ac4 
>   
> engine/api/src/org/apache/cloudstack/engine/service/api/OrchestrationService.java
>  64ef063 
>   engine/components-api/src/com/cloud/event/UsageEventUtils.java b44ed32 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> b74b4c5 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/CloudOrchestrator.java
>  2fd10b6 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  ab626c8 
>   
> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
>  98ef018 
>   engine/schema/src/com/cloud/event/UsageEventDetailsVO.java PRE-CREATION 
>   engine/schema/src/com/cloud/event/dao/UsageEventDao.java 01979e1 
>   engine/schema/src/com/cloud/event/dao/UsageEventDaoImpl.java 4333903 
>   engine/schema/src/com/cloud/event/dao/UsageEventDetailsDao.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/event/dao/UsageEventDetailsDaoImpl.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/service/ServiceOfferingVO.java 9a262c5 
>   engine/schema/src/com/cloud/service/dao/ServiceOfferingDao.java 7da7208 
>   engine/schema/src/com/cloud/service/dao/ServiceOfferingDaoImpl.java f807f0d 
>   
> plugins/deployment-planners/implicit-dedication/test/org/apache/cloudstack/implicitplanner/ImplicitPlannerTest.java
>  f1fa71c 
>   
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetalPxeManagerImpl.java
>  ef6ec31 
>   
> server/src/com/cloud/agent/manager/allocator/impl/UserConcentratedAllocator.java
>  0da2c92 
>   server/src/com/cloud/api/query/QueryManagerImpl.java f34e60e 
>   server/src/com/cloud/capacity/CapacityManagerImpl.java 1c5f189 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java a31d06f 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> 9b35a4b 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 9e69962 
>   server/test/com/cloud/capacity/CapacityManagerTest.java 3faa32f 
>   server/test/com/cloud/vm/UserVmManagerTest.java df676d3 
>   
> server/test/org/apache/cloudstack/networkoffering/CreateNetworkOfferingTest.java
>  f2ebf67 
>   server/test/org/apache/cloudstack/service/ServiceOfferingVOTest.java 
> PRE-CREATION 
>   server/test/resources/createNetworkOffering.xml 9d684ba 
>   setup/db/db/schema-421to430.sql 980650d 
> 
> Diff: https://reviews.apache.org/r/15173/diff/
> 
> 
> Testing
> ---
> 
> Tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Cloudstack 4.2.0 > migration of local data volume is not allowed

[Koushik Das]

Is your data volume and VM on the same host? If not then the volume cannot be 
attached to the VM in case of a local volume.

-Koushik
 
On 07-Nov-2013, at 4:03 PM, Antonio Petrocelli 
 wrote:

> Hello,
> 
> i've this error when i try to attach a volume to vm:
> 
> "Failed to attach local data volume snap_2599317a-2598-4a91-8dca-f3801ae1f462 
> to VM Test01 as migration of local data volume is not allowed"
> 
> 
> Actual config is on LOCAL storage type.
> 
> Someone know about?
> 
> Thanks!

Re: pool.storage.capacity.disablethreshold global config

[Koushik Das]

>From what I understand, now there is a new interface Configurable that exposes 
>the config parameters. In this case if you look at the 
>CapacityManagerImpl.java, there is a method getCongigKeys() that return the 
>config parameters. During MS startup all these are automatically populated in 
>the db. Looks like pool.storage.capacity.disablethreshold was missed out from 
>the list. Add it in the list and it should be available.

 
On 08-Nov-2013, at 4:14 AM, Alena Prokharchyk  
wrote:

> I've run into the problem in master where I can't deploy the VM due to 
> insufficient capacity:
> 
> 2013-11-07 14:21:20,439 DEBUG [c.c.s.StorageManagerImpl] 
> (Job-Executor-27:ctx-e5d8814d ctx-e5375ad7) Insufficient space on pool: 1 
> since its usage percentage: 4.875950712239125 has crossed the 
> pool.storage.capacity.disablethreshold: 0.85
> 
> But there is no way to change "pool.storage.capacity.disablethreshold" as 
> this parameter is hardcoded in CapacityManager, and you can't change its 
> value.
> 
> Alex, seems you were the last person who modified it. Before we used to keep 
> all capacity thresholds in global config table, can you explain how it works 
> now?
> 
> commit 6e8ca994660afc468530944542e232596e8f1176
> Author: Alex Huang 
> Date:   Tue Aug 27 17:33:24 2013 -0700
> 
>Got all of the config stuff out of the way
> 
> -alena.

Re: Review Request 15348: CLOUDSTACK-5105 Template/ISO download fails cause the object to disappear from UI

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On Nov. 8, 2013, 12:02 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15348/
> ---
> 
> (Updated Nov. 8, 2013, 12:02 p.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-5105
> https://issues.apache.org/jira/browse/CLOUDSTACK-5105
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5105:  Template/ISO download fails cause the object to disappear 
> from UI
> 
> 
> Diffs
> -
> 
>   
> engine/storage/src/org/apache/cloudstack/storage/datastore/ObjectInDataStoreManagerImpl.java
>  652df43 
>   server/src/com/cloud/template/HypervisorTemplateAdapter.java 00e6222 
> 
> Diff: https://reviews.apache.org/r/15348/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 15348: CLOUDSTACK-5105 Template/ISO download fails cause the object to disappear from UI

[Koushik Das]

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

Ship it!


master -> 53b0bf6733d28cb104a231f28f58c7f1dff11742
4.3 -> 6a8ec786ad2a843768c26099e17f89782cd77f75

- Koushik Das


On Nov. 8, 2013, 12:24 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15348/
> ---
> 
> (Updated Nov. 8, 2013, 12:24 p.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-5105
> https://issues.apache.org/jira/browse/CLOUDSTACK-5105
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5105:  Template/ISO download fails cause the object to disappear 
> from UI
> 
> 
> Diffs
> -
> 
>   
> engine/storage/src/org/apache/cloudstack/storage/datastore/ObjectInDataStoreManagerImpl.java
>  652df43 
>   server/src/com/cloud/template/HypervisorTemplateAdapter.java b33a192 
> 
> Diff: https://reviews.apache.org/r/15348/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: SSL and JCE

[Koushik Das]

I see the JCE extensions in jdk 1.7 as well. They are present under 
/jre/lib/security. But still I see a test failure. Is there any 
other configuration that is required?

Running org.apache.cloudstack.network.lb.CertServiceTest
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.456 sec <<< 
FAILURE!

-Koushik

On 12-Nov-2013, at 11:19 AM, Prasanna Santhanam 
 wrote:

> My MacOSX 1.6 jdk seems to have the crypto extensions jce builtin and
> the build+test works. JDK 1.7 install does not have them though.
> 
> The JCE kit seems to carry a BCL which is not ASF friendly [1]. But
> this being part of the Java install and not the project it should be
> okay IMO if we note it in our wiki on building the project.
> 
> As for legal aspects - I found this which might be of some relevance.  
> http://markmail.org/message/evtkc656gewrkruf
> 
> [1] http://www.apache.org/legal/3party.html#transition-examples
> 
> On Mon, Nov 11, 2013 at 10:45:12PM +0100, Laszlo Hornyak wrote:
>> Hi,
>> 
>> That is a good question, I do not know for sure, but this package needs to
>> be signed by oracle, it is not redistributable and has teritorial import
>> restrictions, so it could be problematic :-( I hope it is not. Guys, can
>> someone help us here?
>> 
>> 
>> On Mon, Nov 11, 2013 at 10:21 PM, Syed Ahmed  wrote:
>> 
>>> Hi Laszlo,
>>> 
>>> The CertService uses BouncyCastle for certificate parsing and validation.
>>> The JCE extension provides the API for using BouncyCastle as the provider.
>>> So, JCE is required. I know that BouncyCastle is added in CS. Would it be
>>> possible to add JCE as a dependency too?
>>> 
>>> Thanks,
>>> -Syed
>>> 
>>> 
>>> On 13-11-10 09:55 AM, Laszlo Hornyak wrote:
>>> 
 Hi Sahmed and list,
 
 I ran into some failing tests this weekend related to the patch
 0076307863e9155273d9e4c14282de429388c9e9 apparently jenkins fails for
 the same reason. I did a short investigation and it turned out that in
 order to run the tests correctly, one has to download the sun jce policy
 files and put it in the jdk replacing the original policies.
 
 Questions:
 - Is there a more convenient deployment process? :-) It would be very
 useful for the jenkins environment as well.
 - I gave it a try and patched the oracle jdk 1.7 with the same plugin, it
 did not work. Do you know a way to make it work again with jdk 1.7?
 
 Thank you,
 Laszlo
 
 --
 
 EOF
 
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>> EOF
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 

Re: SSL and JCE

[Koushik Das]

The following tests are failing in my environment even with the JCE extensions.

/* Test7: If no chain is given, the certificate should be self signed. 
Else, uploadShould Fail */
runUploadSslCertNoChain();

/* Test8: Chain is given but does not have root certificate */
runUploadSslCertNoRootCert();

/* Test9: The chain given is not the correct chain for the certificate 
*/
runUploadSslCertBadChain();

/* Test12: Given a certificate signed by a CA and a valid CA chain, 
upload should succeed */
runUploadSslCertWithCAChain();




On 12-Nov-2013, at 11:35 AM, Koushik Das  wrote:

> I see the JCE extensions in jdk 1.7 as well. They are present under 
> /jre/lib/security. But still I see a test failure. Is there any 
> other configuration that is required?
> 
> Running org.apache.cloudstack.network.lb.CertServiceTest
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.456 sec <<< 
> FAILURE!
> 
> -Koushik
> 
> On 12-Nov-2013, at 11:19 AM, Prasanna Santhanam 
> wrote:
> 
>> My MacOSX 1.6 jdk seems to have the crypto extensions jce builtin and
>> the build+test works. JDK 1.7 install does not have them though.
>> 
>> The JCE kit seems to carry a BCL which is not ASF friendly [1]. But
>> this being part of the Java install and not the project it should be
>> okay IMO if we note it in our wiki on building the project.
>> 
>> As for legal aspects - I found this which might be of some relevance.  
>> http://markmail.org/message/evtkc656gewrkruf
>> 
>> [1] http://www.apache.org/legal/3party.html#transition-examples
>> 
>> On Mon, Nov 11, 2013 at 10:45:12PM +0100, Laszlo Hornyak wrote:
>>> Hi,
>>> 
>>> That is a good question, I do not know for sure, but this package needs to
>>> be signed by oracle, it is not redistributable and has teritorial import
>>> restrictions, so it could be problematic :-( I hope it is not. Guys, can
>>> someone help us here?
>>> 
>>> 
>>> On Mon, Nov 11, 2013 at 10:21 PM, Syed Ahmed  wrote:
>>> 
>>>> Hi Laszlo,
>>>> 
>>>> The CertService uses BouncyCastle for certificate parsing and validation.
>>>> The JCE extension provides the API for using BouncyCastle as the provider.
>>>> So, JCE is required. I know that BouncyCastle is added in CS. Would it be
>>>> possible to add JCE as a dependency too?
>>>> 
>>>> Thanks,
>>>> -Syed
>>>> 
>>>> 
>>>> On 13-11-10 09:55 AM, Laszlo Hornyak wrote:
>>>> 
>>>>> Hi Sahmed and list,
>>>>> 
>>>>> I ran into some failing tests this weekend related to the patch
>>>>> 0076307863e9155273d9e4c14282de429388c9e9 apparently jenkins fails for
>>>>> the same reason. I did a short investigation and it turned out that in
>>>>> order to run the tests correctly, one has to download the sun jce policy
>>>>> files and put it in the jdk replacing the original policies.
>>>>> 
>>>>> Questions:
>>>>> - Is there a more convenient deployment process? :-) It would be very
>>>>> useful for the jenkins environment as well.
>>>>> - I gave it a try and patched the oracle jdk 1.7 with the same plugin, it
>>>>> did not work. Do you know a way to make it work again with jdk 1.7?
>>>>> 
>>>>> Thank you,
>>>>> Laszlo
>>>>> 
>>>>> --
>>>>> 
>>>>> EOF
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> 
>>> EOF
>> 
>> -- 
>> Prasanna.,
>> 
>> 
>> Powered by BigRock.com
>> 
> 

Re: New Committer: Sanjeev Neelarapu

[Koushik Das]

Congrats Sanjeev

On 14-Nov-2013, at 11:29 AM, Prasanna Santhanam  wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked Sanjeev
> Neelarapu to become a committer and we are pleased to announce that they have
> accepted.
> 
> Being a committer allows many contributors to contribute more autonomously. 
> For
> developers, it makes it easier to submit changes and eliminates the need to
> have contributions reviewed via the patch submission process. Whether
> contributions are development-related or otherwise, it is a recognition of a
> contributor's participation in the project and commitment to the project and
> the Apache Way.
> 
> Please join me in congratulating Sanjeev!
> 
> --
> Prasanna.,
> on behalf of the Apache CloudStack PMC
> 
> 
> Powered by BigRock.com
> 

Re: Review Request 15507: CLOUDSTACK-4835: Update global configuration test cases failed in master

[Koushik Das]

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



api/src/com/cloud/deploy/DeploymentPlanner.java
<https://reviews.apache.org/r/15507/#comment55923>

Is there any other changes in this file? If not remove it.



framework/config/src/org/apache/cloudstack/framework/config/impl/ConfigDepotImpl.java
<https://reviews.apache.org/r/15507/#comment55924>

this is not required


- Koushik Das


On Nov. 14, 2013, 7:36 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15507/
> ---
> 
> (Updated Nov. 14, 2013, 7:36 a.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-4169, CLOUDSTACK-4835 and CLOUDSTACK-5163
> https://issues.apache.org/jira/browse/CLOUDSTACK-4169
> https://issues.apache.org/jira/browse/CLOUDSTACK-4835
> https://issues.apache.org/jira/browse/CLOUDSTACK-5163
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4835: Update global configuration test cases failed in master 
> Changes made in update/list configuration API to use ConfigDepot
> 
> CLOUDSTACK-4169: Scoped configuraion parameters logic moved to ConfigDepot
> 
> CLOUDSTACK-5163: missing parameters in configuration table
> pool.storage.capacity.disablethreshold, storage.overprovisioning.factor, 
> pool.storage.allocated.capacity.disablethreshold,
> cluster.cpu.allocated.capacity.disablethreshold, 
> cluster.memory.allocated.capacity.disablethreshold
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/deploy/DeploymentClusterPlanner.java ca73267 
>   api/src/com/cloud/deploy/DeploymentPlanner.java 88cfc74 
>   
> framework/config/src/org/apache/cloudstack/framework/config/ConfigDepot.java 
> 2fd6efb 
>   
> framework/config/src/org/apache/cloudstack/framework/config/impl/ConfigDepotImpl.java
>  254e6d2 
>   server/src/com/cloud/capacity/CapacityManagerImpl.java 70491bc 
>   server/src/com/cloud/configuration/Config.java bc805b7 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 82256ca 
>   server/src/com/cloud/deploy/FirstFitPlanner.java 64b1124 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> a088a4a 
>   server/src/com/cloud/server/ConfigurationServerImpl.java 8459ada 
>   
> server/test/org/apache/cloudstack/networkoffering/ChildTestConfiguration.java 
> d7ac3f7 
> 
> Diff: https://reviews.apache.org/r/15507/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 15507: CLOUDSTACK-4835: Update global configuration test cases failed in master

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On Nov. 14, 2013, 9:25 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15507/
> ---
> 
> (Updated Nov. 14, 2013, 9:25 a.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-4169, CLOUDSTACK-4835 and CLOUDSTACK-5163
> https://issues.apache.org/jira/browse/CLOUDSTACK-4169
> https://issues.apache.org/jira/browse/CLOUDSTACK-4835
> https://issues.apache.org/jira/browse/CLOUDSTACK-5163
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4835: Update global configuration test cases failed in master 
> Changes made in update/list configuration API to use ConfigDepot
> 
> CLOUDSTACK-4169: Scoped configuraion parameters logic moved to ConfigDepot
> 
> CLOUDSTACK-5163: missing parameters in configuration table
> pool.storage.capacity.disablethreshold, storage.overprovisioning.factor, 
> pool.storage.allocated.capacity.disablethreshold,
> cluster.cpu.allocated.capacity.disablethreshold, 
> cluster.memory.allocated.capacity.disablethreshold
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/deploy/DeploymentClusterPlanner.java ca73267 
>   
> framework/config/src/org/apache/cloudstack/framework/config/ConfigDepot.java 
> 2fd6efb 
>   
> framework/config/src/org/apache/cloudstack/framework/config/impl/ConfigDepotImpl.java
>  254e6d2 
>   server/src/com/cloud/capacity/CapacityManagerImpl.java 70491bc 
>   server/src/com/cloud/configuration/Config.java bc805b7 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 82256ca 
>   server/src/com/cloud/deploy/FirstFitPlanner.java 64b1124 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> a088a4a 
>   server/src/com/cloud/server/ConfigurationServerImpl.java 8459ada 
>   
> server/test/org/apache/cloudstack/networkoffering/ChildTestConfiguration.java 
> d7ac3f7 
> 
> Diff: https://reviews.apache.org/r/15507/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: bf22f6dfe reverts commit 1762dbbb

[Koushik Das]

I have reverted the same in 4.3 as well

commit f84b729eb01ffc7cae1e210b58f80ff2033ad785
Author: Koushik Das 
Date:   Fri Nov 15 12:59:48 2013 +0530

Revert "CLOUDSTACK-5176:"

This reverts commit f29c7188ba03f1997238d50f8a11857e94fe4b55.

On 15-Nov-2013, at 10:35 AM, Prasanna Santhanam  wrote:

> I've reverted 1762dbbb as it seems to have introduced
> ConfigurationParameterScope which didn't exist causing builds to fail
> on master.
> 
> Thanks,
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 

Re: Review Request: CLOUDSTACK-2543: createipAlias.sh/deleteipAlias.sh won't be copied to XenServer host

[Koushik Das]

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


Changes look good.
I also see a patch file in scripts/vm/hypervisor/xenserver/xcposs. This also 
needs to be fixed for devcloud to work

- Koushik Das


On May 17, 2013, 1:56 p.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11221/
> ---
> 
> (Updated May 17, 2013, 1:56 p.m.)
> 
> 
> Review request for cloudstack, Prasanna Santhanam and Koushik Das.
> 
> 
> Description
> ---
> 
> createipAlias.sh/deleteipAlias.sh won't be copied to XenServer host.
> 
> 1.The directory of the scripts should be ".." rather "../../.." in all the 
> xenser patches file.
> Corrected the path to ".." because the scripts are located at 
> scripts/vm/hypervisor/xenserver/xenserver56/patch 
> b/scripts/vm/hypervisor/xenserver/
> 
> 
> This addresses bug CLOUDSTACK-2543.
> 
> 
> Diffs
> -
> 
>   scripts/vm/hypervisor/xenserver/xcpserver/patch a275df4 
>   scripts/vm/hypervisor/xenserver/xenserver56/patch 5c4673d 
>   scripts/vm/hypervisor/xenserver/xenserver56fp1/patch c7c58b9 
>   scripts/vm/hypervisor/xenserver/xenserver60/patch 26205f2 
> 
> Diff: https://reviews.apache.org/r/11221/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested with xenserver6.1 on master branch.
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

RE: CLOUDSTACK-2554: Yet another blocker?

[Koushik Das]

The problem is that there is no default ctor in XcpServerResource.java. Now the 
default ctor was changed to a non-default one by this commit. Adding a default 
ctor should fix the issue but need to check if there will be any other side 
effects due to the version field introduced.

commit 63630a412fddc92fdc68dc27e12d2a68dd09f1dd
Author: Edison Su 
Date:   Wed May 8 11:40:37 2013 -0700

CLOUDSTACK-1907: Debian Squeeze 6.0 (64-bit) is not experimental any more

-Koushik

> -Original Message-
> From: Prasanna Santhanam [mailto:t...@apache.org]
> Sent: Friday, May 17, 2013 9:35 PM
> To: CloudStack Dev
> Subject: CLOUDSTACK-2554: Yet another blocker?
> 
> This one's filed as Major but I tried the XCP 1.6 hypervisor today on our
> automated test infrastructure and I'm unable to even bring up a zone with
> the XCP hypervisor:
> 
> The error when AgentManager attempts to reconnect to an XCP host is as
> listed in the bug. Happy to provide any more logs:
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-2554
> 
> To me this seems like another blocker.
> 
> --
> Prasanna.,
> 
> 
> Powered by BigRock.com

Re: Review Request: CLOUDSTACK-2543: createipAlias.sh/deleteipAlias.sh won't be copied to XenServer host

[Koushik Das]

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



scripts/vm/hypervisor/xenserver/xcposs/patch
<https://reviews.apache.org/r/11221/#comment42836>

For other entries I see different target paths. What should be the correct 
one in these cases?


- Koushik Das


On May 20, 2013, 6:44 a.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11221/
> ---
> 
> (Updated May 20, 2013, 6:44 a.m.)
> 
> 
> Review request for cloudstack, Prasanna Santhanam and Koushik Das.
> 
> 
> Description
> ---
> 
> createipAlias.sh/deleteipAlias.sh won't be copied to XenServer host.
> 
> 1.The directory of the scripts should be ".." rather "../../.." in all the 
> xenser patches file.
> Corrected the path to ".." because the scripts are located at 
> scripts/vm/hypervisor/xenserver/xenserver56/patch 
> b/scripts/vm/hypervisor/xenserver/
> 
> 
> This addresses bug CLOUDSTACK-2543.
> 
> 
> Diffs
> -
> 
>   scripts/vm/hypervisor/xenserver/xcposs/patch 6dc3baa 
>   scripts/vm/hypervisor/xenserver/xcpserver/patch a275df4 
>   scripts/vm/hypervisor/xenserver/xenserver56/patch 5c4673d 
>   scripts/vm/hypervisor/xenserver/xenserver56fp1/patch c7c58b9 
>   scripts/vm/hypervisor/xenserver/xenserver60/patch 26205f2 
> 
> Diff: https://reviews.apache.org/r/11221/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested with xenserver6.1 on master branch.
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

Re: Review Request: CLOUDSTACK-2543: createipAlias.sh/deleteipAlias.sh won't be copied to XenServer host

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On May 20, 2013, 1:14 p.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11221/
> ---
> 
> (Updated May 20, 2013, 1:14 p.m.)
> 
> 
> Review request for cloudstack, Prasanna Santhanam and Koushik Das.
> 
> 
> Description
> ---
> 
> createipAlias.sh/deleteipAlias.sh won't be copied to XenServer host.
> 
> 1.The directory of the scripts should be ".." rather "../../.." in all the 
> xenser patches file.
> Corrected the path to ".." because the scripts are located at 
> scripts/vm/hypervisor/xenserver/xenserver56/patch 
> b/scripts/vm/hypervisor/xenserver/
> 
> 
> This addresses bug CLOUDSTACK-2543.
> 
> 
> Diffs
> -
> 
>   scripts/vm/hypervisor/xenserver/xcposs/patch 6dc3baa 
>   scripts/vm/hypervisor/xenserver/xcpserver/patch a275df4 
>   scripts/vm/hypervisor/xenserver/xenserver56/patch 5c4673d 
>   scripts/vm/hypervisor/xenserver/xenserver56fp1/patch c7c58b9 
>   scripts/vm/hypervisor/xenserver/xenserver60/patch 26205f2 
> 
> Diff: https://reviews.apache.org/r/11221/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested with xenserver6.1 on master branch.
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

RE: [ANNOUNCE] New committer: Wei Zhou

[Koushik Das]

Congrats Wei!

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Friday, May 24, 2013 2:53 AM
> To: 
> Subject: [ANNOUNCE] New committer: Wei Zhou
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Wei Zhou to become a committer and we are pleased to announce
> that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Wei!
> 
> -chip
> on behalf of the CloudStack PMC

RE: [ANNOUNCE] New committer: Venkata Swamy

[Koushik Das]

Congrats Swamy!

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Friday, May 24, 2013 2:52 AM
> To: 
> Subject: [ANNOUNCE] New committer: Venkata Swamy
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Venkata Swamy to become a committer and we are pleased to
> announce that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Venkata!
> 
> -chip
> on behalf of the CloudStack PMC

RE: [ANNOUNCE] New committer: Sailaja Mada

[Koushik Das]

Congrats Sailaja!

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Friday, May 24, 2013 2:52 AM
> To: 
> Subject: [ANNOUNCE] New committer: Sailaja Mada
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Sailaja Mada to become a committer and we are pleased to announce
> that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Sailaja!
> 
> -chip
> on behalf of the CloudStack PMC

RE: Convention on UUID column

[Koushik Das]

It is better to add constraints in the db for all uuid fields. That way uuid 
field will never get missed out. I see that for some tables there is a NOT NULL 
constraint.

-Koushik

> -Original Message-
> From: Min Chen [mailto:min.c...@citrix.com]
> Sent: Friday, May 24, 2013 4:09 AM
> To: dev@cloudstack.apache.org
> Subject: Convention on UUID column
> 
> Hi there,
> 
> During API refactoring efforts, Rohit and I run into several issues due to
> empty UUID column for existing DB entries. Since UUID was introduced later
> in 3.0.x, we have to always conditionally handle existing customers with
> empty UUID columns for different entities, causing much headache for
> various upgrade cases. To make sure that we have a consistent upgrade base
> for all 4.1 customers later, in schema-410to420.sql, we have added sql scripts
> to populate UUID column of all pre-4.1 schema tables with values from their
> ID column if UUID column is NULL. To make this work properly, we require
> that all UUID columns should be populated with values when you add new
> data into both pre-4.1 schema or post-4.1 schema. I just noticed that this
> assumption may not be well known to community, since I am seeing this sql
> in schema-410to420.sql:
> 
> 
> INSERT INTO `cloud`.`vm_template` (id, unique_name, name, public,
> created, type, hvm, bits, account_id, url, checksum, enable_password,
> display_text, format, guest_os_id, featured, cross_zones, hypervisor_type)
> 
>  VALUES (10, 'routing-10', 'SystemVM Template (LXC)', 0, now(), 'SYSTEM',
> 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-systemvm-
> 02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0, 'SystemVM
> Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
> 
> 
> Instead, this should be modified as:
> 
> 
> INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public,
> created, type, hvm, bits, account_id, url, checksum, enable_password,
> display_text, format, guest_os_id, featured, cross_zones, hypervisor_type)
> 
>  VALUES (10, UUID(), 'routing-10', 'SystemVM Template (LXC)', 0, now(),
> 'SYSTEM', 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-
> systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
> 'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
> 
> I have made this fix in master, but want to raise this topic to get 
> community's
> attention on this.
> 
> Thanks
> -min
> 

RE: [ANNOUNCE] New committer: Sangeetha Hariharan

[Koushik Das]

Congrats Sangeetha!

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Friday, May 24, 2013 11:50 AM
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] New committer: Sangeetha Hariharan
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Sangeetha Hariharan  to become a committer and we are pleased to
> announce that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Sangeetha!
> 
> --Alex
> on behalf of the CloudStack PMC

Re: Review Request: CLOUDSTACK-1453: support restore for VM created from ISO

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On May 24, 2013, 10:19 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9779/
> ---
> 
> (Updated May 24, 2013, 10:19 a.m.)
> 
> 
> Review request for cloudstack, Nitin Mehta and Koushik Das.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-1453: support restore for VM created from ISO
> Previously this was not there. Fixed with small changes
> 
> 
> This addresses bug CLOUDSTACK-1453.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/vm/RestoreVMCmd.java 9c33f97 
>   server/src/com/cloud/vm/UserVmManagerImpl.java a3b731a 
>   server/test/com/cloud/vm/UserVmManagerTest.java 6a97114 
> 
> Diff: https://reviews.apache.org/r/9779/diff/
> 
> 
> Testing
> ---
> 
> tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[Koushik Das]

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



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43583>

There are multiple return paths for this method. How are you ensuring 
consistency in the db. for all the return paths? The complexity of the code 
makes the testing very difficult



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43577>

unused



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43580>

First check if log level is debug and then only print the message. Do in 
other places as well



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43579>

There are multiple db calls _vlanDao, _nicIpAliasDao, _publicIpAddressDao. 
What happens in case of partial success? Should this be in a txn?



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43582>

In some cases you are throwing and in some case you are returning boolean? 
What is the logic?



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43581>

there is a return, what happens to the txn?



server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43571>

why is the error message add/remove vpn users?

Also what is the account and zone here



server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43574>

unused



server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43573>

Is it possible that some routers are running and some are not? If so what 
happens?



server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43572>

error message: same as above



server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43575>

message says apply but this for revoke. right? also dhcp has become "dhco"



server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/11435/#comment43576>

dhco -> dhcp


- Koushik Das


On May 27, 2013, 2:50 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated May 27, 2013, 2:50 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 214e292 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> b969be2 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: CLOUDSTACK-2648 [Multiple_IP_Ranges] Reboot or start/stop router vm deletes the ip alises created on VR in case of multiple subnets

[Koushik Das]

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



core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
<https://reviews.apache.org/r/11437/#comment43590>

Please put a comment as to the need for this extra '-'. In case you are 
doing this to handle any boundary condition explain that as well.



patches/systemvm/debian/config/root/deleteIpAlias.sh
<https://reviews.apache.org/r/11437/#comment43592>

Plese review the condition. Do you need both checks?



server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/11437/#comment43595>

dhco -> dhcp, also should be revoke



server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/11437/#comment43593>

The message says apply, should be revoke.


- Koushik Das


On May 27, 2013, 3:23 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11437/
> ---
> 
> (Updated May 27, 2013, 3:23 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Reboot or start/stop router vm deletes the ip alises 
> created on VR in case of multiple subnets
> https://issues.apache.org/jira/browse/CLOUDSTACK-2648
> 
> 
> This addresses bug Cloudstack-2648.
> 
> 
> Diffs
> -
> 
>   
> core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java 
> 8b996d1 
>   patches/systemvm/debian/config/root/deleteIpAlias.sh 865ff3b 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  630d1b4 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  4680fde 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> b969be2 
> 
> Diff: https://reviews.apache.org/r/11437/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: CLOUDSTACK-2620 [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address in case of multiple subnets

[Koushik Das]

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



api/src/com/cloud/agent/api/to/DnsmasqTO.java
<https://reviews.apache.org/r/11436/#comment43608>

nit: variable name shouldn't start with caps. Change in other places as well



core/src/com/cloud/network/DnsMasqConfigurator.java
<https://reviews.apache.org/r/11436/#comment43618>

Can you format these text properly? What all is comment and what all 
actually gets replaced?



core/src/com/cloud/network/DnsMasqConfigurator.java
<https://reviews.apache.org/r/11436/#comment43617>

What is the correct formatting here, tag:net1,6,... (used in the code below)
OR
dhcp-option=6,dns1,dns2,...




server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/11436/#comment43619>

You have the cidr which can be used as well in dhcp-range parameter.


- Koushik Das


On May 27, 2013, 3:05 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11436/
> ---
> 
> (Updated May 27, 2013, 3:05 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address 
> in case of multiple subnets
> https://issues.apache.org/jira/browse/CLOUDSTACK-2620
> 
> 
> This addresses bug Cloudstack-2620.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/DnsmasqTO.java f99878c 
>   core/src/com/cloud/network/DnsMasqConfigurator.java ee8e5fc 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> b969be2 
> 
> Diff: https://reviews.apache.org/r/11436/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze

[Koushik Das]

> -Original Message-
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: Thursday, May 30, 2013 12:36 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
> 
> On Thu, May 30, 2013 at 3:02 AM, murali reddy
>  wrote:
> > We should do a health-check of proposed features [1] which are at risk
> > for
> > 4.2 feature freeze before deciding to re-evaluate timelines.
> >
> 
> We are supposedly doing time-based release, so we don't care about what
> features make it versus don't.

4.1 was also supposed to be a time based one but got delayed due to various 
issues. So not sure what would be the right approach here. I think it makes 
sense to look at the feature list to see if some of them (individual features 
can be voted upon) can be accommodated in 4.2. If there are no such features 
then there is no need for extending the cutoff date.


> 
> --David

Re: Review Request: CLOUDSTACK-2648 [Multiple_IP_Ranges] Reboot or start/stop router vm deletes the ip alises created on VR in case of multiple subnets

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On June 3, 2013, 10:10 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11437/
> ---
> 
> (Updated June 3, 2013, 10:10 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Reboot or start/stop router vm deletes the ip alises 
> created on VR in case of multiple subnets
> https://issues.apache.org/jira/browse/CLOUDSTACK-2648
> 
> 
> This addresses bug Cloudstack-2648.
> 
> 
> Diffs
> -
> 
>   
> core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java 
> 8b996d1 
>   patches/systemvm/debian/config/root/deleteIpAlias.sh 865ff3b 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  5f99a15 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  a2cceb1 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> c71d037 
> 
> Diff: https://reviews.apache.org/r/11437/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: CLOUDSTACK-2620 [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address in case of multiple subnets

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On June 3, 2013, 1:08 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11436/
> ---
> 
> (Updated June 3, 2013, 1:08 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address 
> in case of multiple subnets
> https://issues.apache.org/jira/browse/CLOUDSTACK-2620
> 
> 
> This addresses bug Cloudstack-2620.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/DnsmasqTO.java f99878c 
>   core/src/com/cloud/network/DnsMasqConfigurator.java ee8e5fc 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> c71d037 
> 
> Diff: https://reviews.apache.org/r/11436/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

StaticNatRule vs StaticNat

[Koushik Das]

What is the difference between these interfaces? I see that StaticNat is used 
in network elements. And StaticNatRule used elsewhere including APIs. Given 
that PF and FW rules uses a single interface everywhere, should a similar thing 
be there for static nat rules as well?

-Koushik

RE: [VOTE] Pushback 4.2.0 Feature Freeze

[Koushik Das]

+0
If proposed features are completed earlier then we shouldn't wait for 4 weeks.

-Koushik

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Friday, May 31, 2013 8:30 PM
> To: dev@cloudstack.apache.org
> Subject: [VOTE] Pushback 4.2.0 Feature Freeze
> 
> Following our discussion on the proposal to push back the feature freeze
> date for 4.2.0 [1], we have not yet achieved a clear consensus.  Well...
> we have already defined the "project rules" for figuring out what to do.
> In out project by-laws [2], we have defined a "release plan" decision as
> follows:
> 
> > 3.4.2. Release Plan
> >
> > Defines the timetable and work items for a release. The plan also
> > nominates a Release Manager.
> >
> > A lazy majority of active committers is required for approval.
> >
> > Any active committer or PMC member may call a vote. The vote must
> > occur on a project development mailing list.
> 
> And our lazy majority is defined as:
> 
> > 3.2.2. Lazy Majority - A lazy majority vote requires 3 binding +1
> > votes and more binding +1 votes than binding -1 votes.
> 
> Our current plan is the starting point, so this VOTE is a vote to change the
> current plan.  We require a 72 hour window for this vote, so IMO we are in an
> odd position where the feature freeze date is at least extended until
> Tuesday of next week.
> 
> Our current plan of record for 4.2.0 is at [3].
> 
> [1] http://markmail.org/message/vi3nsd2yo763kzua
> [2] http://s.apache.org/csbylaws
> [3]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.2+
> Release
> 
> 
> 
> I'd like to call a VOTE on the following:
> 
> Proposal: Extend the feature freeze date for our 4.2.0 feature release from
> today (2013-05-31) to 2013-06-28.  All other dates following the feature
> freeze date in the plan would be pushed out 4 weeks as well.
> 
> Please respond with one of the following:
> 
> +1 : change the plan as listed above
> +/-0 : no strong opinion, but leaning + or -
> -1 : do not change the plan
> 
> This vote will remain open until Tuesday morning US eastern time.
> 
> -chip

Re: Review Request: Cloudstack-2511 Multiple_Ip_Ranges: Adding guest ip range in subset/superset to existing CIDR is allowed https://issues.apache.org/jira/browse/CLOUDSTACK-2511, Cloudstack-2651 [Sha

[Koushik Das]

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


Don't combine multiple fixes in a single commit. Keep it simple -> 1 commit = 1 
bug fix

- Koushik Das


On June 4, 2013, 2:51 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11600/
> ---
> 
> (Updated June 4, 2013, 2:51 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> Cloudstack-2511 Multiple_Ip_Ranges: Adding guest ip range in subset/superset 
> to existing CIDR is allowed
> https://issues.apache.org/jira/browse/CLOUDSTACK-2511
> 
> Cloudstack-2651 [Shared n/w]Add IP range should not ask for gateway and 
> netmask while adding the ip range to the existing subnet.
> https://issues.apache.org/jira/browse/CLOUDSTACK-2651
> 
> 
> This addresses bugs Cloudstack-2511 and Cloudstack-2651.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/test/com/cloud/configuration/ValidateIpRangeTest.java 7681667 
>   utils/src/com/cloud/utils/net/NetUtils.java 8c094c8 
> 
> Diff: https://reviews.apache.org/r/11600/diff/
> 
> 
> Testing
> ---
> 
> Tested with master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[Koushik Das]

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



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment44818>

Where is the txn started? Where is the txn marked as complete?



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment44817>

nit: handel -> handle



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment44833>

Move this comment to the place where the code is moved



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment44835>

Instead of using _accountDao.findById(Account.ACCOUNT_ID_SYSTEM) why don't 
you pass the 'caller' parameter from the calling function 



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment44837>

result_final is set to false, but the code is still moving ahead. 
Previously there was a return So the remaining code should only be executed if 
(result == true).



- Koushik Das


On June 3, 2013, 10:27 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated June 3, 2013, 10:27 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> c71d037 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[Koushik Das]

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



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment44842>

if result_final == false, why is txn committed?


- Koushik Das


On June 3, 2013, 10:27 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated June 3, 2013, 10:27 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> c71d037 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[Koushik Das]

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



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment44863>

why not pass the 'caller' parameter to handleIpAliasDelete?



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/11435/#comment44862>

why is both rollback and commit done?


- Koushik Das


On June 11, 2013, 6:38 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated June 11, 2013, 6:38 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> c71d037 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On June 12, 2013, 10:59 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated June 12, 2013, 10:59 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 59e70cf 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> db4786a 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

RE: Using "In Progress" status in JIRA

[Koushik Das]

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Friday, June 14, 2013 6:32 AM
> To: dev@cloudstack.apache.org
> Subject: Using "In Progress" status in JIRA
> 
> Folks
> 
> It seems that we do not use "In Progress" status in JIRA as often as we
> should. Issues seem to change from "Open" to "Resolved" directly. IMHO
> marking an issue "In Progress" provides much better visibility and helps
> communicate to community that you are working on that item.
> 

Isn't assigning a bug would also mean the same? The 'In Progress' is useful 
when bugs are triaged on a daily basis, most probably towards end of a release 
cycle.

> If for whatever reason you stop working on that item and will not attend to it
> you can always mark it back as "Open".
> 

If someone has stopped working on a bug simply unassign so that anyone else can 
pick it up.

> For 4.2 I see that 40 features/ improvement tickets changed from "Open" to
> "Resolved" directly. And for Bugs "509" bugs moved from "Open" to
> "Resolved" directly.
> 

I don't see any issues in that.

> 
> Thanks
> Animesh

RE: [ANNOUNCE] New committer: Jayapal Reddy Uradi

[Koushik Das]

Congrats Jayapal

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Monday, June 17, 2013 9:02 PM
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] New committer: Jayapal Reddy Uradi
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Jayapal Reddy Uradi to become a committer and we are pleased to
> announce that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Jayapal!
> 
> -chip
> on behalf of the CloudStack PMC

RE: Which file to update for schema change required for 4.1.1?

[Koushik Das]

Ideally if the fix involves schema changes then it should go to 4.2. If there 
is no alternative then 410to411.sql looks like the option. But then the upgrade 
path becomes complicated. The following needs to be handled 4.1.0 -> 4.2.0, 
4.1.1 -> 4.2.0. Or else the upgrade sql script needs to be guarded with "if 
exists" kind of clause for every schema change so that a single 4.1 -> 4.2 
script suffices.

-Koushik

> -Original Message-
> From: Min Chen [mailto:min.c...@citrix.com]
> Sent: Wednesday, June 19, 2013 10:14 PM
> To: dev@cloudstack.apache.org
> Subject: Which file to update for schema change required for 4.1.1?
> 
> Hi there,
> 
> I need to fix a bug for 4.1.1, which requires some schema change. Two
> existing files (schema-40to410.sql and schema-410to420.sql) seem not fit
> here. In this case, should we create a new schema-410to411.sql for this
> purpose? Also, for fix required for 4.1.1, can we directly check into 4.1 
> branch
> or is it still a controlled checkin?
> Thanks for clarification.
> 
> -min

RE: [ANNOUNCE] New committer: Mike Tutkowski

[Koushik Das]

Congrats Mike!

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Wednesday, June 19, 2013 7:10 PM
> To: dev@cloudstack.apache.org
> Subject: FW: [ANNOUNCE] New committer: Mike Tutkowski
> 
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Mike Tutkowski to become a committer and we are pleased to
> announce that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Mike!
> 
> --Alex
> on behalf of the CloudStack PMC

(CLOUDSTACK-3248) XenServer Host got removed successfully inspite of running VMs on the host

[Koushik Das]

This looks like a serious issue. Cloudstack goes into a bad state due to this.

From the UI the host first needs to be put into maintenance and only after that 
the host can be deleted. But if deleteHost API is directly invoked there is no 
such restriction (there is no check to see the ResourceState of the host). Now 
if there are VMs running on the host the system goes into a bad state. The VMs 
remain in the database but no operations can be performed on them.

The fix is to put a check that the resource state is 'Maintenance' for delete 
host to succeed. Before going ahead with the fix just wanted to check if the 
current behavior is intentional to handle some specific scenarios.

-Koushik

RE: HA for VMWare

[Koushik Das]

That's right. Cloudstack relies on native HA capabilities provided by vSphere.

> -Original Message-
> From: Kirk Kosinski [mailto:kirkkosin...@gmail.com]
> Sent: Thursday, July 11, 2013 6:30 AM
> To: us...@cloudstack.apache.org
> Cc: Chip Childers; dev@cloudstack.apache.org
> Subject: Re: HA for VMWare
> 
> Hi, unless something changed (I checked 4.0/4.1 release notes and found
> nothing), CloudStack uses the native vSphere HA (unlike XenServer and
> KVM), so HA must be enabled in a CloudStack-managed vSphere for HA to
> work.  Shutting down a VM through vCenter is probably seen as a valid
> shutdown (same as shutting down through CS UI/API) and doesn't trigger HA
> even if it is enabled in vSphere.  This might be different for other 
> hypervisors
> since VMSync for vSphere is different.
> 
> Best regards,
> Kirk
> 
> On 07/10/2013 01:03 PM, Chip Childers wrote:
> > It "should" work for CS to do the HA (typically with the VMware
> > cluster *not* having HA enabled).
> >
> > Nicolas, perhaps open a bug?
> >
> > On Wed, Jul 10, 2013 at 4:01 PM, Jörgen Maas 
> wrote:
> >> This should be done by ESX instead of CS, to CS ESX hypervisor is
> >> externally managed (vCenter) I guess you need to enable HA in your
> >> vmware configuration
> >>
> >>
> >> On Wed, Jul 10, 2013 at 12:11 PM,  wrote:
> >>
> >>> Hi,
> >>> We are testing CS 4.1.0 with VMWare vSphere 5.0.
> >>> If we stop a VM using vCenter, CS doesn't try to restart it. In logs
> >>> we see :
> >>>
> >>> Skip HA for VMware VM i-xx
> >>>
> >>> In source code, we can see :
> >>>
> >>> @Override
> >>> public void scheduleRestartForVmsOnHost(final HostVO host,
> >>> boolean
> >>> investigate) {
> >>>
> >>>  [...]
> >>>
> >>>  if(host.getHypervisorType() == HypervisorType.VMware) {
> >>> s_logger.info("Don't restart for VMs on host " +
> >>> host.getId() + " as the host is VMware host");
> >>> return;
> >>> }
> >>>
> >>>
> >>>  [...]
> >>>
> >>> }
> >>>
> >>>
> >>> So, CS does not care to restart the VM ?
> >>> Regards.
> >>>
> >>>
> >>> --
> >>> Nicolas Lamirault
> >>>
> >>>
> >>>
> __
> __
> >>> _
> >>>
> >>> Ce message et ses pieces jointes peuvent contenir des informations
> >>> confidentielles ou privilegiees et ne doivent donc pas etre
> >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> >>> ce message par erreur, veuillez le signaler a l'expediteur et le
> >>> detruire ainsi que les pieces jointes. Les messages electroniques
> >>> etant susceptibles d'alteration, Orange decline toute responsabilite
> >>> si ce message a ete altere, deforme ou falsifie. Merci.
> >>>
> >>> This message and its attachments may contain confidential or
> >>> privileged information that may be protected by law; they should not
> >>> be distributed, used or copied without authorisation.
> >>> If you have received this email in error, please notify the sender
> >>> and delete this message and its attachments.
> >>> As emails may be altered, Orange is not liable for messages that
> >>> have been modified, changed or falsified.
> >>> Thank you.
> >>>
> >>>
> >>
> >>
> >> --
> >> Grtz,
> >> Jörgen Maas

RE: Localization

[Koushik Das]

That's correct. Currently all messages are hard-coded in the Java code. First 
all these strings needs to be moved out to something like a 'resource file' and 
only then they can be localized.

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Thursday, July 11, 2013 11:21 AM
> To: dev@cloudstack.apache.org
> Subject: Localization
> 
> Hi,
> 
> I was wondering if the GUI is the only component of CloudStack that is
> localized?
> 
> It looks like we never localize anything in the Java codebase. That being the
> case, error messages returned from the Java side to the client appear in
> English only.
> 
> Does that sound correct?
> 
> 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
> *(tm)*

RE: CLOUDSTACK-531: FIXED ? OPENED ?

[Koushik Das]

Hi Nicolas,
This issue got fixed as part of CLOUDSTACK-595. The fix is present in 4.0 and 
onwards. I will resolve 531 as a duplicate of 595.

-Koushik

> -Original Message-
> From: nicolas.lamira...@orange.com [mailto:nicolas.lamira...@orange.com]
> Sent: Thursday, July 11, 2013 5:59 PM
> To: dev@cloudstack.apache.org
> Subject: CLOUDSTACK-531: FIXED ? OPENED ?
> 
> hi,
> we would like to know if this issue is fixed or not in 4.0.1 ? and 4.1.0 ?
> Thanks.
> 
> --
> Nicolas Lamirault
> 
> __
> __
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.

RE: Another ISO Question

[Koushik Das]

Should it fall back on the compute offering tags if disk offering tags cannot 
be satisfied? This will make the behavior compatible with that of deploying VM 
from template.

-Koushik

> -Original Message-
> From: Prachi Damle [mailto:prachi.da...@citrix.com]
> Sent: Friday, July 12, 2013 2:52 AM
> To: aemne...@gmail.com; Mike Tutkowski
> Cc: dev@cloudstack.apache.org
> Subject: RE: Another ISO Question
> 
> From the deployVM API I see that while deploying a VM from ISO, the
> diskOfferingId passed to the API is used to create the ROOT Disk Volume of
> the VM.
> The tags of this disk offering will be considered while choosing a pool for 
> the
> ROOT volume.
> 
> The tags of the compute offering will not be referred in this case.
> 
> Prachi
> 
> From: Ahmad Emneina [mailto:aemne...@gmail.com]
> Sent: Thursday, July 11, 2013 1:39 PM
> To: Mike Tutkowski; Prachi Damle
> Cc: dev@cloudstack.apache.org
> Subject: Re: Another ISO Question
> 
> Let me defer to +Prachi, she knows the tagging system better than I.
> 
> On Thu, Jul 11, 2013 at 1:33 PM, Mike Tutkowski
> mailto:mike.tutkow...@solidfire.com>>
> wrote:
> OK, thanks.
> 
> I wasn't sure if we were maybe only honoring the Storage Tags of the
> Compute Offering or the Disk Offering, but it sounds like we essentially are
> taking the subset of the two, if any.
> 
> On Thu, Jul 11, 2013 at 2:30 PM, Ahmad Emneina
> mailto:aemne...@gmail.com>> wrote:
> The vm wont deploy. There wont be any hosts found that overlap with the
> correct tagged storage.
> 
> 
> On Thu, Jul 11, 2013 at 1:23 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com>
> wrote:
> 
> > Hi,
> >
> > When trying to kick a VM off based on an ISO, I see you have to pick
> > the Compute Offering and the Disk Offering (as opposed to just picking
> > a Compute Offering for a template).
> >
> > What happens if the Compute Offering and Disk Offering you select have
> > incompatible Storage Tags?
> >
> > 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
> > *(tm)*
> >
> 
> 
> 
> --
> Mike Tutkowski
> Senior CloudStack Developer, SolidFire Inc.
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud(tm)

RE: Is VMware working in 4.2?

[Koushik Das]

This is fixed as part of CLOUDSTACK-3445 in master and 4.2. The issue was with 
local storage pool used bytes getting wrongly stored as you noted.

-Koushik

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Tuesday, July 16, 2013 6:46 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Is VMware working in 4.2?
> 
> Yeah, it appears to be completely backwards.
> 
> When I go to the dashboard, it says I've got 34.05 GB used of 35 GB. In 
> reality
> 34.05 are available (per what vSphere Client says).
> 
> I can log a bug on this.
> 
> 
> On Mon, Jul 15, 2013 at 7:00 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> 
> > Hi,
> >
> > I was having a hard time understanding why my VMware-only setup was
> > complaining that there was little space left on my one primary storage
> > until I looked in the DB.
> >
> > 36562796544 (below) supposedly represents the used bytes while
> > 37580963840 (also below) represents the capacity bytes.
> >
> > Used bytes was recently changed from available bytes (in late June for
> > 4.2) and I wonder if this was not incorporated into the VMware logic
> > because the datastore that this DB row represents claims (in vSphere
> > Client) have have over 34 GB remaining.
> >
> > 6 172.16.140.2 Local Storage 4cccd1e4d37c3afc94381b7d3a914757 LVM 0 1
> > 1 3
> > 36562796544 37580963840 172.16.140.2 datastore-74 2013-07-16 00:37:11
> > Up DefaultPrimary HOST 0
> >
> > Thoughts?
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*
> >
> 
> 
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*

RE: Template Question

[Koushik Das]

I am also seeing it.

-Koushik

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, July 17, 2013 9:22 PM
> To: dev@cloudstack.apache.org
> Subject: Template Question
> 
> Hi,
> 
> I've noticed recently on XenServer when SSVM and CPVM are deployed that
> Template routing-1 appears twice in my Disks list (it used to appear only
> once).
> 
> Is this change in behavior expected?
> 
> 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
> *(tm)*

Re: Review Request 12427: Fix for CLOUDSTACK-3365 and CLOUDSTACK-2536

[Koushik Das]

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


The changes related to CLOUDSTACK-2536 is not required. updateCluster needs to 
be fixed as updateConfiguration is a generic approach and shouldn't be broken 
for handling a special scenario.

- Koushik Das


On July 17, 2013, 7:37 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12427/
> ---
> 
> (Updated July 17, 2013, 7:37 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Nitin 
> Mehta.
> 
> 
> Bugs: CLOUDSTACK-2536 and CLOUDSTACK-3365
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3365: cluster level parameters 
> cluster.(cpu/memory).allocated.capacity.notificationthreshold is not 
> considering overcommit value
> 
> CLOUDSTACK-2536:  parameters (cpu/memory)overcommit ratio and 
> (cpu/memory).overprosioning.factor are redundant(cluster level)
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/alert/AlertManagerImpl.java 9b7cd27 
>   server/src/com/cloud/configuration/Config.java e77f6ce 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 827e233 
>   server/test/com/cloud/vm/VirtualMachineManagerImplTest.java 44e22e2 
> 
> Diff: https://reviews.apache.org/r/12427/diff/
> 
> 
> Testing
> ---
> 
> Tested locally both with actual usage and over committed values for memory. 
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 12427: Fix for CLOUDSTACK-3365: cluster level parameters cluster.(cpu/memory).allocated.capacity.notificationthreshold is not considering overcommit value

[Koushik Das]

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

Ship it!


master -> 78f1092df12928f06646b3bc42d69cc45dd3b1d3
4.2 -> f604e3d9cc9073c8863bbd7dfc47fb6693a0b6f0

Currently in the db. for total capacity of a resource actual value is stored 
but for used capacity the value stored takes into account over provisioning 
factor. As a result of this for any comparison the total capacity needs to be 
re-calibrated in the code everywhere based on over provisioning factor. Please 
open a new bug for future to store used/total capacity values in db. based on 
same scale factor.

- Koushik Das


On July 19, 2013, 10:14 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12427/
> ---
> 
> (Updated July 19, 2013, 10:14 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Nitin 
> Mehta.
> 
> 
> Bugs: CLOUDSTACK-3365
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3365: cluster level parameters 
> cluster.(cpu/memory).allocated.capacity.notificationthreshold is not 
> considering overcommit value
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/alert/AlertManagerImpl.java 9b7cd27 
> 
> Diff: https://reviews.apache.org/r/12427/diff/
> 
> 
> Testing
> ---
> 
> Tested locally both with actual usage and over committed values for memory. 
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 12427: Fix for CLOUDSTACK-3365: cluster level parameters cluster.(cpu/memory).allocated.capacity.notificationthreshold is not considering overcommit value

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On July 19, 2013, 10:14 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12427/
> ---
> 
> (Updated July 19, 2013, 10:14 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Nitin 
> Mehta.
> 
> 
> Bugs: CLOUDSTACK-3365
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3365: cluster level parameters 
> cluster.(cpu/memory).allocated.capacity.notificationthreshold is not 
> considering overcommit value
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/alert/AlertManagerImpl.java 9b7cd27 
> 
> Diff: https://reviews.apache.org/r/12427/diff/
> 
> 
> Testing
> ---
> 
> Tested locally both with actual usage and over committed values for memory. 
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Error to start MS on 4.2

[Koushik Das]

The code needs to handle the case when the db. entry is not present. It should 
fall back on some default value.

-Koushik

On 21-Jul-2013, at 12:38 AM, Min Chen  wrote:

> Thanks Vijay. I just figured out that trick myself:) I will check in a fix
> to 4.2, seems that he forgot to seed this  config value in
> schema410to420.sql.
> 
> -min
> 
> On 7/20/13 12:05 PM, "Vijayendra Bhamidipati"
>  wrote:
> 
>> Hi Min,
>> 
>> Yes it's due to Frank's changes that went into
>> 0633608f8035f8f409c271fc6e7548699a63d366 on master (and
>> a5ee39a54a8574b030655916d6156d049c99009c on 4.2). He introduced a new
>> global configuration variable ucs.sync.blade.interval. So to not run into
>> this error, either redeploy your db or insert a row in the configuration
>> table manually and then bring up your server. Here's the entry in
>> Config.java:
>> 
>> UCSSyncBladeInterval("Advanced", ManagementServer.class, Integer.class,
>> "ucs.sync.blade.interval", "3600", "the interval cloudstack sync with UCS
>> manager for available blades in case user remove blades from chassis
>> without notifying CloudStack", null);
>> 
>> So doing:
>> 
>> mysql> insert into configuration values("Advanced", "DEFAULT",
>> "management-server", "ucs.sync.blade.interval", "3600", "the interval
>> cloudstack sync with UCS manager for available blades in case user remove
>> blades from chassis without notifying CloudStack");
>> Query OK, 1 row affected (0.04 sec)
>> 
>> Should fix this.. on my tree I'm still at one commit behind Frank's.
>> 
>> 
>> Cheers!
>> Regards,
>> Vijay
>> 
>> 
>> 
>> -Original Message-
>> From: Min Chen [mailto:min.c...@citrix.com]
>> Sent: Saturday, July 20, 2013 11:57 AM
>> To: dev@cloudstack.apache.org
>> Cc: Frank Zhang
>> Subject: Error to start MS on 4.2
>> 
>> Hi there,
>> 
>> Anybody encounter this issue in starting MS on latest 4.2 branch?
>> 
>> INFO  [utils.component.ComponentContext] (Timer-2:) Starting
>> com.cloud.ucs.manager.UcsManagerImpl
>> ERROR [utils.component.ComponentContext] (Timer-2:) Unhandled exception
>> java.lang.NumberFormatException: null
>> at java.lang.Integer.parseInt(Integer.java:417)
>> at java.lang.Integer.valueOf(Integer.java:554)
>> at com.cloud.ucs.manager.UcsManagerImpl.start(UcsManagerImpl.java:178)
>> at 
>> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(Compone
>> ntContext.java:135)
>> at 
>> com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50)
>> at java.util.TimerThread.mainLoop(Timer.java:512)
>> at java.util.TimerThread.run(Timer.java:462)
>> Exception in thread "Timer-2" java.lang.RuntimeException: Unable to start
>> com.cloud.ucs.manager.UcsManagerImpl
>> at 
>> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(Compone
>> ntContext.java:141)
>> at 
>> com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50)
>> at java.util.TimerThread.mainLoop(Timer.java:512)
>> at java.util.TimerThread.run(Timer.java:462)
>> Caused by: java.lang.NumberFormatException: null at
>> java.lang.Integer.parseInt(Integer.java:417)
>> at java.lang.Integer.valueOf(Integer.java:554)
>> at com.cloud.ucs.manager.UcsManagerImpl.start(UcsManagerImpl.java:178)
>> at 
>> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(Compone
>> ntContext.java:135)
>> ... 3 more
>> 
>> CC Frank here to see if he knows any recent change on UcsManagerImpl.
>> 
>> Thanks
>> -min
> 

System VMs not coming up due to https://reviews.apache.org/r/12685/

[Koushik Das]

Commit id: 2d4464d2badc9aff842fd180bafc4c384a83a91d

-return new URI(scheme + "://" + value);
+// do we need to check that value does not contain a scheme
+// part?
+if (value.toString().contains(":"))
+return new URI(value.toString());
+else
+return new URI(scheme, value.toString(), null);


As part of this commit system VMs are not working in latest master. I see as 
part of this change the broadcast/isolation URI format has changed from 
vlan:// to vlan:. The code in many places still depends on the 
URI.getHosts() to extract the vlan id which is broken due to the new format.
Can this be reverted?

RE: System VMs not coming up due to https://reviews.apache.org/r/12685/

[Koushik Das]

Standard system VMs with systemvm.iso from latest master. But that shouldn't 
matter as the issue is in the deploy VM code.


From: Donal Lafferty
Sent: 22/07/2013 6:37 PM
To: 'dev@cloudstack.apache.org'; cloudstack-...@incubator.apache.org
Subject: RE: System VMs not coming up due to https://reviews.apache.org/r/12685/

Where are you getting your system VM from?

DL

> -Original Message-----
> From: Koushik Das [mailto:koushik@citrix.com]
> Sent: 22 July 2013 11:09 AM
> To: cloudstack-...@incubator.apache.org
> Subject: System VMs not coming up due to
> https://reviews.apache.org/r/12685/
>
> Commit id: 2d4464d2badc9aff842fd180bafc4c384a83a91d
>
> -return new URI(scheme + "://" + value);
> +// do we need to check that value does not contain a scheme
> +// part?
> +if (value.toString().contains(":"))
> +return new URI(value.toString());
> +else
> +return new URI(scheme, value.toString(), null);
>
>
> As part of this commit system VMs are not working in latest master. I see as
> part of this change the broadcast/isolation URI format has changed from
> vlan:// to vlan:. The code in many places still depends on
> the URI.getHosts() to extract the vlan id which is broken due to the new
> format.
> Can this be reverted?
>
>
>

Re: System VMs not coming up due to https://reviews.apache.org/r/12685/

[Koushik Das]

Daan,

After manually updating the database entries to 'vlan://', the system VMs 
started working. So I don't think using a database before the commit is a 
problem. One piece of code that seems broken is CitrixResourceBase.getNetwork().

Refer to the line of code

long vlan = Long.parseLong(broadcastUri.getHost());

This fails with a NumberFormatException for vlan:.

-Koushik 

On 22-Jul-2013, at 9:38 PM, Daan Hoogland  wrote:

> Koushik,
> 
> thanks for reporting this. You are probably using a database form before
> this commit. This should work but I suspect it doesn't.
>public  URI toUri(T value) {
>try {
>// do we need to check that value does not contain a scheme
>// part?
>try {
>Long.parseLong(value.toString());
>return new URI(Vlan.scheme + "://" + value);
>} catch (NumberFormatException e) {
>if (value.toString().contains(":"))
>return new URI(value.toString());
>else
>return new URI(scheme, value.toString(), null);
>}
>} catch (URISyntaxException e) {
>throw new CloudRuntimeException(
>"Unable to convert to broadcast URI: " + value);
>}
>}
> 
> would be the correct code for the function that is your culprit, but master
> doesn't work due to database mismatches between the code and the databse
> schema. I will test this as soon as possible.
> 
> regards,
> Daan
> 
> 
> On Mon, Jul 22, 2013 at 5:18 PM, Koushik Das  wrote:
> 
>> Standard system VMs with systemvm.iso from latest master. But that
>> shouldn't matter as the issue is in the deploy VM code.
>> 
>> 
>> From: Donal Lafferty
>> Sent: 22/07/2013 6:37 PM
>> To: 'dev@cloudstack.apache.org'; cloudstack-...@incubator.apache.org
>> Subject: RE: System VMs not coming up due to
>> https://reviews.apache.org/r/12685/
>> 
>> Where are you getting your system VM from?
>> 
>> DL
>> 
>>> -Original Message-
>>> From: Koushik Das [mailto:koushik@citrix.com]
>>> Sent: 22 July 2013 11:09 AM
>>> To: cloudstack-...@incubator.apache.org
>>> Subject: System VMs not coming up due to
>>> https://reviews.apache.org/r/12685/
>>> 
>>> Commit id: 2d4464d2badc9aff842fd180bafc4c384a83a91d
>>> 
>>> -return new URI(scheme + "://" + value);
>>> +// do we need to check that value does not contain a
>> scheme
>>> +// part?
>>> +if (value.toString().contains(":"))
>>> +return new URI(value.toString());
>>> +else
>>> +return new URI(scheme, value.toString(), null);
>>> 
>>> 
>>> As part of this commit system VMs are not working in latest master. I
>> see as
>>> part of this change the broadcast/isolation URI format has changed from
>>> vlan:// to vlan:. The code in many places still depends
>> on
>>> the URI.getHosts() to extract the vlan id which is broken due to the new
>>> format.
>>> Can this be reverted?
>>> 
>>> 
>>> 
>> 
>> 

Re: Review Request 12849: added backwards compatibility code to Networks enums

[Koushik Das]

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



api/src/com/cloud/network/Networks.java
<https://reviews.apache.org/r/12849/#comment47581>

Why only Vlan in case of IsolationType and Vlan, Storage and Mido in the 
case of BroadcastDomainType? Earlier both used similar logic.

If all system VMs (SSVM, CPVM and router VMs) are getting started after 
this then should be fine.

Also ensure that upgraded setups work fine as well.


- Koushik Das


On July 23, 2013, 10:02 a.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12849/
> ---
> 
> (Updated July 23, 2013, 10:02 a.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Both BroadcastDomainType and IsolationType needed some extra code for 
> backwards compatibility
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/Networks.java c76c3d4 
>   
> server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
>  6fafa3e 
> 
> Diff: https://reviews.apache.org/r/12849/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

RE: Inclusion of commons-httpclient-contrib jar

[Koushik Das]

For now I think cloud-utils is the best option.

> -Original Message-
> From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
> Sent: Wednesday, July 24, 2013 10:48 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Inclusion of commons-httpclient-contrib jar
> 
> Hi Alex,
> 
> Thanks! I had looked at that initially, but found this disclaimer on the 
> source
> website :
> "Warning:
>  not-yet-commons-ssl-0.3.11 should be considered to be of "Alpha" quality!"
> 
> I do not see a code update in it for the past 4 years, and thus was skeptical.
> Please let me know if we should go ahead with it.
> 
> Thanks,
> Amogh
> 
> On 7/23/13 10:51 PM, "Alex Huang"  wrote:
> 
> >Amogh,
> >
> >I added the following to the pom.xml for cisco and it seems to compile
> >with a few extra exceptions try-catch added.  Can you check on if you
> >can use this?
> >
> >
> >ca.juliusdavies
> >not-yet-commons-ssl
> >0.3.11
> >
> >
> >--Alx
> >
> >> -Original Message-
> >> From: Alex Huang [mailto:alex.hu...@citrix.com]
> >> Sent: Tuesday, July 23, 2013 10:25 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: Inclusion of commons-httpclient-contrib jar
> >>
> >> Isn't this in commons-httpclient 3.1?
> >>
> >> http://grepcode.com/file/repo1.maven.org/maven2/commons-
> >> httpclient/commons-
> >> httpclient/3.1/org/apache/commons/httpclient/contrib/ssl/EasyX509Trus
> >> tM
> >> anager.java
> >>
> >> --Alex
> >>
> >> > -Original Message-
> >> > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> >> > Sent: Tuesday, July 23, 2013 9:41 PM
> >> > To: dev@cloudstack.apache.org
> >> > Subject: Re: Inclusion of commons-httpclient-contrib jar
> >> >
> >> > +1
> >> > @Frank, it is not a re-implementation, but a copy.
> >> >
> >> > On 7/24/13 2:14 AM, "Amogh Vasekar" 
> >> wrote:
> >> >
> >> > >In the absence of an officially published jar on maven for
> >> > >contrib-ssl, the current idea is to put this package in
> >> > >cloud-utils (it is a dependency for both cisco-vnmc and ucs) for
> >> > >easier
> >>maintenance.
> >> > >Please let me know if this sounds good.
> >> > >
> >> > >Thanks,
> >> > >Amogh
> >> > >
> >> > >On 7/22/13 5:26 PM, "Frank Zhang"  wrote:
> >> > >
> >> > >>I prefer to just use httpclient-contribs.jar as it has been
> >> > >>proven by lots of users.
> >> > >>Reimplementing such code brings no gain but maintenance effort.
> >> > >>
> >> > >>> -Original Message-
> >> > >>> From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
> >> > >>> Sent: Monday, July 22, 2013 5:17 PM
> >> > >>> To: dev@cloudstack.apache.org
> >> > >>> Subject: Inclusion of commons-httpclient-contrib jar
> >> > >>>
> >> > >>> Hi All,
> >> > >>>
> >> > >>> I was working on a HTTPS related fix, and found this package in
> >> > >>>the codebase :
> >> > >>>
> >> > >>>
> https://github.com/apache/cloudstack/tree/master/plugins/networ
> >> > >>> k-
> >> > >>> elements/c
> >> > >>> isco-vnmc/src/org/apache/commons/httpclient/contrib/ssl
> >> > >>>
> >> > >>> I need to use the same classes, which are already a part of
> >> > >>>httpclient-contribs  jar
> >> > >>>
> >> >
> >>>(http://www.java2s.com/Code/Jar/c/Downloadcommonshttpclientcon
> >> tr
> >> > ib31jar.
> >> > >>> htm
> >> > >>> )
> >> > >>>
> >> > >>> Was wondering if there is a specific reason the jar was not
> >> > >>>included instead  (probably since it is a contrib jar?)
> >> > >>>
> >> > >>> Thanks,
> >> > >>> Amogh
> >> > >>
> >> > >
> >

Re: Review Request 12808: Fix for CLOUDSTACK-2536: updating parameters (cpu/memory)overcommit ratio and (cpu/memory).overprosioning.factor are redundant(cluster level)

[Koushik Das]

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



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/12808/#comment47664>

Provide the exact parameter name instead of the set of value.



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/12808/#comment47665>

Use a variable to store the message and use it.


- Koushik Das


On July 23, 2013, 11:41 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12808/
> ---
> 
> (Updated July 23, 2013, 11:41 a.m.)
> 
> 
> Review request for cloudstack, Koushik Das and Nitin Mehta.
> 
> 
> Bugs: CLOUDSTACK-1528 and CLOUDSTACK-2536
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2536:  updating parameters (cpu/memory)overcommit ratio and 
> (cpu/memory).overprosioning.factor are redundant(cluster level) 
> There are two APIs updateCluster and UpdateConfiguration where we can update 
> these parameters. Ideally this should get updated using updateConfiguration 
> API, so removing from updateCluster API
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/resource/ResourceService.java 25298cc 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 0550a39 
>   api/src/org/apache/cloudstack/api/command/admin/cluster/AddClusterCmd.java 
> c6ca9bc6 
>   
> api/src/org/apache/cloudstack/api/command/admin/cluster/UpdateClusterCmd.java 
> a14f905 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 92178c9 
>   server/src/com/cloud/resource/ResourceManagerImpl.java d7652f4 
>   server/test/com/cloud/resource/MockResourceManagerImpl.java 2c66134 
> 
> Diff: https://reviews.apache.org/r/12808/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 12808: Fix for CLOUDSTACK-2536: updating parameters (cpu/memory)overcommit ratio and (cpu/memory).overprosioning.factor are redundant(cluster level)

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On July 25, 2013, 7:19 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12808/
> ---
> 
> (Updated July 25, 2013, 7:19 a.m.)
> 
> 
> Review request for cloudstack, Koushik Das and Nitin Mehta.
> 
> 
> Bugs: CLOUDSTACK-1528 and CLOUDSTACK-2536
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2536:  updating parameters (cpu/memory)overcommit ratio and 
> (cpu/memory).overprosioning.factor are redundant(cluster level) 
> There are two APIs updateCluster and UpdateConfiguration where we can update 
> these parameters. Ideally this should get updated using updateConfiguration 
> API, so removing from updateCluster API
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/resource/ResourceService.java 25298cc 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 0550a39 
>   api/src/org/apache/cloudstack/api/command/admin/cluster/AddClusterCmd.java 
> c6ca9bc6 
>   
> api/src/org/apache/cloudstack/api/command/admin/cluster/UpdateClusterCmd.java 
> a14f905 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 9bc8efd 
>   server/src/com/cloud/resource/ResourceManagerImpl.java 342b9fd 
>   server/test/com/cloud/resource/MockResourceManagerImpl.java 2c66134 
> 
> Diff: https://reviews.apache.org/r/12808/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

RE: [DISCUSS] vlan uri format change

[Koushik Das]

I raised this in a separate thread. Daan created a new patch 
https://reviews.apache.org/r/12849/ to address backward compat.

> -Original Message-
> From: Prasanna Santhanam [mailto:t...@apache.org]
> Sent: Saturday, July 27, 2013 11:12 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] vlan uri format change
> 
> Daan,
> 
> This broke the KVM setups last week on master. I couldn't find your commit-
> id for this change scanning the git logs. Toshiaki-san was looking at
> CLOUDSTACK-3682 regarding this change [1] where he makes the scheme
> backwards compatible to work with KVM agents of the past.
> Could you please have a look at the changeset?
> 
> [1] https://reviews.apache.org/r/12985/
> 
> On Mon, Jul 01, 2013 at 10:28:57AM +0200, Daan Hoogland wrote:
> > The gain is that enums like BroadcastDomainType and IsolationType do
> > not have to check for different formats in the presented uri. It also
> > makes it more intiutive what the parts in the uri mean; vlan://
> > would inmply that id is a hostname instead of a scheme specific identifier.
> >
> > I think I am reducing complexity, not introducing any. The present use
> > of uri for vlans is abuse of the construct, i don't think my proposed
> > new use is.
> >
> >
> > On Mon, Jul 1, 2013 at 10:17 AM, Hiroaki KAWAI
> wrote:
> >
> > > Daan, I'm curious about what is the improvement of changing the vlan
> > > String format in URI?
> > >
> > > I'm -1 on pushing more complexity in URI, because that's abuse of
> > > URI class and sounds it's time to get rid of URI.
> > >
> > >
> > >
> > > (2013/07/01 16:47), Daan Hoogland wrote:
> > >
> > >> H,
> > >>
> > >> I've been trying to get a patch accepted and had some discussions
> > >> to do it in parts as well. I would like to refresh the first part:
> > >>
> > >> vlans are now referred as vlan://. I would like to change this
> > >> to vlan:. This will changee addressing the id as a scheme
> > >> specific part instead of as a host. As a result it will be easier
> > >> to fix the code to use Nicira NVP and other sdn networks whereever
> > >> vlans are used now. Doing this will result in a patch that is a
> > >> subset of my earlier patch. It touches a lot of core code and tests
> > >> but has been tested  thoroughly for VPC gateways with both vlans
> > >> and Nicira NVP.
> > >>
> > >> regards,
> > >> Daan
> > >>
> > >>
> > >
> 
> --
> Prasanna.,
> 
> 
> Powered by BigRock.com

RE: Request to inform which DB command to run on existing setup if any db schema changes

[Koushik Das]

Rajesh,
You can look at the check-in history for schema-410to420.sql for the changes

> -Original Message-
> From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
> Sent: Tuesday, July 30, 2013 5:03 PM
> To: dev@cloudstack.apache.org
> Subject: Request to inform which DB command to run on existing setup if any
> db schema changes
> 
> Hi All,
> Please share sql statements to be inserted in the dev list, if any db schema
> changes are committed and require deploy db on existing setup .
> This will save lots of development time.
> More time is getting consumed in clearing the entire setup and set it again.
> 
> Thanks
> Rajesh Battala

RE: [ACS42][Request] CLOUDSTACK-4001

[Koushik Das]

I see this in the review request

Review 13189 failed the build test : FAILURE
The url of build cloudstack-master-with-patch #99 is : 
http://jenkins.cloudstack.org/job/cloudstack-master-with-patch/99/

Can you address this?

-Koushik

> -Original Message-
> From: Sanjay Tripathi [mailto:sanjay.tripa...@citrix.com]
> Sent: Thursday, August 01, 2013 1:43 PM
> To: dev@cloudstack.apache.org
> Cc: Animesh Chaturvedi
> Subject: [ACS42][Request] CLOUDSTACK-4001
> 
> Hi,
> 
> Request to review and commit this patch to 4.2 branch.
> 
> Review request:
> https://reviews.apache.org/r/13189/
> 
> Ticket:
> https://issues.apache.org/jira/browse/CLOUDSTACK-4001
> (Unable to deploy Windows server 2012 64bit VM on XenServer 6.2)
> 
> --Sanjay

Re: Review Request 13072: Print agent host name in logging of agent commands

[Koushik Das]

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


The changes look fine but I don't see much value with this as the name can be 
easily identified from the db. I feel the logs are used primarily for debugging 
issues. And one key aspect that is missing currently is the correlation of 
logs. Currently when a API call is made to MS, it traverses through various 
layers in the MS and finally hitting the resource layer and then returns back 
with response. Logs gets generated from each layer but it is not very intuitive 
to relate them to API call. If there is a unique id (some kind of uuid) that 
gets appended to the logs for a specific API call then correlation becomes very 
easy.

I feel adding these kind of correlation would be much more useful.

- Koushik Das


On July 30, 2013, 5:37 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13072/
> ---
> 
> (Updated July 30, 2013, 5:37 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-3872
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Print agent name when logging Commands sent to VM hosts. See bug description. 
>  I'm not super familiar with this code, so I'd like someone to look over it 
> and verify it's the right thing.
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/agent/transport/Request.java b0fa4cc 
>   server/src/com/cloud/agent/manager/AgentManagerImpl.java b157838 
> 
> Diff: https://reviews.apache.org/r/13072/diff/
> 
> 
> Testing
> ---
> 
> Tested on KVM zone, need help testing others.
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>

RE: Review Request 13072: Print agent host name in logging of agent commands

[Koushik Das]

I see your point Marcus.
I felt that accessing the database would be simpler but you are right that 
everyone may not have access to it. Actually the CS logs do mention the host 
names as well but in a different place and based on that you can match the id 
to a name. For e.g. if you look for agent status logs that mentions both id and 
name.

2013-07-29 10:09:47,124 DEBUG [c.c.h.Status] (AgentTaskPool-3:null) 
Transition:[Resource state = Enabled, Agent event = Ping, Host id = 1, name = 
xenserver-kd1]
2013-07-29 10:09:47,136 DEBUG [c.c.h.Status] (AgentTaskPool-3:null) Agent 
status update: [id = 1; name = xenserver-kd1; old status = Up; event = Ping; 
new status = Up; old update count = 78; new update count = 79]

2013-07-29 10:09:47,736 DEBUG [c.c.a.t.Request] (DirectAgent-24:null) Seq 
1-1386348573: Sending  { Cmd , MgmtId: 2546680725505, via: 1, Ver: v1, Flags: 
100011, 
[{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-45-VM","wait":0}}]
 }
2013-07-29 10:09:47,736 DEBUG [c.c.a.t.Request] (DirectAgent-24:null) Seq 
1-1386348573: Executing:  { Cmd , MgmtId: 2546680725505, via: 1, Ver: v1, 
Flags: 100011, 
[{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-45-VM","wait":0}}]
 }


The changes you have made would definitely improve the readability.

-Koushik

From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Thursday, August 01, 2013 7:26 PM
To: Koushik Das
Cc: cloudstack
Subject: Re: Review Request 13072: Print agent host name in logging of agent 
commands


I agree, that would be useful.

The issue im resolving here is that 1) not everyone who has access to look at 
the logs and troubleshoot also has access to (or knows the schema of) the 
database. There might be an issue with a KVM host, but the admin will waste 
time manually hunting down which host the command went to because he has no 
idea what "via:1237" means and 2) even with db access, its a major pain to go 
hunt down the unencrypted db password(because its a long string that's hard to 
memorize), log into the database, run a query, just to know where to continue 
your debugging.

A little background: Most of the people who surf these logs aren't devs. For us 
they are usually devs, but not cloudstack devs. Maybe UI guys or some other 
consumer. It has happened several times where someone comes into my office, 
points out an agent command, and says "any idea where that went?". I pretty 
much have the numbers memorized by now, depending on the zone, so I tell them 
which agent the command went to. Then they ask me where I found that, and when 
I explain that this little "via: 85" means to go log into the db and make an 
SQL query for vm_instance 85, I almost always get some "gee that's useful, how 
was I ever supposed to know that" response.

So I do agree that the correlations you mention would also be good, I disagree 
with the idea that there is not much value in doing this.
On Aug 1, 2013 6:06 AM, "Koushik Das" 
mailto:koushik@citrix.com>> wrote:
This is an automatically generated e-mail. To reply, visit: 
https://reviews.apache.org/r/13072/




The changes look fine but I don't see much value with this as the name can be 
easily identified from the db. I feel the logs are used primarily for debugging 
issues. And one key aspect that is missing currently is the correlation of 
logs. Currently when a API call is made to MS, it traverses through various 
layers in the MS and finally hitting the resource layer and then returns back 
with response. Logs gets generated from each layer but it is not very intuitive 
to relate them to API call. If there is a unique id (some kind of uuid) that 
gets appended to the logs for a specific API call then correlation becomes very 
easy.



I feel adding these kind of correlation would be much more useful.


- Koushik Das


On July 30th, 2013, 5:37 p.m. UTC, Marcus Sorensen wrote:
Review request for cloudstack.
By Marcus Sorensen.

Updated July 30, 2013, 5:37 p.m.
Bugs: CLOUDSTACK-3872
Repository: cloudstack-git
Description

Print agent name when logging Commands sent to VM hosts. See bug description.  
I'm not super familiar with this code, so I'd like someone to look over it and 
verify it's the right thing.


Testing

Tested on KVM zone, need help testing others.


Diffs

  *   core/src/com/cloud/agent/transport/Request.java (b0fa4cc)
  *   server/src/com/cloud/agent/manager/AgentManagerImpl.java (b157838)

View Diff<https://reviews.apache.org/r/13072/diff/>

RE: [DISCUSS] [jira] make affectedVersion field mandatory.....

[Koushik Das]

+1

> -Original Message-
> From: Ram Ganesh [mailto:ram.gan...@citrix.com]
> Sent: Friday, August 02, 2013 4:38 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] [jira] make affectedVersion field mandatory.
> 
> Hi,
> 
> While triaging bugs I noticed that many bugs had affectedVersion field as
> empty.  This makes it difficult to guess the version/release the reporter was
> on while filing the bug. Can we make the affectedVersion field a mandatory
> field instead?
> 
> Thanks,
> RamG

RE: Reverting 17267794adb2bab923fb20515a7b943780d61921

[Koushik Das]

+1. Provided git allows to make a specific file as read-only.

> -Original Message-
> From: Nitin Mehta [mailto:nitin.me...@citrix.com]
> Sent: Monday, August 05, 2013 12:01 PM
> To: dev@cloudstack.apache.org; Saksham Srivastava
> Subject: Re: Reverting 17267794adb2bab923fb20515a7b943780d61921
> 
> Should we not try and enforce it through git ?
> 
> On 02/08/13 10:44 PM, "Alex Huang"  wrote:
> 
> >Ok...i spoke too soon.  Just talked with Prasanna.  He pointed out that
> >it's a large change that's been in since May.  So I won't revert it.
> >But the rule is no one can change create-schema.sql until the community
> >decided we want to based off of a new copy of the create-schema.
> >
> >--Alex
> >
> >> -Original Message-
> >> From: Alex Huang [mailto:alex.hu...@citrix.com]
> >> Sent: Friday, August 2, 2013 10:01 AM
> >> To: Saksham Srivastava
> >> Cc: dev@cloudstack.apache.org
> >> Subject: Reverting 17267794adb2bab923fb20515a7b943780d61921
> >>
> >> Saksham,
> >>
> >> I'm reverting commit id: 17267794adb2bab923fb20515a7b943780d61921 in
> >> master.
> >>
> >> It changed the create-schema.sql.  We've established since 4.1 that
> >>create-
> >> schema.sql should not be changed and everything done through
> upgrades.
> >>I
> >> believe this commit causes a fresh deployment to fail.
> >>
> >> --Alex

RE: [jira] [Commented] (CLOUDSTACK-4179) [Performance Testing] Time taken for Deploy VM async job to complete is considerably higher

[Koushik Das]

The increase in deployVM time is due to the dedicated resources feature. I have 
updated the issue with my analysis. Need some inputs from the original devs.

-Koushik

> -Original Message-
> From: Koushik Das (JIRA) [mailto:j...@apache.org]
> Sent: Thursday, August 08, 2013 6:37 PM
> To: cloudstack-iss...@incubator.apache.org
> Subject: [jira] [Commented] (CLOUDSTACK-4179) [Performance Testing]
> Time taken for Deploy VM async job to complete is considerably higher
> 
> 
> [ https://issues.apache.org/jira/browse/CLOUDSTACK-
> 4179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=13733464#comment-13733464 ]
> 
> Koushik Das commented on CLOUDSTACK-4179:
> -
> 
> The fix is to optimize the following code in
> checkForNonDedicatedResources(). Also I am not sure why it gets called
> twice during a VM deployment (have debugged through the code). Need to
> check with the developer for dedicated resources.
> 
> List podsInDc = _podDao.listByDataCenterId(dc.getId());
> for (HostPodVO pod : podsInDc) {
> DedicatedResourceVO dedicatedPod =
> _dedicatedDao.findByPodId(pod.getId());
> if (dedicatedPod != null) {
> avoids.addPod(dedicatedPod.getPodId());
> if (s_logger.isDebugEnabled()) {
> s_logger.debug("Cannot use this dedicated pod " +
> pod.getName() + ".");
> }
> }
> }
> List clusterInDc =
> _clusterDao.listClustersByDcId(dc.getId());
> for (ClusterVO cluster : clusterInDc) {
> DedicatedResourceVO dedicatedCluster =
> _dedicatedDao.findByClusterId(cluster.getId());
> if (dedicatedCluster != null) {
> avoids.addCluster(dedicatedCluster.getClusterId());
> if (s_logger.isDebugEnabled()) {
> s_logger.debug("Cannot use this dedicated Cluster " +
> cluster.getName() + ".");
> }
> }
> }
> List hostInDc = _hostDao.listByDataCenterId(dc.getId());
> for (HostVO host : hostInDc) {
> DedicatedResourceVO dedicatedHost =
> _dedicatedDao.findByHostId(host.getId());
> if (dedicatedHost != null) {
> avoids.addHost(dedicatedHost.getHostId());
> if (s_logger.isDebugEnabled()) {
> s_logger.debug("Cannot use this dedicated host " +
> host.getName() + ".");
> }
> }
> }
> 
> > [Performance Testing] Time taken for Deploy VM async job to complete
> > is considerably higher
> > --
> > -
> >
> > Key: CLOUDSTACK-4179
> > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4179
> > Project: CloudStack
> >  Issue Type: Bug
> >      Security Level: Public(Anyone can view this level - this is the 
> > default.)
> >  Components: Management Server
> >Affects Versions: 4.2.0
> > Environment: Simulated VMs and hosts, advanced zone, RVR
> >Reporter: Sowmya Krishnan
> >Assignee: Koushik Das
> >Priority: Critical
> > Fix For: 4.2.0
> >
> > Attachments: async_job_time.out, job-109.log
> >
> >
> > Following setup is used to create performance test bed:
> > Advanced zone, 2 Management Servers, 124 Pods [Each Pod having 2
> > Clusters]
> > 248 Clusters [Each cluster having 8 hosts and one primary storage]
> > 2000 Hosts
> > 4000 User accounts [Each account having one network]
> > ~8000 Virtual Routers
> > Following config parameters were used in both the management servers
> > - Java heap size = 5 GB
> > - db.cloud.maxActive = 250
> > -
> >
> db.cloud.url.params=prepStmtCacheSize=517&cachePrepStmts=true&prepS
> tmt
> >
> CacheSqlLimit=4096&includeInnodbStatusInDeadlockExceptions=true&logSlo
> > wQueries=true Tried deploying around 4000 Simulator VMs across 4K
> > accounts. Noticing considerably higher time for deploy VM async job to
> complete as compared to baseline results.
> > Some of the Baseline results are documented here:
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Baseline+Report
> > s+for+Pre-4.x+Performance+Runs On an avera

Re: Review Request 13441: CLOUDSTACK-3850: CPU cap should be per VM not per VCPU

[Koushik Das]

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



plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
<https://reviews.apache.org/r/13441/#comment49132>

CPU weight computation is not considering the number of CPUs in the VM but 
utilization is considering it. Shouldn't both follow the same logic? If not can 
you explain the logic and put a comment in the code for the same.
 
Also what is logic for multiplying the speed with 0.99?


- Koushik Das


On Aug. 9, 2013, 1 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13441/
> ---
> 
> (Updated Aug. 9, 2013, 1 p.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-3850
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3850:  CPU cap should be per VM not per VCPU 
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  e100211 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
>  d230be1 
> 
> Diff: https://reviews.apache.org/r/13441/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

RE: [ANNOUNCE] New Committer: Vijay Bhamidipati

[Koushik Das]

Congrats Vijay!

> -Original Message-
> From: Prasanna Santhanam [mailto:t...@apache.org]
> Sent: Saturday, August 10, 2013 10:31 AM
> To: CloudStack Dev
> Subject: [ANNOUNCE] New Committer: Vijay Bhamidipati
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Vijay Bhamidipati to become a committer and we are pleased to
> announce that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Vijay!
> 
> --
> Prasanna.,
> on behalf of the Apache CloudStack PMC
> 
> 
> Powered by BigRock.com

Re: Review Request 13441: CLOUDSTACK-3850: CPU cap should be per VM not per VCPU

[Koushik Das]

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


'mvn clean install' on 4.2 branch resulted in build failure. XS unit test is 
failing.


[INFO] 
[INFO] Building Apache CloudStack Plugin - Hypervisor Xen 4.2.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-hypervisor-xen ---
[INFO] Deleting 
/Users/koushik/code/cloudstack-apache/cloudstack/plugins/hypervisors/xen/target 
(includes = [**/*], excludes = [])
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-hypervisor-xen ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-hypervisor-xen ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/Users/koushik/code/cloudstack-apache/cloudstack/plugins/hypervisors/xen/src/main/resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-hypervisor-xen ---
[INFO] Compiling 19 source files to 
/Users/koushik/code/cloudstack-apache/cloudstack/plugins/hypervisors/xen/target/classes
[WARNING] Unable to autodetect 'javac' path, using 'javac' from the environment.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-hypervisor-xen ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/Users/koushik/code/cloudstack-apache/cloudstack/plugins/hypervisors/xen/test/resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-hypervisor-xen ---
[INFO] Compiling 1 source file to 
/Users/koushik/code/cloudstack-apache/cloudstack/plugins/hypervisors/xen/target/test-classes
[WARNING] Unable to autodetect 'javac' path, using 'javac' from the environment.
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-hypervisor-xen ---
[INFO] Surefire report directory: 
/Users/koushik/code/cloudstack-apache/cloudstack/plugins/hypervisors/xen/target/surefire-reports

---
 T E S T S
---
Running com.cloud.hypervisor.xen.resource.CitrixResourceBaseTest
log4j:WARN No appenders could be found for logger 
(com.cloud.hypervisor.xen.resource.XenServerConnectionPool).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.884 sec <<< 
FAILURE!

Results :

Failed tests:   
testScaleVMF3(com.cloud.hypervisor.xen.resource.CitrixResourceBaseTest): (..)

Tests run: 3, Failures: 1, Errors: 0, Skipped: 0


- Koushik Das


On Aug. 10, 2013, 7:08 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13441/
> -------
> 
> (Updated Aug. 10, 2013, 7:08 p.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-3850
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3850:  CPU cap should be per VM not per VCPU 
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  e100211 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
>  d230be1 
> 
> Diff: https://reviews.apache.org/r/13441/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 13441: CLOUDSTACK-3850: CPU cap should be per VM not per VCPU

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On Aug. 11, 2013, 5:28 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13441/
> ---
> 
> (Updated Aug. 11, 2013, 5:28 p.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-3850
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3850:  CPU cap should be per VM not per VCPU 
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  e100211 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
>  d230be1 
>   
> plugins/hypervisors/xen/test/com/cloud/hypervisor/xen/resource/CitrixResourceBaseTest.java
>  cb16ae2 
> 
> Diff: https://reviews.apache.org/r/13441/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Change history lost for upgrade sql script schema-412to420.sql

[Koushik Das]

I noticed that the upgrade sql script (earlier used to be schema-410to420.sql) 
has been renamed and in the process all the change history is lost. Can we 
ensure as a process to do a proper git file rename instead of creating a new 
file so that the changes history is not lost? In this case is there a way to 
retrieve the history?

-Koushik

RE: Change history lost for upgrade sql script schema-412to420.sql

[Koushik Das]

This is fine but is it possible to bring this history to the renamed file? Also 
one has to know that there existed a file 410to420.sql.

> -Original Message-
> From: Devdeep Singh [mailto:devdeep.si...@citrix.com]
> Sent: Monday, August 12, 2013 4:07 PM
> To: dev@cloudstack.apache.org
> Subject: RE: Change history lost for upgrade sql script schema-412to420.sql
> 
> See if this helps https://git-wip-
> us.apache.org/repos/asf/cloudstack/repo?p=cloudstack.git;a=history;f=setu
> p/db/db/schema-
> 410to420.sql;h=60335318c7b792a401cab36b8b456e652d47f2a6;hb=e61a38087
> d158da51f7b945d16e4749a83512ab5
> 
> Regards,
> Devdeep
> 
> > -Original Message-
> > From: Koushik Das [mailto:koushik@citrix.com]
> > Sent: Monday, August 12, 2013 2:50 PM
> > To: cloudstack-...@incubator.apache.org
> > Subject: Change history lost for upgrade sql script
> > schema-412to420.sql
> >
> > I noticed that the upgrade sql script (earlier used to be
> > schema-410to420.sql) has been renamed and in the process all the
> > change history is lost. Can we ensure as a process to do a proper git
> > file rename instead of creating a new file so that the changes history
> > is not lost? In this case is there a way to retrieve the history?
> >
> > -Koushik

RE: Could not find corresponding resource manager for VMware

[Koushik Das]

Also refer 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack 
for the list of nonoss jars that needs to be installed before doing the build.

-Koushik

> -Original Message-
> From: La Motta, David [mailto:david.lamo...@netapp.com]
> Sent: Wednesday, August 14, 2013 2:54 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Could not find corresponding resource manager for VMware
> 
> No, in part since I have been working with XS all along in oss mode only, 
> that I
> expected vmware to work as well.
> 
> Let me give that a try.
> 
> Thx.
> 
> 
> David La Motta
> Technical Marketing Engineer - Citrix Solutions | NetApp
> 
> 
> 
> On 8/13/13 4:43 PM, "Alex Huang"  wrote:
> 
> >David,
> >
> >Did you build with -Dnonoss?
> >
> >--Alex
> >
> >> -Original Message-
> >> From: La Motta, David [mailto:david.lamo...@netapp.com]
> >> Sent: Tuesday, August 13, 2013 1:31 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: Could not find corresponding resource manager for VMware
> >>
> >> Hey everybody, I am trying to add a VMware cluster to CS 4.2 (I am
> >> using commit 7eb3d49e8e0a9b247ea974cad744803420982eda, which is
> >> several weeks
> >> old) and I am getting the error in the subject:
> >>
> >>
> >> INFO  [cloud.api.ApiServer] (413440874@qtp-1461551141-41:) Could not
> >>find  corresponding resource manager for Vmware
> >>
> >>
> >>
> >> Is this a known issue or is there anything specific that must be done
> >>to get CS  to work with Vmware?
> >>
> >> Thanks.
> >>
> >>
> >> --
> >> David La Motta
> >> Technical Marketing Engineer - Citrix Solutions | NetApp
> >>
> >>
> >>
> >

RE: [DISCUSS] git commit messages

[Koushik Das]

Agree. The message should indicate the root cause of the problem and the 
solution.

-Koushik

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Friday, August 16, 2013 2:58 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] git commit messages
> 
> +1
> 
> --Alex
> 
> > -Original Message-
> > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> > Sent: Thursday, August 15, 2013 11:58 AM
> > To: dev
> > Subject: Re: [DISCUSS] git commit messages
> >
> > ok,
> >
> > I saw some violation passing by containing only
> > CLOUDSTACK- as message.
> >
> > I am probably not the best citizen in the world but this freaks me, so
> > this is a reminder to everyone to add a message (and for committers to
> > refuse submissions without it?)
> >
> > thanks,
> > Daan
> >
> > On Thu, Aug 15, 2013 at 8:49 PM, Animesh Chaturvedi
> >  wrote:
> > > Yes the commit message should have a brief summary of the change
> > >
> > >> -Original Message-
> > >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> > >> Sent: Thursday, August 15, 2013 11:36 AM
> > >> To: dev@cloudstack.apache.org
> > >> Subject: Re: [DISCUSS] git commit messages
> > >>
> > >> Not good. Especially since it is documented
> > >> https://cwiki.apache.org/confluence/x/4wnVAQ
> > >>
> > >> On 8/13/13 1:41 AM, "Daan Hoogland" 
> > wrote:
> > >>
> > >> >LS,
> > >> >
> > >> >I see a lot of commits with only ticket  numbers as commit messages.
> > >> >This is not very descriptive and makes me suspicious of what I am
> > >> >pulling in. Can people please append a more descriptive message to
> > >> >the ticket number? Or am I the only one disturbed by this?
> > >> >
> > >> >regards,
> > >> >Daan
> > >