date:20130710

On Tue, Jul 09, 2013 at 06:55:03PM +, Edison Su wrote:
> > From: Chip Childers [mailto:chip.child...@sungard.com]
> > Sent: Tuesday, July 09, 2013 11:22 AM
> > To: Edison Su
> > Cc: 
> > Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in 
> > 4.2?
> > 
> > On Tue, Jul 09, 2013 at 06:12:22PM +, Edison Su wrote:
> > > If it's ok to use S3 api talking to swift, then there is zero effort to 
> > > support
> > Swift.
> > > But who will make the decision?
> > 
> > We, as a community.  It's *always* that answer.
> > 
> > If you are proposing this as the corrective path, then ok...  let's see if 
> > others
> > have opinions about this though.
> > 
> > Heres how I see it:
> > 
> > Pros -
> >  * Code within the master branch has functional S3 API support
> >  * We seem to have more contribution around this interface spec
> >  * Having S3 as the only non-NFS secondary storage API reduces the
> >long-term support / test efforts
> > 
> > Cons -
> >  * We may have an expectation issue for existing users that only have the
> >native Swift API enabled in their environment (although I'm not aware
> >of the Swift API's stability between their releases)
> 
> I think you get into the same situation as I did, without input from
> users who is using Swift, or the company who is supporting Swift,
> what we are talking about here is just hypothetic.
> If we really want to support Swift, and support it better, we need
> to get domain expert involved in the discuss.
> 

(Sigh)

Whoever is going to fix, could you get in touch with the user who
reported CLOUDSTACK-3350? They are using swift in *production*, with
*4.0.1*.  And the bug reporter has offered to test 4.2 via JIRA. 

-- 
Prasanna.,


Powered by BigRock.com

Re: cloudstack 4.1 QinQ vlan behaviour

2013-07-10 Thread Valery Ciareszka

Hi all.

I was able to change vlan creation behaviour by source code modification
(plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java),
had to comment several lines of code:

 private String getPif(String bridge) {
String pif = matchPifFileInDirectory(bridge);
//File vlanfile = new File("/proc/net/vlan/" + pif);

//if (vlanfile.isFile()) {
//pif = Script.runSimpleBashScript("grep ^Device\\:
/proc/net/vlan/"
//  + pif + " | awk {'print
$2'}");
//}

return pif;
}

Could someone please comment this new behaviour of vlan creation ? Why does
it try to create vlan on real physical device, but not on vlan (vlan in
vlan) ? There is nothing about this in documentation.
I have found Q-in-Q for isolated networks functional spec -
https://cwiki.apache.org/CLOUDSTACK/q-in-q-for-isolated-networks-functional-spec.html
"The admin simply needs to create any 'vlan#' devices, and CloudStack uses
them as physical devices."

That worked for me in CS 4.0.2. But as you can see, current version of
cloudstack DOES NOT use 'vlan#' devices as physical devices!!!
Is that a bug ?



On Tue, Jul 9, 2013 at 12:39 PM, Valery Ciareszka  wrote:

> So, nobody uses q in q and cloudstack 4.1 ?
>
>
> On Mon, Jul 8, 2013 at 3:13 PM, Valery Ciareszka <
> valery.teres...@gmail.com> wrote:
>
>> Hi all,
>>
>> I use the following environment: CS 4.1, KVM, Centos 6.4
>> (management+node1+node2), OpenIndiana NFS server as primary and secondary
>> storage
>> I have advanced networking in zone. I split management/public/guest
>> traffic into different vlans, and use kvm network labels (bridge names):
>> # cat /etc/cloud/agent/agent.properties |grep device
>> guest.network.device=cloudbrguest
>> private.network.device=cloudbrmanage
>> public.network.device=cloudbrpublic
>>
>> I have following network configuration:
>> eth0+eth1=bond0
>> eth2+eth3=bond1
>>
>> I use  vlan with id=211 on bond1 interface for guest traffic:
>> cloudbrguest8000.90e2ba317614   yes vlan211
>> cloudbrmanage   8000.90e2ba317614   yes bond1.210
>> cloudbrpublic   8000.90e2ba317614   yes bond1.221
>> cloudbrstor 8000.0025908814a4   yes bond0
>>
>>
>> The problem appeared after I have upgraded CS from 4.0.2 to 4.1.
>>
>> How it works in 4.0.2:
>> -bridge interface cloudVirBr#VLANID is created on hypervisor, #VLANID -
>> value from 1024 to 4096(is specified when creating zone), i.e.
>> cloudVirBr1224
>> -vlan interface vlan211.#VLANID is created on hypervisor and is plugged
>> into cloudVirBr#VLANID
>> I should had permitted 211 vlanid on switchports and all guest traffic
>> (vlans 1024-4096) was encapsulated.
>>
>> How it works in 4.1:
>> -bridge interface br#ETHNAME-#VLANID is created on hypervisor, where
>> #VLANID - value from 1024 to 4096(is specified when creating zone) and
>> #ETHNAME - name of device on top of which vlan will be created
>> i.e. brbond1-1224
>> -vlan interface bond1.#VLANID is created on hypervisor and is plugged
>> into br#ETHNAME-#VLANID
>> However, vlan interface is created on top of bond1 interface, while I
>> would like it to be created on top of vlan211 (bond1.211)
>> Now I should permit 1024-4096 vlanid on switchports, that is not
>> convenient.
>>
>> How do I configure CS 4.1 so that it could work with guest vlans the same
>> way as it had worked in CS 4.0 ?
>>
>> --
>> Regards,
>> Valery
>>
>> http://protocol.by/slayer
>>
>
>
>
> --
> Regards,
> Valery
>
> http://protocol.by/slayer
>



-- 
Regards,
Valery

http://protocol.by/slayer

GSoC: Integration - Bring up Embedded LDAP Server

Hi,

I was looking at the integration test within
test/integration/component/test_ldap.py and noticed that all the
hostnames are hard coded IPs.

Is it possible to bring up a standalone embedded LDAP server such as
ApacheDS during execution of integration tests?

Thanks,
Ian

Re: GSoC: Integration - Bring up Embedded LDAP Server

On Wed, Jul 10, 2013 at 10:24:53AM +0100, Ian Duffy wrote:
> Hi,
> 
> I was looking at the integration test within
> test/integration/component/test_ldap.py and noticed that all the
> hostnames are hard coded IPs.
> 
> Is it possible to bring up a standalone embedded LDAP server such as
> ApacheDS during execution of integration tests?
> 
Hasn't been attempted. How difficult would it be? If it pollutes the
test and makes it complex, we should probably just use a pre-installed
instance and point to it.

-- 
Prasanna.,


Powered by BigRock.com

Re: GSoC: Integration - Bring up Embedded LDAP Server

> How difficult would it be? If it pollutes the
> test and makes it complex

I know there that there is a maven plugin that will bring up an
apacheds server based of flat ldif files:
http://ldap-maven-plugin.btmatthews.com/. Would it be possible to
trigger that to startup when cloud-client-ui jetty:run is launched
with some extra goal to state its for integration test purposes?

> If it pollutes the test and makes it complex, we should probably just use a 
> pre-installed
> instance and point to it.

Wouldn't that be more acceptance level testing? It would mean anybody
wanting to run the integration tests would require the instance.

On 10 July 2013 10:32, Prasanna Santhanam  wrote:
> On Wed, Jul 10, 2013 at 10:24:53AM +0100, Ian Duffy wrote:
>> Hi,
>>
>> I was looking at the integration test within
>> test/integration/component/test_ldap.py and noticed that all the
>> hostnames are hard coded IPs.
>>
>> Is it possible to bring up a standalone embedded LDAP server such as
>> ApacheDS during execution of integration tests?
>>
> Hasn't been attempted. How difficult would it be? If it pollutes the
> test and makes it complex, we should probably just use a pre-installed
> instance and point to it.
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>

Re: How to evaluate performance of a resource allocation policy?

2013-07-10 Thread Linux TUX

Hi,

Thanks to Chip and Alex. To test theories, we can use different solutions such 
as random process, the Monte Carlo simulation, and so forth, and we do not even 
always need to pay this much attention to details of a specific structure like 
the Marvin testing page does for it. 
However, by using simulation, I meant something like the solution that has been 
mentioned by Gulatietal. in [1]. They mentioned that: 


"To develop and evaluate various algorithms, we implemented a simulator that 
simulates a cluster of ESX hosts and VMs. The simulator allows us to create 
different VM and host profiles in order to experiment with different 
configurations. For example, a VM can be defined in
terms of a number of virtual CPUs (vCPUs), configured CPU (in MHz) and 
configured memory size (in MB). Similarly a host can be defined
using parameters such as number of physical cores, CPU (MHz) per core, total 
memory size, power consumption when idle etc.
In terms of workload, the simulator supports arbitrary workload specifications 
for each VM over time and generates CPU and memory demand for that VM based on 
the specification."


So, I was wondering if there is something like this available, but it seems 
there is not. 




[1] Ajay Gulatietal., "VMware Distributed Resource Management: Design, 
Implementation, and Lessons Learned", 2012


Thanks,

--Pouya

 
> Consider using the simulator plugin, which will simulate hosts.  You can 
> follow
> the testing instructions on the Marvin testing page [1], but modify your setup
> to implement whatever number of hosts you want to test against.  From
> there, you would need to modify the allocator that's enabled.
> 
+1  That's exactly how it should be done.  It's how stress tests are performed.

You can modify the simulator plugin to vary its response to play devil's 
advocate to test out different theories.

Also, the simulator today does not have this but you should be able to make it 
implement the PluggableService interface to expose commands to allow your test 
client to adjust responses on the fly.

--Alex

HA for VMWare

2013-07-10 Thread nicolas.lamirault

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.

Re: GSoC: Integration - Bring up Embedded LDAP Server

On Wed, Jul 10, 2013 at 10:43:07AM +0100, Ian Duffy wrote:
> > How difficult would it be? If it pollutes the
> > test and makes it complex
> 
> I know there that there is a maven plugin that will bring up an
> apacheds server based of flat ldif files:
> http://ldap-maven-plugin.btmatthews.com/. Would it be possible to
> trigger that to startup when cloud-client-ui jetty:run is launched
> with some extra goal to state its for integration test purposes?
> 

Sounds like a good idea if all config is in flat files. Runnable from
maven and can be linked with the checkin tests.

> > If it pollutes the test and makes it complex, we should probably
> > just use a pre-installed instance and point to it.
> 
> Wouldn't that be more acceptance level testing? It would mean anybody
> wanting to run the integration tests would require the instance.
> 

Yes - the integration tests are of this nature. Ones with backing
infrastructure. However, since you are only looking at user
provisioning and auth it should be ok to do this test through a maven
profile to setup the ApacheDS. When the tests are run on actual
physical infrastructure I will be setting up the Apache DS instance
that will be static and/or pointing to something like open-ldap.

> On 10 July 2013 10:32, Prasanna Santhanam  wrote:
> > On Wed, Jul 10, 2013 at 10:24:53AM +0100, Ian Duffy wrote:
> >> Hi,
> >>
> >> I was looking at the integration test within
> >> test/integration/component/test_ldap.py and noticed that all the
> >> hostnames are hard coded IPs.
> >>
> >> Is it possible to bring up a standalone embedded LDAP server such as
> >> ApacheDS during execution of integration tests?
> >>
> > Hasn't been attempted. How difficult would it be? If it pollutes the
> > test and makes it complex, we should probably just use a pre-installed
> > instance and point to it.
> >
> > --
> > Prasanna.,
> >
> > 
> > Powered by BigRock.com
> >

-- 
Prasanna.,


Powered by BigRock.com

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


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

(Updated July 10, 2013, 10:14 a.m.)


Review request for cloudstack, Abhinandan Prateek and Koushik Das.


Changes
---

Added fix for CLOUDSTACK-2536


Summary (updated)
-

Fix for CLOUDSTACK-3365 and CLOUDSTACK-2536


Bugs: CLOUDSTACK-2536 and CLOUDSTACK-3365


Repository: cloudstack-git


Description (updated)
---

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 (updated)
-

  server/src/com/cloud/alert/AlertManagerImpl.java 9b7cd27 
  server/src/com/cloud/configuration/Config.java 1a2c620 
  server/src/com/cloud/vm/VirtualMachineManagerImpl.java 30ee2d7 
  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 and CLOUDSTACK-2536


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

(Updated July 10, 2013, 10:19 a.m.)


Review request for cloudstack, Abhinandan Prateek and Koushik Das.


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 (updated)
-

  server/src/com/cloud/alert/AlertManagerImpl.java 9b7cd27 
  server/src/com/cloud/configuration/Config.java d3ed718 
  server/src/com/cloud/vm/VirtualMachineManagerImpl.java 30ee2d7 
  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: How to evaluate performance of a resource allocation policy?

On Wed, Jul 10, 2013 at 02:47:44AM -0700, Linux TUX wrote:
> Hi,
> 
> Thanks to Chip and Alex. To test theories, we can use different
> solutions such as random process, the Monte Carlo simulation, and so
> forth, and we do not even always need to pay this much attention to
> details of a specific structure like the Marvin testing page does
> for it. 
> However, by using simulation, I meant something like the solution that has 
> been mentioned by Gulatietal. in [1]. They mentioned that: 

Can you explain further about the specific resource structure? You can
define any structure you like using the configGenerator. But I'd
assume you stick to a model / group of models to base your simulation
upon? 

> 
> 
> "To develop and evaluate various algorithms, we implemented a
> simulator that simulates a cluster of ESX hosts and VMs. The
> simulator allows us to create different VM and host profiles in
> order to experiment with different configurations. For example, a VM
> can be defined in
> terms of a number of virtual CPUs (vCPUs), configured CPU (in MHz) and 
> configured memory size (in MB). Similarly a host can be defined
> using parameters such as number of physical cores, CPU (MHz) per core, total 
> memory size, power consumption when idle etc.
> In terms of workload, the simulator supports arbitrary workload 
> specifications for each VM over time and generates CPU and memory demand for 
> that VM based on the specification."

This is exactly what the simulator provides. Granted there is no real
hardware backing the infrastrucutre. But the problem of orchestration
that cloudstack attempts to solve abstracts us from thinking about the
nature of physical resource - ESXi, KVM, what have you. Beyond that
you can define offerings (tuples defining the cpu, memory, disk etc)
that cloudstack uses to plan, allocate and deploy the virutal
resources. Once you have that and the model/structure of the entire
cloud infrastructure would you be able to simulate resource allocation
policies on that?

-- 
Prasanna.,

Powered by BigRock.com

Re: Review Request 12327: dnsmasq propagation to vpc routervm

I tried to apply this patch on 4.1. it won't. Does anybody have an idea on
how to implement the same in 4.1 It seems backporting is not an options as
utilities used did not exist back then.

regards,
Daan


On Wed, Jul 10, 2013 at 10:14 AM, daan Hoogland wrote:

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12327/
>   Review request for cloudstack, Chip Childers, Jayapal Reddy, Murali
> Reddy, and Prasanna Santhanam.
> By daan Hoogland.
>
> *Updated July 10, 2013, 8:14 a.m.*
> Changes
>
> added test spring config to patch
>
>   *Bugs: * CLOUDSTACK-3357
>  *Repository: * cloudstack-git
> Description
>
> dnsmasq propagation to vpc routervm
>
>   Testing
>
> a bassc unit test
> manual creation of vpc with a networkdomain
>
>   Diffs (updated)
>
>- 
> server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
>(ddfa998)
>- 
> server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
>(7115499)
>- 
> server/test/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImplTest.java
>(PRE-CREATION)
>- server/test/resources/VpcVirtNetAppContext.xml (PRE-CREATION)
>
> View Diff 
>

Re: GSoC: Integration - Bring up Embedded LDAP Server

> Sounds like a good idea if all config is in flat files. Runnable from
> maven and can be linked with the checkin tests

Newbie maven question

Is it possible to do something like:
mvn -pl :cloud-client-ui jetty-run
:cloud-plugin-user-authenticator-ldap ldap:run


On 10 July 2013 11:11, Prasanna Santhanam  wrote:
> On Wed, Jul 10, 2013 at 10:43:07AM +0100, Ian Duffy wrote:
>> > How difficult would it be? If it pollutes the
>> > test and makes it complex
>>
>> I know there that there is a maven plugin that will bring up an
>> apacheds server based of flat ldif files:
>> http://ldap-maven-plugin.btmatthews.com/. Would it be possible to
>> trigger that to startup when cloud-client-ui jetty:run is launched
>> with some extra goal to state its for integration test purposes?
>>
>
> Sounds like a good idea if all config is in flat files. Runnable from
> maven and can be linked with the checkin tests.
>
>> > If it pollutes the test and makes it complex, we should probably
>> > just use a pre-installed instance and point to it.
>>
>> Wouldn't that be more acceptance level testing? It would mean anybody
>> wanting to run the integration tests would require the instance.
>>
>
> Yes - the integration tests are of this nature. Ones with backing
> infrastructure. However, since you are only looking at user
> provisioning and auth it should be ok to do this test through a maven
> profile to setup the ApacheDS. When the tests are run on actual
> physical infrastructure I will be setting up the Apache DS instance
> that will be static and/or pointing to something like open-ldap.
>
>> On 10 July 2013 10:32, Prasanna Santhanam  wrote:
>> > On Wed, Jul 10, 2013 at 10:24:53AM +0100, Ian Duffy wrote:
>> >> Hi,
>> >>
>> >> I was looking at the integration test within
>> >> test/integration/component/test_ldap.py and noticed that all the
>> >> hostnames are hard coded IPs.
>> >>
>> >> Is it possible to bring up a standalone embedded LDAP server such as
>> >> ApacheDS during execution of integration tests?
>> >>
>> > Hasn't been attempted. How difficult would it be? If it pollutes the
>> > test and makes it complex, we should probably just use a pre-installed
>> > instance and point to it.
>> >
>> > --
>> > Prasanna.,
>> >
>> > 
>> > Powered by BigRock.com
>> >
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>

Re: GSoC: Integration - Bring up Embedded LDAP Server

On Wed, Jul 10, 2013 at 11:28:05AM +0100, Ian Duffy wrote:
> > Sounds like a good idea if all config is in flat files. Runnable from
> > maven and can be linked with the checkin tests
> 
> Newbie maven question
> 
> Is it possible to do something like:
> mvn -pl :cloud-client-ui jetty-run
> :cloud-plugin-user-authenticator-ldap ldap:run
> 

mvn rookie to newbie : I haven't come across something like that :)
Will the ldap:run launch another war?

See: 
http://stackoverflow.com/questions/5519066/possible-to-run-two-webapps-at-once-when-developing-with-maven-eclipse
 
-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 11858: CLOUDSTACK-2340 [AWS Style Health Checks] Response of the API listLoadBalancerRuleInstances should show the service state of a VM if health check is configured for it

2013-07-10 Thread Rajesh Battala



> On July 10, 2013, 7:28 a.m., Ram Ganesh wrote:
> > Ship It!

Thanks for the review.
I have to rebase with latest head and then post the patch again.


- Rajesh


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


On June 30, 2013, 6:08 a.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11858/
> ---
> 
> (Updated June 30, 2013, 6:08 a.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk, Murali Reddy, Ram Ganesh, 
> and Vijay Venkatachalam.
> 
> 
> Bugs: CLOUDSTACK-2340
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Issue: when healthcheck is created for LB rule then 
> listLoadBalancerRuleInstance api should have the service state populated by 
> LBHealthCheckManager. 
> Fixed: Fixed the response of listLoadBalancerRuleInstance  to include a 
> "servicestate":"UP" which tell the service state of the instance.
>if the healthcheck is not created on LB then api response then 
> "servicestate" field won't be in the response.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/lb/LoadBalancingRulesService.java 5fc41e3 
>   api/src/org/apache/cloudstack/api/ApiConstants.java ab1402c 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListLoadBalancerRuleInstancesCmd.java
>  49ab42c 
>   api/src/org/apache/cloudstack/api/response/UserVmResponse.java 1f9eb1a 
>   server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 67d31ab 
> 
> Diff: https://reviews.apache.org/r/11858/diff/
> 
> 
> Testing
> ---
> 
> 1. Created LB rule with healthcheck policy verified the 
> listLoadBalancerRuleInstance  api response, it has the field servicestate for 
> all the VM's assigned to the LB rule
> 2. Created LB rule without healthcheck policy, verified the 
> listLoadBalancerRuleInstance api response wont have the servicestate field 
> for all the VM's assigned to the LB rule
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

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


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

(Updated July 10, 2013, 10:56 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 d3ed718 
  server/src/com/cloud/vm/VirtualMachineManagerImpl.java 30ee2d7 
  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 12358: CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm


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

(Updated July 10, 2013, 10:56 a.m.)


Review request for cloudstack and Nitin Mehta.


Bugs: CLOUDSTACK-3228


Repository: cloudstack-git


Description
---

CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and 
kvm;Zone host is ready, but secondary storage vm template: 3 is not ready on 
secondary storage: 2

Shuffling the hypervisors list before getting the first hypervisor in list so 
that on every retry of system vm deployment it chooses different hypervisor and 
checking whether template is downloaded or not.


Diffs
-

  engine/schema/src/com/cloud/storage/dao/VMTemplateDaoImpl.java 9e75990 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
 407f069 
  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 5983aa7 
  server/src/com/cloud/resource/ResourceManager.java e35e89a 
  server/src/com/cloud/resource/ResourceManagerImpl.java 41c6ad7 
  server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
05256a8 
  server/test/com/cloud/resource/MockResourceManagerImpl.java 18cff80 

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


Testing
---

tested locally


Thanks,

Harikrishna Patnala

[ACS411][ACS42] CS-3904: Patch request

2013-07-10 Thread Wido den Hollander


Hi,

I'd like to request a patch request for both 4.1.1 and 4.2 for issue 
CS-3904.


Commit 8e4e56f73175363038a5361fe99e882562c2913a resolves this issue, but 
it should imho be fixed in 4.1.1 since this is hurting KVM installations 
with (recurring) snapshotting.


Link to bug: https://issues.apache.org/jira/browse/CLOUDSTACK-3409
Link to commit: 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=8e4e56f73175363038a5361fe99e882562c2913a


Wido

Dublin meetup tonight

To all dubliners out there, meetup tonight:

https://tito.io/tcube/cloudstack-clients-and-wrappers

Cu there ,

-Sebastien

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

2013-07-10 Thread 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: Review Request 11858: CLOUDSTACK-2340 [AWS Style Health Checks] Response of the API listLoadBalancerRuleInstances should show the service state of a VM if health check is configured for it

2013-07-10 Thread Rajesh Battala


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

(Updated July 10, 2013, 12:37 p.m.)


Review request for cloudstack, Alena Prokharchyk, Murali Reddy, Ram Ganesh, and 
Sateesh Chodapuneedi.


Changes
---

Rebased with latest head and tested the patch


Bugs: CLOUDSTACK-2340


Repository: cloudstack-git


Description
---

Issue: when healthcheck is created for LB rule then 
listLoadBalancerRuleInstance api should have the service state populated by 
LBHealthCheckManager. 
Fixed: Fixed the response of listLoadBalancerRuleInstance  to include a 
"servicestate":"UP" which tell the service state of the instance.
   if the healthcheck is not created on LB then api response then 
"servicestate" field won't be in the response.


Diffs (updated)
-

  api/src/com/cloud/network/lb/LoadBalancingRulesService.java 5fc41e3 
  api/src/org/apache/cloudstack/api/ApiConstants.java e2857b8 
  
api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListLoadBalancerRuleInstancesCmd.java
 49ab42c 
  api/src/org/apache/cloudstack/api/response/UserVmResponse.java 0df9413 
  server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 6e0d0d7 

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


Testing
---

1. Created LB rule with healthcheck policy verified the 
listLoadBalancerRuleInstance  api response, it has the field servicestate for 
all the VM's assigned to the LB rule
2. Created LB rule without healthcheck policy, verified the 
listLoadBalancerRuleInstance api response wont have the servicestate field for 
all the VM's assigned to the LB rule


Thanks,

Rajesh Battala

Re: CloudStack Mirrors

Adding Wido to the CC.

Wido, what do you think about adding a mirror or two from your RPM / DEB
repo server?

-chip

On Tue, Jul 09, 2013 at 07:31:05PM -0500, Matthew E. Porter wrote:
> If there is a need, we (Contegix) are happy to host one.
> 
> 
> Cheers,
>   Matthew 
> 
> 
> ---
> Matthew E. Porter
> Contegix
> E-mail: matthew.por...@contegix.com
> Twitter: @meporter | http://twitter.com/meporter
> 
> On Jul 9, 2013, at 7:24 PM, Maurice Lawler  wrote:
> 
> > Greetings,
> > 
> > Is there any plan to make use of mirrors for folks downloading / updating 
> > from the repo. Or is there one in existence now?
> > 
> > 
> > - Maurice
>

Re: Review Request 11670: CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary storage is in maintenance state.

2013-07-10 Thread ASF Subversion and Git Services


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


Commit 527080e8effe675e7875fff6a0a69de606e3e3eb in branch 
refs/heads/master-6-17-stable from Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=527080e ]

CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
storage is in maintenance state.


- ASF Subversion and Git Services


On July 1, 2013, 9:18 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11670/
> ---
> 
> (Updated July 1, 2013, 9:18 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Devdeep Singh, and 
> Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-2288
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2288: NPE while creating volume from snapshot when the primary 
> storage is in maintenance state.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/VolumeManagerImpl.java a293da5 
> 
> Diff: https://reviews.apache.org/r/11670/diff/
> 
> 
> Testing
> ---
> 
> Tests:
> 1. In CS setup, put all primary storage in maintenance mode.
> 2. Create a volume from snapshot.
> 
> Verified the fix locally.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Re: org.apache.hypervisor.kvm.resource.LibvirtComputingResourceTest Failure

I would not bother to look at it, if I were your, Dharmesh. Find a good
lightweigth xmlunit-like tool or  another xml comaparison tool to do the
checking. parsers and dom generators can do whatever they like with
attribute order. I would say not with element order, but still trying to
make the xml (un)marshalling do exactly what you want is not worth your
time.

regards,
Daan

On Wed, Jul 10, 2013 at 8:11 AM, Dharmesh Kakadia wrote:

> Hi,
>
> I am trying to re-factor com.cloud to org.apache. While doing so 2 test
> cases in org.apache.hypervisor.kvm.resource.LibvirtComputingResourceTest
> are failing and after trying for 2 days I have no idea why.
>
> Output of build is here http://apaste.info/8Tio
>
> From the output its clear that both the xml strings in test are same, but
> the elemenets are in diffrent order and thus string comparision fails. Can
> anyone point out why they are coming in different order ?
>
> Thanks,
> Dharmesh
>

[DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?

Hi all,

So we've run into a couple of features that have turned out to have
never really been "production grade", perhaps due to their creation as
prototypes during the cloud.com startup period.  Swift, Bare metal
provisioning and OVM are examples.  Bare metal is obviously resolved
now, but Swift is an open discussion and OVM remains open for someone to
decide to fix it.

I'd like to propose that those devs that have been around this code-base
from before it's entry into Apache take some time to review things from
the past.  What else is lurking in the repo that some of us might
*think* are functional, but that haven't been tested in years?  What
code was a prototype that never got fully implemented / supported?

If we can get all this out in the open, perhaps we can have a solid
foundation to move forward.

On the other hand, if nobody has any examples beyond the ones listed
below, then I think that those of us that are relatively new to the code
will have to work under the assumption that everything is expected to be
functional.

After we establish our foundation, we will need to be very consistent
about our support of the features.  We'll need to be clear about
intentions to deprecate something, and perhaps even provide a full
feature release cycle worth of warning about a pending deprecation.

As a user, I not been stung by a feature that was yanked... but I was
certainly surprised when I found out that OVM and Bare Metal weren't
being kept up to date (again, bare metal is resolved now).  Those
features were part of our evaluation of the software, and me $dayjob has
plans to at least use bare metal.

So why did I share that little story?  Well, it's because features
coming and going are actually significant events to users of the
software.  Just because we don't know of someone using a feature doesn't
mean that it isn't in use.  I'd like us to have that solid foundation as
a start, and then be very clear when we need/want to make a decision
that removes a feature from the software.

-chip

Re: org.apache.hypervisor.kvm.resource.LibvirtComputingResourceTest Failure

On Wed, Jul 10, 2013 at 03:01:35PM +0200, Daan Hoogland wrote:
> I would not bother to look at it, if I were your, Dharmesh. Find a good
> lightweigth xmlunit-like tool or  another xml comaparison tool to do the
> checking. parsers and dom generators can do whatever they like with
> attribute order. I would say not with element order, but still trying to
> make the xml (un)marshalling do exactly what you want is not worth your
> time.
> 
> regards,
> Daan

+1 to what Daan says.  The XML specification doesn't require any parsers
to maintain the exact same text representation of the XML data after
it's been parsed and subsequently dumped.  It only has to be the same
*data*.

> 
> 
> 
> On Wed, Jul 10, 2013 at 8:11 AM, Dharmesh Kakadia wrote:
> 
> > Hi,
> >
> > I am trying to re-factor com.cloud to org.apache. While doing so 2 test
> > cases in org.apache.hypervisor.kvm.resource.LibvirtComputingResourceTest
> > are failing and after trying for 2 days I have no idea why.
> >
> > Output of build is here http://apaste.info/8Tio
> >
> > From the output its clear that both the xml strings in test are same, but
> > the elemenets are in diffrent order and thus string comparision fails. Can
> > anyone point out why they are coming in different order ?
> >
> > Thanks,
> > Dharmesh
> >

Re: org.apache.hypervisor.kvm.resource.LibvirtComputingResourceTest Failure

2013-07-10 Thread Dharmesh Kakadia

@chip and @Daan Thanks for the reply.

I think there is some misunderstanding. The test case is not written by me.
It is failing on an already existing test case after I did refactoring,
which is why I am worried.

Thanks,
Dharmesh


On Wed, Jul 10, 2013 at 6:55 PM, Chip Childers wrote:

> On Wed, Jul 10, 2013 at 03:01:35PM +0200, Daan Hoogland wrote:
> > I would not bother to look at it, if I were your, Dharmesh. Find a good
> > lightweigth xmlunit-like tool or  another xml comaparison tool to do the
> > checking. parsers and dom generators can do whatever they like with
> > attribute order. I would say not with element order, but still trying to
> > make the xml (un)marshalling do exactly what you want is not worth your
> > time.
> >
> > regards,
> > Daan
>
> +1 to what Daan says.  The XML specification doesn't require any parsers
> to maintain the exact same text representation of the XML data after
> it's been parsed and subsequently dumped.  It only has to be the same
> *data*.
>
> >
> >
> >
> > On Wed, Jul 10, 2013 at 8:11 AM, Dharmesh Kakadia  >wrote:
> >
> > > Hi,
> > >
> > > I am trying to re-factor com.cloud to org.apache. While doing so 2 test
> > > cases in
> org.apache.hypervisor.kvm.resource.LibvirtComputingResourceTest
> > > are failing and after trying for 2 days I have no idea why.
> > >
> > > Output of build is here http://apaste.info/8Tio
> > >
> > > From the output its clear that both the xml strings in test are same,
> but
> > > the elemenets are in diffrent order and thus string comparision fails.
> Can
> > > anyone point out why they are coming in different order ?
> > >
> > > Thanks,
> > > Dharmesh
> > >
>

Re: database deploy problem

2013-07-10 Thread SuichII, Christopher

Now I'm seeing this issue after pulling the latest and rebuilding.

[ERROR] Failed to execute goal on project cloud-client-ui: Could not resolve 
dependencies for project 
org.apache.cloudstack:cloud-client-ui:war:4.2.0-SNAPSHOT: Could not find 
artifact 
org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT 
in apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
on project cloud-client-ui: Could not resolve dependencies for project 
org.apache.cloudstack:cloud-client-ui:war:4.2.0-SNAPSHOT: Could not find 
artifact 
org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT 
in apache.snapshots (http://repository.apache.org/snapshots)

after running "mvn -U -e -Dmaven.test.skip=true -P developer,systemvm clean 
install"

Does anyone know why this is happening?

Thanks,
Chris

On Jul 1, 2013, at 9:19 AM, Thomas Schneider  
wrote:

> What I did:
> 
> # git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git
> 
> # cd cloudstack
> 
> # mvn -P developer,systemvm clean install
> 
> # mvn -P developer -pl developer,tools/devcloud -Ddeploydb
> 
> then error:
> 
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> 
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache CloudStack Developer Mode
> [INFO] Apache CloudStack DevCloud
> [INFO]
> [INFO]
> 
> [INFO] Building Apache CloudStack Developer Mode 4.2.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache CloudStack Developer Mode .. FAILURE [3.594s]
> [INFO] Apache CloudStack DevCloud  SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 7.951s
> [INFO] Finished at: Mon Jul 01 15:16:56 CEST 2013
> [INFO] Final Memory: 16M/38M
> [INFO]
> 
> [ERROR] Failed to execute goal on project cloud-developer: Could not
> resolve dependencies for project
> org.apache.cloudstack:cloud-developer:pom:4.2.0-SNAPSHOT: The following
> artifacts could not be resolved:
> org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-plugin-hypervisor-simulator:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-secondary-storage:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage-image:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage-volume:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage-snapshot:jar:4.2.0-SNAPSHOT:
> Failure to find org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT in
> http://repository.apache.org/snapshots was cached in the local
> repository, resolution will not be reattempted until the update interval
> of apache.snapshots has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal on project cloud-developer: Could not resolve dependencies
> for project org.apache.cloudstack:cloud-developer:pom:4.2.0-SNAPSHOT:
> The following artifacts could not be resolved:
> org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-plugin-hypervisor-simulator:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-secondary-storage:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage-image:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage-volume:jar:4.2.0-SNAPSHOT,
> org.apache.cloudstack:cloud-engine-storage-snapshot:jar:4.2.0-SNAPSHOT:
> Failure to find org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT in
> http://repository.apache.org/snapshots was cached in the local
> repository, resolution will not be reattempted until the update interval
> of apache.snapshots has elapsed or updates are forced
>at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
>at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
>at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
>at
> org.apache.maven.lifecycle.internal.M

Re: GSoC: Integration - Bring up Embedded LDAP Server

> Will the ldap:run launch another war?

I have no idea Just reading it from
http://ldap-maven-plugin.btmatthews.com/run-mojo.html

I think what I want to do is execute different phases on different projects.

I could do:

mvn -pl :cloud-client-ui jetty:run

followed by:

mvn -pl :cloud-plugin-user-authenticator-ldap ldap:run

but it would nice to have them coming up together.

On 10 July 2013 11:34, Prasanna Santhanam  wrote:
> On Wed, Jul 10, 2013 at 11:28:05AM +0100, Ian Duffy wrote:
>> > Sounds like a good idea if all config is in flat files. Runnable from
>> > maven and can be linked with the checkin tests
>>
>> Newbie maven question
>>
>> Is it possible to do something like:
>> mvn -pl :cloud-client-ui jetty-run
>> :cloud-plugin-user-authenticator-ldap ldap:run
>>
>
> mvn rookie to newbie : I haven't come across something like that :)
> Will the ldap:run launch another war?
>
> See: 
> http://stackoverflow.com/questions/5519066/possible-to-run-two-webapps-at-once-when-developing-with-maven-eclipse
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

On Wed, Jul 10, 2013 at 06:45:39AM +, Animesh Chaturvedi wrote:
> 
> 
> > -Original Message-
> > From: Mathias Mullins [mailto:mathias.mull...@citrix.com]
> > Sent: Tuesday, July 09, 2013 5:40 PM
> > To: dev@cloudstack.apache.org; Edison Su
> > Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in
> > 4.2?
> > 
> > I've been watching from the outside and tracking the entire discussion,
> > and with what has happened with the delays with 4.0 and 4.1 am worried
> > that this could be come the next delayer to the release of 4.2. At the
> > same time, I'm very much in agreement with David N., Chip and John B.
> > that we can't just drop a feature because it hasn't been attiquately
> > tested in that past releases.
> > 
> > My observations -
> > 1. There is not a quick fix here.
> > 2. We don't know who can do it.
> > 3. We're not sure how to do it properly
> > 4. Currently we can't even agree on whether we go with the original
> > version or the newer one.
> > 5. We can't validate user base immediate need and requirement for the
> > feature.
> > 6. We're stuck in Analysis paralysis!
> > 
> > Conclusion - If we don't get past these in short order we are going to
> > jeopardize 4.2 timely release.
> > 
> > Suggestion:
> > Based off my work with other (corporate) software releases, if we can't
> > validate the immediate need, we don't know the immediate fix, and we
> > don't have the right people to do it should we slate this for 4.2.1 and
> > lower this to a Major for 4.2? We don't delay a major release, and at
> > the same time we dedicate ourselves to not stranding a user. We need to
> > do this, but at this point we need to do it right for that user base
> > too.
> > 
> > We work to fix the previous version and we work to support new versions.
> > We get the right resources in to assist, and we make it an immediate
> > priority to address. If we can fix and test properly before the cut of
> > 4.2, WONDERFUL! If not, then it doesn't block the release, but it goes
> > out with 4.2.1 asap.
> > 
> > So there's my ramblings. How far off base am I? :-)
> > 
> > Ready, setŠ fire!
> > Matt
> > 
> [Animesh>] Mathias thanks for a detailed and clear description. I agree if we 
> can fix it fine but if not it should not block 4.2. Given that we are 3 weeks 
> away from code freeze any uncertainties either needs to be addressed or we 
> need to defer them.

Based on CLOUDSTACK-3350, we have a known user.  IMO, this should be a
blocker.  We should either fix Swift to support users or revert the object
store branch merge changes.

Re: [ACS411][ACS42] CS-3904: Patch request

On Wed, Jul 10, 2013 at 01:18:18PM +0200, Wido den Hollander wrote:
> Hi,
> 
> I'd like to request a patch request for both 4.1.1 and 4.2 for issue
> CS-3904.
> 
> Commit 8e4e56f73175363038a5361fe99e882562c2913a resolves this issue,
> but it should imho be fixed in 4.1.1 since this is hurting KVM
> installations with (recurring) snapshotting.
> 
> Link to bug: https://issues.apache.org/jira/browse/CLOUDSTACK-3409
> Link to commit: 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=8e4e56f73175363038a5361fe99e882562c2913a
> 
> Wido
> 
> 
> 
> 

Wido,

The 4.1 branch is open for anyone to add a useful fix for 4.1.1.  Feel
free to move the code over and add the release to the bug's fix version.

4.2 is likewise open for bug fixes.

Re: Error Message: Cloud Stack

2013-07-10 Thread Marcus Sorensen

You can use NFS with a single server, but if you choose local storage
instead, you need to go into the global options and tell system vms to
use local storage. Parameter "system.vm.use.local.storage". I'm not
sure that's the problem, but somewhere in the log it may lead you to
why there is no server capacity, whether the agent isn't running
(hence no hosts), or some other mismatch.

On Tue, Jul 9, 2013 at 10:52 PM, Maurice Lawler  wrote:
> Thank you!
>
> This is being deployed on a single machine utilizing KVM as the hypervisor. 
> This is also my attempt at setting it up under Advanced Networking, with the 
> plans later to add additional servers; just wanted to toy with this server. 
> Should the storage not be NFS since its local? As there is an option at the 
> start of the set up.
>
> Marcus Sorensen  wrote:
>
>>InsufficientServerCapacity = You didn't have enough resources to
>>launch the VM. It can be due to out of memory on hosts, out of CPU, or
>>not able to find storage.  Sometimes this is just due to a mismatch in
>>service offerings. For example, often in a dev environment you just
>>set up a local primary storage, but all service offerings reference
>>shared primary storage, therefore the system can not find a place
>>matching it's requirements on which to run the VMs.
>>
>>On Tue, Jul 9, 2013 at 10:26 PM, Maurice Lawler  wrote:
>>> I have started my cloudstack in advanced mode, however, during the process I
>>> am seeing this:
>>>
>>>
>>>
>>> 2013-07-09 23:23:55,920 DEBUG [cloud.capacity.CapacityManagerImpl]
>>> (consoleproxy-1:null) release cpu from host: 1, old used: 500,reserved: 0,
>>> actual total: 36256, total with overprovisioning: 36256; new used:
>>> 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
>>> 2013-07-09 23:23:55,920 DEBUG [cloud.capacity.CapacityManagerImpl]
>>> (consoleproxy-1:null) release mem from host: 1, old used:
>>> 1073741824,reserved: 0, total: 25186906112; new used: 0,reserved:0;
>>> movedfromreserved: false,moveToReserveredfalse
>>> 2013-07-09 23:23:55,922 WARN  [cloud.consoleproxy.ConsoleProxyManagerImpl]
>>> (consoleproxy-1:null) Exception while trying to start console proxy
>>> com.cloud.exception.InsufficientServerCapacityException: Unable to create a
>>> deployment for VM[ConsoleProxy|v-2-VM]Scope=interface
>>> com.cloud.dc.DataCenter; id=1
>>> at
>>> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:728)
>>> at
>>> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:471)
>>> at
>>> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:464)
>>> at
>>> com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:632)
>>> at
>>> com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:1166)
>>> at
>>> com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1989)
>>> at
>>> com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:175)
>>> at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
>>> at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33)
>>> at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81)
>>> at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72)
>>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>>> at
>>> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
>>> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>> at java.lang.Thread.run(Thread.java:679)
>>> 2013-07-09 23:23:58,720 DEBUG
>>> [storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:null) Zone 1
>>> is ready to launch secondary storage VM
>>>
>>>
>>> What does this mean?
>>>
>>> - Maurice

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

2013-07-10 Thread David Nalley

On Wed, Jul 10, 2013 at 9:40 AM, Chip Childers
 wrote:
> On Wed, Jul 10, 2013 at 06:45:39AM +, Animesh Chaturvedi wrote:
>>
>>
>> > -Original Message-
>> > From: Mathias Mullins [mailto:mathias.mull...@citrix.com]
>> > Sent: Tuesday, July 09, 2013 5:40 PM
>> > To: dev@cloudstack.apache.org; Edison Su
>> > Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in
>> > 4.2?
>> >
>> > I've been watching from the outside and tracking the entire discussion,
>> > and with what has happened with the delays with 4.0 and 4.1 am worried
>> > that this could be come the next delayer to the release of 4.2. At the
>> > same time, I'm very much in agreement with David N., Chip and John B.
>> > that we can't just drop a feature because it hasn't been attiquately
>> > tested in that past releases.
>> >
>> > My observations -
>> > 1. There is not a quick fix here.
>> > 2. We don't know who can do it.
>> > 3. We're not sure how to do it properly
>> > 4. Currently we can't even agree on whether we go with the original
>> > version or the newer one.
>> > 5. We can't validate user base immediate need and requirement for the
>> > feature.
>> > 6. We're stuck in Analysis paralysis!
>> >
>> > Conclusion - If we don't get past these in short order we are going to
>> > jeopardize 4.2 timely release.
>> >
>> > Suggestion:
>> > Based off my work with other (corporate) software releases, if we can't
>> > validate the immediate need, we don't know the immediate fix, and we
>> > don't have the right people to do it should we slate this for 4.2.1 and
>> > lower this to a Major for 4.2? We don't delay a major release, and at
>> > the same time we dedicate ourselves to not stranding a user. We need to
>> > do this, but at this point we need to do it right for that user base
>> > too.
>> >
>> > We work to fix the previous version and we work to support new versions.
>> > We get the right resources in to assist, and we make it an immediate
>> > priority to address. If we can fix and test properly before the cut of
>> > 4.2, WONDERFUL! If not, then it doesn't block the release, but it goes
>> > out with 4.2.1 asap.
>> >
>> > So there's my ramblings. How far off base am I? :-)
>> >
>> > Ready, setŠ fire!
>> > Matt
>> >
>> [Animesh>] Mathias thanks for a detailed and clear description. I agree if 
>> we can fix it fine but if not it should not block 4.2. Given that we are 3 
>> weeks away from code freeze any uncertainties either needs to be addressed 
>> or we need to defer them.
>
> Based on CLOUDSTACK-3350, we have a known user.  IMO, this should be a
> blocker.  We should either fix Swift to support users or revert the object
> store branch merge changes.

Agreed, though honestly I would agree with those decisions regardless
of whether there was a user or not.
Breaking features in an unplanned manner is a blocker.
If it can't be fixed, the change that broke it should be reverted IMO.
--David

Re: cloudstack 4.1 QinQ vlan behaviour

2013-07-10 Thread Marcus Sorensen

I created that document, as a suggestion. I never got feedback. The
way it worked previously was sort of  a happy accident, which was
'fixed' when the code changed to accept overlapping vlan numbers on
multiple physical devices (hence the bridge name change).

However... I believe there is still a way to do what you want with the
stock code. What is your guest KVM traffic label set to?  Cloudstack
is looking for the 'parent' physical device of the bridge, so if it
sees that it's on a vlan, it goes up one more to find the real device.
It only does this once. So if instead of:

cloudbrguest8000.90e2ba317614   yes vlan211

You create:

cloudbrguest-10   8000.90e2ba317614   yes vlan211.10

And tell it to use cloudbrguest-10 as the traffic label, it will go up
one from vlan10 and settle on vlan211 as the physical device. The nice
thing about the new behavior is that I believe it will work on ANY
type, not just 'vlan' ones (so you could bond, for instance).

On Wed, Jul 10, 2013 at 2:34 AM, Valery Ciareszka
 wrote:
> Hi all.
>
> I was able to change vlan creation behaviour by source code modification
> (plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java),
> had to comment several lines of code:
>
>  private String getPif(String bridge) {
> String pif = matchPifFileInDirectory(bridge);
> //File vlanfile = new File("/proc/net/vlan/" + pif);
>
> //if (vlanfile.isFile()) {
> //pif = Script.runSimpleBashScript("grep ^Device\\:
> /proc/net/vlan/"
> //  + pif + " | awk {'print
> $2'}");
> //}
>
> return pif;
> }
>
> Could someone please comment this new behaviour of vlan creation ? Why does
> it try to create vlan on real physical device, but not on vlan (vlan in
> vlan) ? There is nothing about this in documentation.
> I have found Q-in-Q for isolated networks functional spec -
> https://cwiki.apache.org/CLOUDSTACK/q-in-q-for-isolated-networks-functional-spec.html
> "The admin simply needs to create any 'vlan#' devices, and CloudStack uses
> them as physical devices."
>
> That worked for me in CS 4.0.2. But as you can see, current version of
> cloudstack DOES NOT use 'vlan#' devices as physical devices!!!
> Is that a bug ?
>
>
>
> On Tue, Jul 9, 2013 at 12:39 PM, Valery Ciareszka > wrote:
>
>> So, nobody uses q in q and cloudstack 4.1 ?
>>
>>
>> On Mon, Jul 8, 2013 at 3:13 PM, Valery Ciareszka <
>> valery.teres...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I use the following environment: CS 4.1, KVM, Centos 6.4
>>> (management+node1+node2), OpenIndiana NFS server as primary and secondary
>>> storage
>>> I have advanced networking in zone. I split management/public/guest
>>> traffic into different vlans, and use kvm network labels (bridge names):
>>> # cat /etc/cloud/agent/agent.properties |grep device
>>> guest.network.device=cloudbrguest
>>> private.network.device=cloudbrmanage
>>> public.network.device=cloudbrpublic
>>>
>>> I have following network configuration:
>>> eth0+eth1=bond0
>>> eth2+eth3=bond1
>>>
>>> I use  vlan with id=211 on bond1 interface for guest traffic:
>>> cloudbrguest8000.90e2ba317614   yes vlan211
>>> cloudbrmanage   8000.90e2ba317614   yes bond1.210
>>> cloudbrpublic   8000.90e2ba317614   yes bond1.221
>>> cloudbrstor 8000.0025908814a4   yes bond0
>>>
>>>
>>> The problem appeared after I have upgraded CS from 4.0.2 to 4.1.
>>>
>>> How it works in 4.0.2:
>>> -bridge interface cloudVirBr#VLANID is created on hypervisor, #VLANID -
>>> value from 1024 to 4096(is specified when creating zone), i.e.
>>> cloudVirBr1224
>>> -vlan interface vlan211.#VLANID is created on hypervisor and is plugged
>>> into cloudVirBr#VLANID
>>> I should had permitted 211 vlanid on switchports and all guest traffic
>>> (vlans 1024-4096) was encapsulated.
>>>
>>> How it works in 4.1:
>>> -bridge interface br#ETHNAME-#VLANID is created on hypervisor, where
>>> #VLANID - value from 1024 to 4096(is specified when creating zone) and
>>> #ETHNAME - name of device on top of which vlan will be created
>>> i.e. brbond1-1224
>>> -vlan interface bond1.#VLANID is created on hypervisor and is plugged
>>> into br#ETHNAME-#VLANID
>>> However, vlan interface is created on top of bond1 interface, while I
>>> would like it to be created on top of vlan211 (bond1.211)
>>> Now I should permit 1024-4096 vlanid on switchports, that is not
>>> convenient.
>>>
>>> How do I configure CS 4.1 so that it could work with guest vlans the same
>>> way as it had worked in CS 4.0 ?
>>>
>>> --
>>> Regards,
>>> Valery
>>>
>>> http://protocol.by/slayer
>>>
>>
>>
>>
>> --
>> Regards,
>> Valery
>>
>> http://protocol.by/slayer
>>
>
>
>
> --
> Regards,
> Valery
>
> http://protocol.by/slayer

[Proposal] Configuration of Hyper-V SystemVMs

2013-07-10 Thread Donal Lafferty

Could I get some comments on the following proposal?


Background:
System VMs are passed their configuration details in the 'bootArgs' field of 
the StartCommand used to create and start them.  For instance, with XenServer, 
the vm.set_PV_args command is used.
When the SystemVM is launched, the cloud-early-config script reads this 
information and sets up the system VM accordingly.

Problem:
The current SystemVM does not process its configuration when running on a 
Hyper-V hypervisor.  See https://issues.apache.org/jira/browse/CLOUDSTACK-3449

Proposed solution:
Pass the data in the KVP service.  KVP is short for key value pair.  This 
service allows key / value strings to be passed between host and guest VM in 
either direction.
Drivers for Hyper-V's KVP exist in the Debian distro used by the current 
SystemVM (Debian Wheezy).  In addition, a user mode daemon, hv_kvp_daemon, must 
running on the SystemVM.  This daemon writes the key / value pairs to a file.

Complications:
-KVP will not work until the O/S is running, which will delay the completion of 
the StartCommand.
-A binary of hv_kvp_daemon needs to be found.  One option is to build from 
source, as hv_kvp_daemon is in the Linux kernel repo.
-If the Hyper-V host does not get proper feedback about whether hv_kvp_daemon 
wrote a KVP to file, it will be difficult to tell if the data was passed 
properly.
-An alternative to the KVP service is to place bootargs in a file on a new 
volume and attach this to the system VM.  However, this broadens bootargs 
functionality to include volume management.

RE: Dublin meetup tonight

2013-07-10 Thread Donal Lafferty

Seb,

Please circulate a picture of yourself in the branded clothing distributed 
during the event.

;)

DL

> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: 10 July 2013 12:38 PM
> To: dev@cloudstack.apache.org
> Subject: Dublin meetup tonight
> 
> To all dubliners out there, meetup tonight:
> 
> https://tito.io/tcube/cloudstack-clients-and-wrappers
> 
> Cu there ,
> 
> -Sebastien

Re: Dublin meetup tonight

On Wed, Jul 10, 2013, at 06:38 AM, Sebastien Goasguen wrote:
> To all dubliners out there, meetup tonight:

I tweeted this from the CloudStack account. Happy to add these to our
social media for promotion ahead of time if folks send a note to
marketing@ with the full info... 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Review Request 12445: Making sdn gre work with XCP 1.6

2013-07-10 Thread tuna


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

(Updated July 10, 2013, 3:31 p.m.)


Review request for cloudstack, Sebastien Goasguen and Hugo Trippaers.


Repository: cloudstack-git


Description
---

This patch makes sdn gre work with XCP 1.6. Users still can follow the old 
strategy described in this post: 
https://cwiki.apache.org/CLOUDSTACK/ovs-tunnel-manager-for-cloudstack.html. 

Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1779


Diffs
-

  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 d6d0523 
  scripts/vm/hypervisor/xenserver/ovstunnel ddcaa5b 
  scripts/vm/hypervisor/xenserver/xcposs/patch 4d07c76 
  scripts/vm/hypervisor/xenserver/xcpserver/patch 7e92d5a 
  scripts/vm/hypervisor/xenserver/xenserver56/patch 8abd6b2 
  scripts/vm/hypervisor/xenserver/xenserver56fp1/patch 901f6de 

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


Testing
---


Thanks,

tuna

Re: database deploy problem

2013-07-10 Thread SuichII, Christopher

Ignore that….I was running mvn with sudo, so of course it couldn't find the 
artifact…


On Jul 10, 2013, at 9:36 AM, "SuichII, Christopher"  
wrote:

> Now I'm seeing this issue after pulling the latest and rebuilding.
> 
> [ERROR] Failed to execute goal on project cloud-client-ui: Could not resolve 
> dependencies for project 
> org.apache.cloudstack:cloud-client-ui:war:4.2.0-SNAPSHOT: Could not find 
> artifact 
> org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT 
> in apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal on project cloud-client-ui: Could not resolve dependencies for project 
> org.apache.cloudstack:cloud-client-ui:war:4.2.0-SNAPSHOT: Could not find 
> artifact 
> org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT 
> in apache.snapshots (http://repository.apache.org/snapshots)
> 
> after running "mvn -U -e -Dmaven.test.skip=true -P developer,systemvm clean 
> install"
> 
> Does anyone know why this is happening?
> 
> Thanks,
> Chris
> 
> On Jul 1, 2013, at 9:19 AM, Thomas Schneider  
> wrote:
> 
>> What I did:
>> 
>> # git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git
>> 
>> # cd cloudstack
>> 
>> # mvn -P developer,systemvm clean install
>> 
>> # mvn -P developer -pl developer,tools/devcloud -Ddeploydb
>> 
>> then error:
>> 
>> [INFO] Error stacktraces are turned on.
>> [INFO] Scanning for projects...
>> [INFO]
>> 
>> [INFO] Reactor Build Order:
>> [INFO]
>> [INFO] Apache CloudStack Developer Mode
>> [INFO] Apache CloudStack DevCloud
>> [INFO]
>> [INFO]
>> 
>> [INFO] Building Apache CloudStack Developer Mode 4.2.0-SNAPSHOT
>> [INFO]
>> 
>> [INFO]
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Apache CloudStack Developer Mode .. FAILURE [3.594s]
>> [INFO] Apache CloudStack DevCloud  SKIPPED
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Total time: 7.951s
>> [INFO] Finished at: Mon Jul 01 15:16:56 CEST 2013
>> [INFO] Final Memory: 16M/38M
>> [INFO]
>> 
>> [ERROR] Failed to execute goal on project cloud-developer: Could not
>> resolve dependencies for project
>> org.apache.cloudstack:cloud-developer:pom:4.2.0-SNAPSHOT: The following
>> artifacts could not be resolved:
>> org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-plugin-hypervisor-simulator:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-secondary-storage:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-engine-storage:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-engine-storage-image:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-engine-storage-volume:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-engine-storage-snapshot:jar:4.2.0-SNAPSHOT:
>> Failure to find org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT in
>> http://repository.apache.org/snapshots was cached in the local
>> repository, resolution will not be reattempted until the update interval
>> of apache.snapshots has elapsed or updates are forced -> [Help 1]
>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>> execute goal on project cloud-developer: Could not resolve dependencies
>> for project org.apache.cloudstack:cloud-developer:pom:4.2.0-SNAPSHOT:
>> The following artifacts could not be resolved:
>> org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-plugin-hypervisor-simulator:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-secondary-storage:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-plugin-storage-image-simulator:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-engine-storage:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-engine-storage-image:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-engine-storage-volume:jar:4.2.0-SNAPSHOT,
>> org.apache.cloudstack:cloud-engine-storage-snapshot:jar:4.2.0-SNAPSHOT:
>> Failure to find org.apache.cloudstack:cloud-server:jar:4.2.0-SNAPSHOT in
>> http://repository.apache.org/snapshots was cached in the local
>> repository, resolution will not be reattempted until the update interval
>> of apache.snapshots has elapsed or updates are forced
>>   at
>> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
>>   at
>> org.apache.maven.

Re: System VM

2013-07-10 Thread Ahmad Emneina

That seems to be the latest stable release for the KVM template (according
to the 4.1 install docs). You can also get bleeding edge templates from:
http://jenkins.cloudstack.org/job/build-systemvm-master, say if youre
interested in ipv6 support and other features that didnt make it into
'-stable'.

On Tue, Jul 9, 2013 at 6:19 PM, Maurice Lawler wrote:

> Hello,
>
> I'm curious, is this the most recent up to date system VM for download for
> KVM?
>
>
> http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2
>
>
>
>

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

2013-07-10 Thread Mathias Mullins


On 7/10/13 8:59 AM, "David Nalley"  wrote:

>On Wed, Jul 10, 2013 at 9:40 AM, Chip Childers
> wrote:
>> On Wed, Jul 10, 2013 at 06:45:39AM +, Animesh Chaturvedi wrote:
>>>
>>>
>>> > -Original Message-
>>> > From: Mathias Mullins [mailto:mathias.mull...@citrix.com]
>>> > Sent: Tuesday, July 09, 2013 5:40 PM
>>> > To: dev@cloudstack.apache.org; Edison Su
>>> > Subject: Re: Swift in 4.2 is broken, anybody wants it to be
>>>supported in
>>> > 4.2?
>>> >
>>> > I've been watching from the outside and tracking the entire
>>>discussion,
>>> > and with what has happened with the delays with 4.0 and 4.1 am
>>>worried
>>> > that this could be come the next delayer to the release of 4.2. At
>>>the
>>> > same time, I'm very much in agreement with David N., Chip and John B.
>>> > that we can't just drop a feature because it hasn't been attiquately
>>> > tested in that past releases.
>>> >
>>> > My observations -
>>> > 1. There is not a quick fix here.
>>> > 2. We don't know who can do it.
>>> > 3. We're not sure how to do it properly
>>> > 4. Currently we can't even agree on whether we go with the original
>>> > version or the newer one.
>>> > 5. We can't validate user base immediate need and requirement for the
>>> > feature.
>>> > 6. We're stuck in Analysis paralysis!
>>> >
>>> > Conclusion - If we don't get past these in short order we are going
>>>to
>>> > jeopardize 4.2 timely release.
>>> >
>>> > Suggestion:
>>> > Based off my work with other (corporate) software releases, if we
>>>can't
>>> > validate the immediate need, we don't know the immediate fix, and we
>>> > don't have the right people to do it should we slate this for 4.2.1
>>>and
>>> > lower this to a Major for 4.2? We don't delay a major release, and at
>>> > the same time we dedicate ourselves to not stranding a user. We need
>>>to
>>> > do this, but at this point we need to do it right for that user base
>>> > too.
>>> >
>>> > We work to fix the previous version and we work to support new
>>>versions.
>>> > We get the right resources in to assist, and we make it an immediate
>>> > priority to address. If we can fix and test properly before the cut
>>>of
>>> > 4.2, WONDERFUL! If not, then it doesn't block the release, but it
>>>goes
>>> > out with 4.2.1 asap.
>>> >
>>> > So there's my ramblings. How far off base am I? :-)
>>> >
>>> > Ready, setŠ fire!
>>> > Matt
>>> >
>>> [Animesh>] Mathias thanks for a detailed and clear description. I
>>>agree if we can fix it fine but if not it should not block 4.2. Given
>>>that we are 3 weeks away from code freeze any uncertainties either
>>>needs to be addressed or we need to defer them.
>>
>> Based on CLOUDSTACK-3350, we have a known user.  IMO, this should be a
>> blocker.  We should either fix Swift to support users or revert the
>>object
>> store branch merge changes.
>
>Agreed, though honestly I would agree with those decisions regardless
>of whether there was a user or not.
>Breaking features in an unplanned manner is a blocker.
>If it can't be fixed, the change that broke it should be reverted IMO.
>--David

And what if we have nothing to revert too that we can make compatible and
function, and a expert to make it functional, What do we do then?
This seems to be the state we are in.

Matt

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

On Wed, Jul 10, 2013 at 03:50:13PM +, Mathias Mullins wrote:
> 
> On 7/10/13 8:59 AM, "David Nalley"  wrote:
> 
> >On Wed, Jul 10, 2013 at 9:40 AM, Chip Childers
> > wrote:
> >> On Wed, Jul 10, 2013 at 06:45:39AM +, Animesh Chaturvedi wrote:
> >>>
> >>>
> >>> > -Original Message-
> >>> > From: Mathias Mullins [mailto:mathias.mull...@citrix.com]
> >>> > Sent: Tuesday, July 09, 2013 5:40 PM
> >>> > To: dev@cloudstack.apache.org; Edison Su
> >>> > Subject: Re: Swift in 4.2 is broken, anybody wants it to be
> >>>supported in
> >>> > 4.2?
> >>> >
> >>> > I've been watching from the outside and tracking the entire
> >>>discussion,
> >>> > and with what has happened with the delays with 4.0 and 4.1 am
> >>>worried
> >>> > that this could be come the next delayer to the release of 4.2. At
> >>>the
> >>> > same time, I'm very much in agreement with David N., Chip and John B.
> >>> > that we can't just drop a feature because it hasn't been attiquately
> >>> > tested in that past releases.
> >>> >
> >>> > My observations -
> >>> > 1. There is not a quick fix here.
> >>> > 2. We don't know who can do it.
> >>> > 3. We're not sure how to do it properly
> >>> > 4. Currently we can't even agree on whether we go with the original
> >>> > version or the newer one.
> >>> > 5. We can't validate user base immediate need and requirement for the
> >>> > feature.
> >>> > 6. We're stuck in Analysis paralysis!
> >>> >
> >>> > Conclusion - If we don't get past these in short order we are going
> >>>to
> >>> > jeopardize 4.2 timely release.
> >>> >
> >>> > Suggestion:
> >>> > Based off my work with other (corporate) software releases, if we
> >>>can't
> >>> > validate the immediate need, we don't know the immediate fix, and we
> >>> > don't have the right people to do it should we slate this for 4.2.1
> >>>and
> >>> > lower this to a Major for 4.2? We don't delay a major release, and at
> >>> > the same time we dedicate ourselves to not stranding a user. We need
> >>>to
> >>> > do this, but at this point we need to do it right for that user base
> >>> > too.
> >>> >
> >>> > We work to fix the previous version and we work to support new
> >>>versions.
> >>> > We get the right resources in to assist, and we make it an immediate
> >>> > priority to address. If we can fix and test properly before the cut
> >>>of
> >>> > 4.2, WONDERFUL! If not, then it doesn't block the release, but it
> >>>goes
> >>> > out with 4.2.1 asap.
> >>> >
> >>> > So there's my ramblings. How far off base am I? :-)
> >>> >
> >>> > Ready, setŠ fire!
> >>> > Matt
> >>> >
> >>> [Animesh>] Mathias thanks for a detailed and clear description. I
> >>>agree if we can fix it fine but if not it should not block 4.2. Given
> >>>that we are 3 weeks away from code freeze any uncertainties either
> >>>needs to be addressed or we need to defer them.
> >>
> >> Based on CLOUDSTACK-3350, we have a known user.  IMO, this should be a
> >> blocker.  We should either fix Swift to support users or revert the
> >>object
> >> store branch merge changes.
> >
> >Agreed, though honestly I would agree with those decisions regardless
> >of whether there was a user or not.
> >Breaking features in an unplanned manner is a blocker.
> >If it can't be fixed, the change that broke it should be reverted IMO.
> >--David
> 
> And what if we have nothing to revert too that we can make compatible and
> function, and a expert to make it functional, What do we do then?
> This seems to be the state we are in.
> 
> Matt
> 
>

Well, given that we have a bug about Swift (3350), we know that there
are bugs...  but that generally it's working.

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

2013-07-10 Thread Caleb Call

It's decisions like this (dropping a previously advertised supported feature 
simply because it wasn't tested) are part of the reasons that have changed our 
plan to use Cloudstack in our corporate environment.  I'm glad to see Chip, 
David, and others pushing back on the decision to just drop it and fix it in 
the next dot release (same story as OVM, go back and read the discussions on 
the choice to drop it and they sound identical to what you're saying) which 
generally means it's getting dropped for good.  It doesn't matter if the 
feature currently works or not or if it's been tested in a while or not, it's 
being advertised as being supported and people/companies make plans based on 
those supported features.  Although my voice doesn't mean a lot, I too would 
vote this as a blocker.  If it's going to be dropped, users need to be notified 
well in advanced so they can be make plans moving forward instead of suddenly 
being stranded on an out-dated version.


On Jul 9, 2013, at 6:39 PM, Mathias Mullins  wrote:

> I've been watching from the outside and tracking the entire discussion,
> and with what has happened with the delays with 4.0 and 4.1 am worried
> that this could be come the next delayer to the release of 4.2. At the
> same time, I'm very much in agreement with David N., Chip and John B. that
> we can't just drop a feature because it hasn't been attiquately tested in
> that past releases.
> 
> My observations - 
> 1. There is not a quick fix here.
> 2. We don't know who can do it.
> 3. We're not sure how to do it properly
> 4. Currently we can't even agree on whether we go with the original
> version or the newer one.
> 5. We can't validate user base immediate need and requirement for the
> feature. 
> 6. We're stuck in Analysis paralysis!
> 
> Conclusion - If we don't get past these in short order we are going to
> jeopardize 4.2 timely release.
> 
> Suggestion:
> Based off my work with other (corporate) software releases, if we can't
> validate the immediate need, we don't know the immediate fix, and we don't
> have the right people to do it should we slate this for 4.2.1 and lower
> this to a Major for 4.2? We don't delay a major release, and at the same
> time we dedicate ourselves to not stranding a user. We need to do this,
> but at this point we need to do it right for that user base too.
> 
> We work to fix the previous version and we work to support new versions.
> We get the right resources in to assist, and we make it an immediate
> priority to address. If we can fix and test properly before the cut of
> 4.2, WONDERFUL! If not, then it doesn't block the release, but it goes out
> with 4.2.1 asap. 
> 
> So there's my ramblings. How far off base am I? :-)
> 
> Ready, setŠ fire!
> Matt 
> 
> 
> 
> On 7/9/13 5:23 PM, "Animesh Chaturvedi" 
> wrote:
> 
>> 
>> 
>>> -Original Message-
>>> From: Chip Childers [mailto:chip.child...@sungard.com]
>>> Sent: Tuesday, July 09, 2013 11:57 AM
>>> To: Edison Su
>>> Cc: 
>>> Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in
>>> 4.2?
>>> 
>>> On Tue, Jul 09, 2013 at 06:55:03PM +, Edison Su wrote:
 
 
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, July 09, 2013 11:22 AM
> To: Edison Su
> Cc: 
> Subject: Re: Swift in 4.2 is broken, anybody wants it to be
>>> supported in 4.2?
> 
> On Tue, Jul 09, 2013 at 06:12:22PM +, Edison Su wrote:
>> If it's ok to use S3 api talking to swift, then there is zero
>> effort to support
> Swift.
>> But who will make the decision?
> 
> We, as a community.  It's *always* that answer.
> 
> If you are proposing this as the corrective path, then ok...  let's
> see if others have opinions about this though.
> 
> Heres how I see it:
> 
> Pros -
> * Code within the master branch has functional S3 API support
> * We seem to have more contribution around this interface spec
> * Having S3 as the only non-NFS secondary storage API reduces the
>   long-term support / test efforts
> 
> Cons -
> * We may have an expectation issue for existing users that only
>>> have the
>   native Swift API enabled in their environment (although I'm not
>>> aware
>   of the Swift API's stability between their releases)
 
 I think you get into the same situation as I did, without input from
>>> users who is using Swift, or the company who is supporting Swift, what
>>> we are talking about here is just hypothetic.
 If we really want to support Swift, and support it better, we need to
>>> get domain expert involved in the discuss.
>>> 
>>> Does your $dayjob happen to have a customer that might be using this
>>> integration?  If so, could your $dayjob product manager chime in on the
>>> discussion?
>>> 
>> [Animesh>] I followed up with $dayjob product manager, there was a
>> customer who was interested in this integration a

RE: Error Message: Cloud Stack

Maurice,

You should check the logs before this exception trace is logged, just follow 
the consoleproxy-1 thread to see what went wrong in the deployment process.

-Prachi

-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com] 
Sent: Wednesday, July 10, 2013 6:59 AM
To: dev@cloudstack.apache.org
Subject: Re: Error Message: Cloud Stack

You can use NFS with a single server, but if you choose local storage instead, 
you need to go into the global options and tell system vms to use local 
storage. Parameter "system.vm.use.local.storage". I'm not sure that's the 
problem, but somewhere in the log it may lead you to why there is no server 
capacity, whether the agent isn't running (hence no hosts), or some other 
mismatch.

On Tue, Jul 9, 2013 at 10:52 PM, Maurice Lawler  wrote:
> Thank you!
>
> This is being deployed on a single machine utilizing KVM as the hypervisor. 
> This is also my attempt at setting it up under Advanced Networking, with the 
> plans later to add additional servers; just wanted to toy with this server. 
> Should the storage not be NFS since its local? As there is an option at the 
> start of the set up.
>
> Marcus Sorensen  wrote:
>
>>InsufficientServerCapacity = You didn't have enough resources to 
>>launch the VM. It can be due to out of memory on hosts, out of CPU, or 
>>not able to find storage.  Sometimes this is just due to a mismatch in 
>>service offerings. For example, often in a dev environment you just 
>>set up a local primary storage, but all service offerings reference 
>>shared primary storage, therefore the system can not find a place 
>>matching it's requirements on which to run the VMs.
>>
>>On Tue, Jul 9, 2013 at 10:26 PM, Maurice Lawler  wrote:
>>> I have started my cloudstack in advanced mode, however, during the 
>>> process I am seeing this:
>>>
>>>
>>>
>>> 2013-07-09 23:23:55,920 DEBUG [cloud.capacity.CapacityManagerImpl]
>>> (consoleproxy-1:null) release cpu from host: 1, old used: 
>>> 500,reserved: 0, actual total: 36256, total with overprovisioning: 36256; 
>>> new used:
>>> 0,reserved:0; movedfromreserved: false,moveToReserveredfalse
>>> 2013-07-09 23:23:55,920 DEBUG [cloud.capacity.CapacityManagerImpl]
>>> (consoleproxy-1:null) release mem from host: 1, old used:
>>> 1073741824,reserved: 0, total: 25186906112; new used: 0,reserved:0;
>>> movedfromreserved: false,moveToReserveredfalse
>>> 2013-07-09 23:23:55,922 WARN  
>>> [cloud.consoleproxy.ConsoleProxyManagerImpl]
>>> (consoleproxy-1:null) Exception while trying to start console proxy
>>> com.cloud.exception.InsufficientServerCapacityException: Unable to 
>>> create a deployment for VM[ConsoleProxy|v-2-VM]Scope=interface
>>> com.cloud.dc.DataCenter; id=1
>>> at
>>> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineMa
>>> nagerImpl.java:728)
>>> at
>>> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerIm
>>> pl.java:471)
>>> at
>>> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerIm
>>> pl.java:464)
>>> at
>>> com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsolePro
>>> xyManagerImpl.java:632)
>>> at
>>> com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(Console
>>> ProxyManagerImpl.java:1166)
>>> at
>>> com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsolePro
>>> xyManagerImpl.java:1989)
>>> at
>>> com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsolePro
>>> xyManagerImpl.java:175) at 
>>> com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:1
>>> 11) at 
>>> com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java
>>> :33) at 
>>> com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.jav
>>> a:81) at 
>>> com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72)
>>> at 
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:4
>>> 71)
>>> at
>>> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.jav
>>> a:351) at 
>>> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
>>> .access$201(ScheduledThreadPoolExecutor.java:165)
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
>>> .run(ScheduledThreadPoolExecutor.java:267)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor
>>> .java:1146)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto
>>> r.java:615) at java.lang.Thread.run(Thread.java:679)
>>> 2013-07-09 23:23:58,720 DEBUG
>>> [storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:null) 
>>> Zone 1 is ready to launch secondary storage VM
>>>
>>>
>>> What does this mean?
>>>
>>> - Maurice

Re: Dublin meetup tonight


On 10 Jul 2013, at 17:08, Joe Brockmeier  wrote:

> On Wed, Jul 10, 2013, at 06:38 AM, Sebastien Goasguen wrote:
>> To all dubliners out there, meetup tonight:
> 
> I tweeted this from the CloudStack account. Happy to add these to our
> social media for promotion ahead of time if folks send a note to
> marketing@ with the full info... 
> 
> Best,

I have been tweeting it for a while now and also sent emails.



> 
> jzb
> -- 
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/

Re: Review Request 12445: Making sdn gre work with XCP 1.6

2013-07-10 Thread Rajesh Battala


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



plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java


there are many white space/tabs in java and py files.

can you please post what kind of testing/test cases executed for this patch.


- Rajesh Battala


On July 10, 2013, 3:31 p.m., tuna wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12445/
> ---
> 
> (Updated July 10, 2013, 3:31 p.m.)
> 
> 
> Review request for cloudstack, Sebastien Goasguen and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch makes sdn gre work with XCP 1.6. Users still can follow the old 
> strategy described in this post: 
> https://cwiki.apache.org/CLOUDSTACK/ovs-tunnel-manager-for-cloudstack.html. 
> 
> Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-1779
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  d6d0523 
>   scripts/vm/hypervisor/xenserver/ovstunnel ddcaa5b 
>   scripts/vm/hypervisor/xenserver/xcposs/patch 4d07c76 
>   scripts/vm/hypervisor/xenserver/xcpserver/patch 7e92d5a 
>   scripts/vm/hypervisor/xenserver/xenserver56/patch 8abd6b2 
>   scripts/vm/hypervisor/xenserver/xenserver56fp1/patch 901f6de 
> 
> Diff: https://reviews.apache.org/r/12445/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> tuna
> 
>

Re: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?

I like,

thanks for starting this discussion.
Please ignore the rest of this mail as it is not of any consequence.

As a folowup, I would like ti propose to move any peace of code to branches
if it meets the  qualifications you mention; not (full) functional, not
production ready. And i would like to add not fully tested an not fully
tested. Ofcourse we can only migrate in that dirrection, unfortunately. As
a newbee on this codebase it would help a lot knowing that any code on
master is actually functional. Meaning that coveragetests could help. This
is me@devchair talking, i will probably be countered by collegues having
real user issues.
This is also an incentive to document and test, for those rhat want to
guard their niche functionality and an incentive to isolate code for easy
cherrypicking whilst not done.
Hi all,

So we've run into a couple of features that have turned out to have
never really been "production grade", perhaps due to their creation as
prototypes during the cloud.com startup period.  Swift, Bare metal
provisioning and OVM are examples.  Bare metal is obviously resolved
now, but Swift is an open discussion and OVM remains open for someone to
decide to fix it.

I'd like to propose that those devs that have been around this code-base
from before it's entry into Apache take some time to review things from
the past.  What else is lurking in the repo that some of us might
*think* are functional, but that haven't been tested in years?  What
code was a prototype that never got fully implemented / supported?

If we can get all this out in the open, perhaps we can have a solid
foundation to move forward.

On the other hand, if nobody has any examples beyond the ones listed
below, then I think that those of us that are relatively new to the code
will have to work under the assumption that everything is expected to be
functional.

After we establish our foundation, we will need to be very consistent
about our support of the features.  We'll need to be clear about
intentions to deprecate something, and perhaps even provide a full
feature release cycle worth of warning about a pending deprecation.

As a user, I not been stung by a feature that was yanked... but I was
certainly surprised when I found out that OVM and Bare Metal weren't
being kept up to date (again, bare metal is resolved now).  Those
features were part of our evaluation of the software, and me $dayjob has
plans to at least use bare metal.

So why did I share that little story?  Well, it's because features
coming and going are actually significant events to users of the
software.  Just because we don't know of someone using a feature doesn't
mean that it isn't in use.  I'd like us to have that solid foundation as
a start, and then be very clear when we need/want to make a decision
that removes a feature from the software.

-chip

Re: org.apache.hypervisor.kvm.resource.LibvirtComputingResourceTest Failure

I understand, so either change the checker (as i sugested) or change the
expected result in the testcase.
Op 10 jul. 2013 15:37 schreef "Dharmesh Kakadia"  het
volgende:

> @chip and @Daan Thanks for the reply.
>
> I think there is some misunderstanding. The test case is not written by me.
> It is failing on an already existing test case after I did refactoring,
> which is why I am worried.
>
> Thanks,
> Dharmesh
>
>
> On Wed, Jul 10, 2013 at 6:55 PM, Chip Childers  >wrote:
>
> > On Wed, Jul 10, 2013 at 03:01:35PM +0200, Daan Hoogland wrote:
> > > I would not bother to look at it, if I were your, Dharmesh. Find a good
> > > lightweigth xmlunit-like tool or  another xml comaparison tool to do
> the
> > > checking. parsers and dom generators can do whatever they like with
> > > attribute order. I would say not with element order, but still trying
> to
> > > make the xml (un)marshalling do exactly what you want is not worth your
> > > time.
> > >
> > > regards,
> > > Daan
> >
> > +1 to what Daan says.  The XML specification doesn't require any parsers
> > to maintain the exact same text representation of the XML data after
> > it's been parsed and subsequently dumped.  It only has to be the same
> > *data*.
> >
> > >
> > >
> > >
> > > On Wed, Jul 10, 2013 at 8:11 AM, Dharmesh Kakadia  > >wrote:
> > >
> > > > Hi,
> > > >
> > > > I am trying to re-factor com.cloud to org.apache. While doing so 2
> test
> > > > cases in
> > org.apache.hypervisor.kvm.resource.LibvirtComputingResourceTest
> > > > are failing and after trying for 2 days I have no idea why.
> > > >
> > > > Output of build is here http://apaste.info/8Tio
> > > >
> > > > From the output its clear that both the xml strings in test are same,
> > but
> > > > the elemenets are in diffrent order and thus string comparision
> fails.
> > Can
> > > > anyone point out why they are coming in different order ?
> > > >
> > > > Thanks,
> > > > Dharmesh
> > > >
> >
>

CloudStack Weekly News - 10 July 2013

(Note: Sending this to the mailing lists as blogs.apache.org is down for
the moment.)

The community is busy working on 4.2.0, and there's much to be done
before the release is ready. This week, we're taking a look at some of
the interesting discussions going on in the the community about the
next generation of Apache CloudStack, and functionality we can provide,
as well as procedural changes that everyone should be aware of.

## News Moving to Wednesdays

To help get information out a little more timely to key discussions and
information that is going on in the community we are going to move the
publishing of the weekly news to Wednesdays, starting with this issue
on July 10th! If you'd like to help put the news together, please sign
up for the market...@cloudstack.apache.org mailing list and ask how you
can get involved!

## Major Discussions

In this section we look at major discussions that have happened on the
CloudStack mailing lists. This is by no means a full summary of all
discussions on the lists, but we try to hit the highlights that are
relevant to the larger CloudStack community.

### 4.2 Status Update

Animesh Chaturvedi is tracking the [1]current status of the release.
Testing, bug fix work, and documentation should be targeted to complete
by code freeze on 7/28. Release is still on schedule to release by
8/19.

We are now just 3 weeks from ACS 4.2 code freeze on 7/29. We have
around 400 open defects with 100+ blockers and critical and I expect
another 200 new defects to come in. As a community we have been
fixing roughly 100 defects per week, in order to clear up our
backlog I request you to help out on aggressively fixing the issues.
The unassigned issue list is available at
[2]http://s.apache.org/BlH/. When you fix a bug in 4.2 please make
sure it is also fixed in master.

Given the debate on system template changes in last few days of 4.1
requiring big testing effort and potential regression, I would like
to see that as community we lock down system templates for 4.2
pretty soon. If any changes are needed we should call it out now and
get them resolved.

As for bugs here is a summary for this week:

Bugs This Week Last Week
Blocker Critical Major Total Blocker Critical Major Total
Incoming 8 10 28 50 11 34 24 72
Outgoing 26 23 34 86 26 30 40 100
Open Unassigned 7 49 129 222 6 49 119 184
Open Total 25 84 232 403 25 80 218 385

The status for features or improvement is depicted in table below

New Features / Improvements Today Last Week
Closed 10 10
Resolved 59 57
In Progress 11 13
Reopened 1 1
Ready To Review 1 1
Open 20 20
Total 102 102

### Swift Support in 4.2

On July 3rd, Edison Su reported that [3]support for Swift is broken due
to the object store refactor. There's been a fair amount of discussion
on how an extant feature could be broken without being exposed via
testing, and what should be done about it at this stage.

David Nalley says that "unplanned/unannounced deprecation of a feature
is a blocker IMO. It engenders a bad relationship with our users, and
strands them on previous versions with no good migration/upgrade path."
Chip Childers [4]says that "I believe that this was an honest mistake,
but we need to figure out what to do. I'm -1 on us saying 'we'll drop
Swift support'. If necessary, I'd say that we need to roll back the
object-store branch merge... I don't want to see that happen, though.
That's why I'm asking about the effort to fix it."

Chip [5]opened CLOUDSTACK-3400 as a blocker against 4.2 until Swift
support is fixed. Discussion about the bug continues.

### Closing 4.2 Resolved Defects

Sudha Ponnaganti [6]posted a list of 543 defects that are in resolved
state that need to re-validated, reopened or closed. Please look
through this list and check to see if you're assigned to any of these
defects.

There are 543 defects in Resolved state and not closed. Please make
sure that you validate and close the defect if you are satisfied
with the fix. If there are issues with the fix, pl reopen the
defect. Pl note that these need to be validated in 4.2 branch as all
are fixed in 4.2 ( should be applicable for master as well). You can
prioritize these based on the blocker, critical, major etc. As team
is already done with the features, this is good time to close
these...

### Coding Convention Reminder

As open source projects mature and add new participants, it's
occasionally necessary to send a gentle reminder of accepted
conventions in the community. For example, Alex Huang [7]opened a
discussion about the CloudStack codi

IRC Meeting (10 July 2013)

No meeting today, as we had only four people show up. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

[GSOC] ldap feature branch

Hi,

FYI: I created a ldapplugin feature branch for Ian to commit his patches in.

Cheers,

-Sebastien

Re: Review Request 12273: Cloudstack-2150 DB table entries of phisical network is not proper.Shows Duplicate entries Cloudstack-2980 Adding a VLAN range that overlaps with two existing ranges results

2013-07-10 Thread bharat kumar


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

(Updated July 10, 2013, 5:43 p.m.)


Review request for cloudstack and Abhinandan Prateek.


Changes
---

updated and rebased the code with master-stable


Bugs: Cloudstack-2150 and Cloudstack-2980


Repository: cloudstack-git


Description
---

Cloudstack-2150 DB table entries of phisical network is not proper.Shows 
Duplicate entries Cloudstack-2980 Adding a
VLAN range that overlaps with two existing ranges results inconsistent DB 
entries
This fix was causing a regression due to which the state of the physical 
network was not getting updated and as a result basic zone deployment failed. 
Resubmitting the fixed code.


Diffs (updated)
-

  engine/schema/src/com/cloud/dc/dao/DataCenterDao.java ed6e696 
  engine/schema/src/com/cloud/dc/dao/DataCenterDaoImpl.java 503306f 
  engine/schema/src/com/cloud/dc/dao/DataCenterVnetDao.java 778498d 
  engine/schema/src/com/cloud/dc/dao/DataCenterVnetDaoImpl.java e97f2c6 
  server/src/com/cloud/network/NetworkServiceImpl.java 49bfb88 
  server/test/com/cloud/network/UpdatePhysicalNetworkTest.java 25c023e 

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


Testing
---

Tested 
basic zone deployment.
adding vlan
removing vlan
removing all vlan
checked if all the added vlans are in the db.


Thanks,

bharat kumar

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

On Wed, Jul 10, 2013, at 10:52 AM, Caleb Call wrote:
> Although my voice doesn't mean a lot, I too would vote this as
> a blocker.  If it's going to be dropped, users need to be notified well
> in advanced so they can be make plans moving forward instead of suddenly
> being stranded on an out-dated version.

Your voice does mean a lot, thanks for speaking up. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

On Wed, Jul 10, 2013, at 08:40 AM, Chip Childers wrote:
> Based on CLOUDSTACK-3350, we have a known user.  IMO, this should be a
> blocker.  We should either fix Swift to support users or revert the
> object store branch merge changes.

+1 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Review Request 11649: CLOUDSTACK-1768: Ability to delete Events and Alerts: Delete by a time period is required.

2013-07-10 Thread Sanjay Tripathi


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

(Updated July 10, 2013, 5:50 p.m.)


Review request for cloudstack and Devdeep Singh.


Changes
---

Resolved conflicts with the latest master code.


Bugs: CLOUDSTACK-1768


Repository: cloudstack-git


Description
---

CLOUDSTACK-1768: Ability to delete Events and Alerts: Delete by a time period 
is required.

Under this improvement, archive/deletion of alerts and events by time period 
i.e. with startdate and enddate is required.

Removed parameter "olderthan" and added new params "startdate" and "enddate" in 
the following APIs:
archiveEvents
deleteEvents
archiveAlerts
deleteAlerts


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java e2857b8 
  
api/src/org/apache/cloudstack/api/command/admin/resource/ArchiveAlertsCmd.java 
2a1a47a 
  api/src/org/apache/cloudstack/api/command/admin/resource/DeleteAlertsCmd.java 
f03793c 
  api/src/org/apache/cloudstack/api/command/user/event/ArchiveEventsCmd.java 
481607c 
  api/src/org/apache/cloudstack/api/command/user/event/DeleteEventsCmd.java 
a03e6d9 
  engine/schema/src/com/cloud/alert/dao/AlertDao.java fda814d 
  engine/schema/src/com/cloud/alert/dao/AlertDaoImpl.java 18115a5 
  engine/schema/src/com/cloud/event/dao/EventDao.java 9454ce7 
  engine/schema/src/com/cloud/event/dao/EventDaoImpl.java cefe107 
  server/src/com/cloud/api/ApiDispatcher.java b7d08e2 
  server/src/com/cloud/server/ManagementServerImpl.java da9d6a2 
  server/test/com/cloud/alert/AlertControlsUnitTest.java c1e4c54 
  server/test/com/cloud/event/EventControlsUnitTest.java e2a86cd 

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


Testing
---

Tested and verified the result of all the four APIs with the different 
combinations and inputs of startdate and enddate in my local CloudStack setup.


Thanks,

Sanjay Tripathi

Re: Review Request 11910: Fix for CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable dynamic scaling of vm

2013-07-10 Thread ASF Subversion and Git Services


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


Commit f7f826d4f516144069e26b3bb112e8c22414123e in branch refs/heads/master 
from Jessica Wang
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f7f826d ]

CLOUDSTACK-2987: UI > Templates menu > register template action: add 
Dynamically Scalable field.


- ASF Subversion and Git Services


On June 20, 2013, 5:19 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11910/
> ---
> 
> (Updated June 20, 2013, 5:19 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Nitin Mehta.
> 
> 
> Bugs: CLOUDSTACK-2987 and CLOUDSTACK-3042
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable 
> dynamic scaling of vm 
> 
> CLOUDSTACK-3042 - handle Scaling up of vm memory/CPU based on the presence of 
> XS tools in the template
> This should also take care of updation of VM after XS tools are installed in 
> the vm and set memory values accordingly to support dynamic scaling after 
> stop start of VM
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/template/VirtualMachineTemplate.java cedc793 
>   api/src/com/cloud/vm/VirtualMachine.java ce9add6 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 12e5097 
>   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 6fd9773 
>   api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java 
> 284d553 
>   
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
>  c9da0c2 
>   api/src/org/apache/cloudstack/api/command/user/vm/UpdateVMCmd.java 2860283 
>   api/src/org/apache/cloudstack/api/response/TemplateResponse.java ed933ff 
>   api/src/org/apache/cloudstack/api/response/UserVmResponse.java 5b71ba2 
>   core/src/com/cloud/agent/api/ScaleVmCommand.java b361485 
>   engine/schema/src/com/cloud/storage/VMTemplateVO.java e643d75 
>   engine/schema/src/com/cloud/vm/VMInstanceVO.java fbe03dc 
>   
> engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java
>  4d162bb 
>   plugins/hypervisors/xen/src/com/cloud/hypervisor/XenServerGuru.java 8c38a69 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  5e8283a 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
>  8e37809 
>   server/src/com/cloud/api/ApiResponseHelper.java 7ffa30f 
>   server/src/com/cloud/api/query/dao/UserVmJoinDaoImpl.java f9877ab 
>   server/src/com/cloud/api/query/vo/UserVmJoinVO.java c97d71a 
>   server/src/com/cloud/hypervisor/HypervisorGuruBase.java 1ad9a1f 
>   server/src/com/cloud/server/ManagementServerImpl.java cfc8333 
>   server/src/com/cloud/storage/TemplateProfile.java 0b55f1f 
>   server/src/com/cloud/template/TemplateAdapter.java 9a2d877 
>   server/src/com/cloud/template/TemplateAdapterBase.java 0940d3e 
>   server/src/com/cloud/vm/UserVmManagerImpl.java e8ea024 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 5814075 
>   server/test/com/cloud/vm/VirtualMachineManagerImplTest.java 8715c9e 
>   setup/db/db/schema-410to420.sql c782234 
> 
> Diff: https://reviews.apache.org/r/11910/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

RE: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

2013-07-10 Thread Edison Su

1. Add swift back is just one or two days work, plus maybe one or two days, to 
setup a swift environment.
2. There is no single user from the "group of swift users" jumping into the 
thread. Do they really care about this feature?
3. If we add this feature back, will we test it for each release? Such as 
adding it into automate test? Right now, I break this feature, I am pretty 
sure, it will be broken by other developers, if we continue adding feature 
without test.
4.  Claim a feature is supported for each release without test, is worse than 
saying not supported a feature. If we want to support a feature, we should test 
it for each release. If so, who will want to test this feature?

> -Original Message-
> From: Caleb Call [mailto:calebc...@me.com]
> Sent: Wednesday, July 10, 2013 8:53 AM
> To: dev@cloudstack.apache.org
> Cc: Edison Su
> Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?
> 
> It's decisions like this (dropping a previously advertised supported feature
> simply because it wasn't tested) are part of the reasons that have changed
> our plan to use Cloudstack in our corporate environment.  I'm glad to see
> Chip, David, and others pushing back on the decision to just drop it and fix 
> it
> in the next dot release (same story as OVM, go back and read the discussions
> on the choice to drop it and they sound identical to what you're saying) which
> generally means it's getting dropped for good.  It doesn't matter if the
> feature currently works or not or if it's been tested in a while or not, it's 
> being
> advertised as being supported and people/companies make plans based on
> those supported features.  Although my voice doesn't mean a lot, I too
> would vote this as a blocker.  If it's going to be dropped, users need to be
> notified well in advanced so they can be make plans moving forward instead
> of suddenly being stranded on an out-dated version.
> 
> 
> On Jul 9, 2013, at 6:39 PM, Mathias Mullins 
> wrote:
> 
> > I've been watching from the outside and tracking the entire
> > discussion, and with what has happened with the delays with 4.0 and
> > 4.1 am worried that this could be come the next delayer to the release
> > of 4.2. At the same time, I'm very much in agreement with David N.,
> > Chip and John B. that we can't just drop a feature because it hasn't
> > been attiquately tested in that past releases.
> >
> > My observations -
> > 1. There is not a quick fix here.
> > 2. We don't know who can do it.
> > 3. We're not sure how to do it properly 4. Currently we can't even
> > agree on whether we go with the original version or the newer one.
> > 5. We can't validate user base immediate need and requirement for the
> > feature.
> > 6. We're stuck in Analysis paralysis!
> >
> > Conclusion - If we don't get past these in short order we are going to
> > jeopardize 4.2 timely release.
> >
> > Suggestion:
> > Based off my work with other (corporate) software releases, if we
> > can't validate the immediate need, we don't know the immediate fix,
> > and we don't have the right people to do it should we slate this for
> > 4.2.1 and lower this to a Major for 4.2? We don't delay a major
> > release, and at the same time we dedicate ourselves to not stranding a
> > user. We need to do this, but at this point we need to do it right for that
> user base too.
> >
> > We work to fix the previous version and we work to support new versions.
> > We get the right resources in to assist, and we make it an immediate
> > priority to address. If we can fix and test properly before the cut of
> > 4.2, WONDERFUL! If not, then it doesn't block the release, but it goes
> > out with 4.2.1 asap.
> >
> > So there's my ramblings. How far off base am I? :-)
> >
> > Ready, setŠ fire!
> > Matt
> >
> >
> >
> > On 7/9/13 5:23 PM, "Animesh Chaturvedi"
> > 
> > wrote:
> >
> >>
> >>
> >>> -Original Message-
> >>> From: Chip Childers [mailto:chip.child...@sungard.com]
> >>> Sent: Tuesday, July 09, 2013 11:57 AM
> >>> To: Edison Su
> >>> Cc: 
> >>> Subject: Re: Swift in 4.2 is broken, anybody wants it to be
> >>> supported in 4.2?
> >>>
> >>> On Tue, Jul 09, 2013 at 06:55:03PM +, Edison Su wrote:
> 
> 
> > -Original Message-
> > From: Chip Childers [mailto:chip.child...@sungard.com]
> > Sent: Tuesday, July 09, 2013 11:22 AM
> > To: Edison Su
> > Cc: 
> > Subject: Re: Swift in 4.2 is broken, anybody wants it to be
> >>> supported in 4.2?
> >
> > On Tue, Jul 09, 2013 at 06:12:22PM +, Edison Su wrote:
> >> If it's ok to use S3 api talking to swift, then there is zero
> >> effort to support
> > Swift.
> >> But who will make the decision?
> >
> > We, as a community.  It's *always* that answer.
> >
> > If you are proposing this as the corrective path, then ok...
> > let's see if others have opinions about this though.
> >
> > Heres how I see it:
> >
> > Pros -
> > * C

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

I wonder if this Swift-support question has gone out to the CloudStack
users e-mail list for opinions?


On Wed, Jul 10, 2013 at 12:13 PM, Edison Su  wrote:

> 1. Add swift back is just one or two days work, plus maybe one or two
> days, to setup a swift environment.
> 2. There is no single user from the "group of swift users" jumping into
> the thread. Do they really care about this feature?
> 3. If we add this feature back, will we test it for each release? Such as
> adding it into automate test? Right now, I break this feature, I am pretty
> sure, it will be broken by other developers, if we continue adding feature
> without test.
> 4.  Claim a feature is supported for each release without test, is worse
> than saying not supported a feature. If we want to support a feature, we
> should test it for each release. If so, who will want to test this feature?
>
> > -Original Message-
> > From: Caleb Call [mailto:calebc...@me.com]
> > Sent: Wednesday, July 10, 2013 8:53 AM
> > To: dev@cloudstack.apache.org
> > Cc: Edison Su
> > Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in
> 4.2?
> >
> > It's decisions like this (dropping a previously advertised supported
> feature
> > simply because it wasn't tested) are part of the reasons that have
> changed
> > our plan to use Cloudstack in our corporate environment.  I'm glad to see
> > Chip, David, and others pushing back on the decision to just drop it and
> fix it
> > in the next dot release (same story as OVM, go back and read the
> discussions
> > on the choice to drop it and they sound identical to what you're saying)
> which
> > generally means it's getting dropped for good.  It doesn't matter if the
> > feature currently works or not or if it's been tested in a while or not,
> it's being
> > advertised as being supported and people/companies make plans based on
> > those supported features.  Although my voice doesn't mean a lot, I too
> > would vote this as a blocker.  If it's going to be dropped, users need
> to be
> > notified well in advanced so they can be make plans moving forward
> instead
> > of suddenly being stranded on an out-dated version.
> >
> >
> > On Jul 9, 2013, at 6:39 PM, Mathias Mullins 
> > wrote:
> >
> > > I've been watching from the outside and tracking the entire
> > > discussion, and with what has happened with the delays with 4.0 and
> > > 4.1 am worried that this could be come the next delayer to the release
> > > of 4.2. At the same time, I'm very much in agreement with David N.,
> > > Chip and John B. that we can't just drop a feature because it hasn't
> > > been attiquately tested in that past releases.
> > >
> > > My observations -
> > > 1. There is not a quick fix here.
> > > 2. We don't know who can do it.
> > > 3. We're not sure how to do it properly 4. Currently we can't even
> > > agree on whether we go with the original version or the newer one.
> > > 5. We can't validate user base immediate need and requirement for the
> > > feature.
> > > 6. We're stuck in Analysis paralysis!
> > >
> > > Conclusion - If we don't get past these in short order we are going to
> > > jeopardize 4.2 timely release.
> > >
> > > Suggestion:
> > > Based off my work with other (corporate) software releases, if we
> > > can't validate the immediate need, we don't know the immediate fix,
> > > and we don't have the right people to do it should we slate this for
> > > 4.2.1 and lower this to a Major for 4.2? We don't delay a major
> > > release, and at the same time we dedicate ourselves to not stranding a
> > > user. We need to do this, but at this point we need to do it right for
> that
> > user base too.
> > >
> > > We work to fix the previous version and we work to support new
> versions.
> > > We get the right resources in to assist, and we make it an immediate
> > > priority to address. If we can fix and test properly before the cut of
> > > 4.2, WONDERFUL! If not, then it doesn't block the release, but it goes
> > > out with 4.2.1 asap.
> > >
> > > So there's my ramblings. How far off base am I? :-)
> > >
> > > Ready, setŠ fire!
> > > Matt
> > >
> > >
> > >
> > > On 7/9/13 5:23 PM, "Animesh Chaturvedi"
> > > 
> > > wrote:
> > >
> > >>
> > >>
> > >>> -Original Message-
> > >>> From: Chip Childers [mailto:chip.child...@sungard.com]
> > >>> Sent: Tuesday, July 09, 2013 11:57 AM
> > >>> To: Edison Su
> > >>> Cc: 
> > >>> Subject: Re: Swift in 4.2 is broken, anybody wants it to be
> > >>> supported in 4.2?
> > >>>
> > >>> On Tue, Jul 09, 2013 at 06:55:03PM +, Edison Su wrote:
> > 
> > 
> > > -Original Message-
> > > From: Chip Childers [mailto:chip.child...@sungard.com]
> > > Sent: Tuesday, July 09, 2013 11:22 AM
> > > To: Edison Su
> > > Cc: 
> > > Subject: Re: Swift in 4.2 is broken, anybody wants it to be
> > >>> supported in 4.2?
> > >
> > > On Tue, Jul 09, 2013 at 06:12:22PM +, Edison Su wrote:
> > >> If it's ok to use S3 api talking to swift, th

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

On Wed, Jul 10, 2013 at 06:13:07PM +, Edison Su wrote:
> 2. There is no single user from the "group of swift users" jumping into the 
> thread. Do they really care about this feature?

This is a developer list.  Even our users don't have to be on the users
list.  We have at least one known user at the moment, who happens to be
on the 4.x line.  The nature of open source projects (that don't suck)
is that they *assume* users are using the features that exist in the
product, and only remove them when they have (1) a really good reason
and (2) give deprecation warnings.

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

On Wed, Jul 10, 2013 at 06:13:07PM +, Edison Su wrote:
> 1. Add swift back is just one or two days work, plus maybe one or two days, 
> to setup a swift environment.

Great!

> 3. If we add this feature back, will we test it for each release? Such as 
> adding it into automate test? Right now, I break this feature, I am pretty 
> sure, it will be broken by other developers, if we continue adding feature 
> without test.

Then let's test it until such time that we actually agree to deprecate
it (if that ever happens).

> 4.  Claim a feature is supported for each release without test, is worse than 
> saying not supported a feature. If we want to support a feature, we should 
> test it for each release. If so, who will want to test this feature?

As stated earlier, we have a user that's volunteered to test it out for
us already.

Using VMware from CloudStack

Hi,

I've been primarily working on the 4.2 branch as of late and was setting up
a VMware cluster for the first time in a while.

I noticed from an error message that before I can set up a cluster based on
VMware that I must add the VMware Datacenter to the Zone. I went ahead and
did this.

I then came back to the Add Cluster dialog and am wondering why at this
point we ask for the vCenter host, username, password, and datacenter. It
would seem I already filled in this info when I associated the VMware
Datacenter to the Zone. Am I missing something here?

Thanks for filling me in on this!

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*™*

Re: HA for VMWare

2013-07-10 Thread Jörgen Maas

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: Using VMware from CloudStack

2013-07-10 Thread Ahmad Emneina

one typically adds a cluster during zone creation or adds the cluster as a
unit (which maps to the vmware dc/cluster). I believe at the cluster
addition phase, is where you should be prompted for credentials. Give that
a try, see if you get any miles out of that.


On Wed, Jul 10, 2013 at 12:35 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> I've been primarily working on the 4.2 branch as of late and was setting up
> a VMware cluster for the first time in a while.
>
> I noticed from an error message that before I can set up a cluster based on
> VMware that I must add the VMware Datacenter to the Zone. I went ahead and
> did this.
>
> I then came back to the Add Cluster dialog and am wondering why at this
> point we ask for the vCenter host, username, password, and datacenter. It
> would seem I already filled in this info when I associated the VMware
> Datacenter to the Zone. Am I missing something here?
>
> Thanks for filling me in on this!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*
>

Re: HA for VMWare

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: Using VMware from CloudStack

Hi Ahmad,

Yeah, it seems to ask for vCenter credentials both when adding the VMware
Datacenter to the Zone and when creating a CS Cluster based on a VMware
Cluster.

Interesting


On Wed, Jul 10, 2013 at 2:02 PM, Ahmad Emneina  wrote:

> one typically adds a cluster during zone creation or adds the cluster as a
> unit (which maps to the vmware dc/cluster). I believe at the cluster
> addition phase, is where you should be prompted for credentials. Give that
> a try, see if you get any miles out of that.
>
>
> On Wed, Jul 10, 2013 at 12:35 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Hi,
> >
> > I've been primarily working on the 4.2 branch as of late and was setting
> up
> > a VMware cluster for the first time in a while.
> >
> > I noticed from an error message that before I can set up a cluster based
> on
> > VMware that I must add the VMware Datacenter to the Zone. I went ahead
> and
> > did this.
> >
> > I then came back to the Add Cluster dialog and am wondering why at this
> > point we ask for the vCenter host, username, password, and datacenter. It
> > would seem I already filled in this info when I associated the VMware
> > Datacenter to the Zone. Am I missing something here?
> >
> > Thanks for filling me in on this!
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *™*
> >
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*™*

Storage Allocator Question

Hi,

I have a question about how current storage allocators work.

Let's say I have two primary storages with the same storage tag.

If I execute compute and disk offerings that reference that storage tag
only, will one primary storage be (essentially) filled up before the other
is utilized or do we have an allocator that performs round-robin placement?

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
*™*

RE: Storage Allocator Question

Currently for storage allocators, only random or firstfit or user-dispersing 
strategies are present. This is governed by the 'vm.allocation.algorithm' 
global config.
So for you case with storage tags, if you choose random, either of the pools 
can get chosen. For firstfit, you will mostly see one pool getting filled up 
first and then the other.

There is no round-robin implementation in place. 'User-dispersing' may provide 
it to some effect if you are using a single account, since it always chooses a 
pool having less number of volumes for a given account.

-Prachi

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Wednesday, July 10, 2013 1:34 PM
To: dev@cloudstack.apache.org
Subject: Storage Allocator Question

Hi,

I have a question about how current storage allocators work.

Let's say I have two primary storages with the same storage tag.

If I execute compute and disk offerings that reference that storage tag only, 
will one primary storage be (essentially) filled up before the other is 
utilized or do we have an allocator that performs round-robin placement?

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: Storage Allocator Question

Oh, when you say "random," does that mean random among the storage pools
that have, say, the necessary storage tag or does random ignore storage
tags?

Thanks


On Wed, Jul 10, 2013 at 2:43 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> OK, thanks!
>
>
> On Wed, Jul 10, 2013 at 2:40 PM, Prachi Damle wrote:
>
>> Currently for storage allocators, only random or firstfit or
>> user-dispersing strategies are present. This is governed by the
>> 'vm.allocation.algorithm' global config.
>> So for you case with storage tags, if you choose random, either of the
>> pools can get chosen. For firstfit, you will mostly see one pool getting
>> filled up first and then the other.
>>
>> There is no round-robin implementation in place. 'User-dispersing' may
>> provide it to some effect if you are using a single account, since it
>> always chooses a pool having less number of volumes for a given account.
>>
>> -Prachi
>>
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: Wednesday, July 10, 2013 1:34 PM
>> To: dev@cloudstack.apache.org
>> Subject: Storage Allocator Question
>>
>> Hi,
>>
>> I have a question about how current storage allocators work.
>>
>> Let's say I have two primary storages with the same storage tag.
>>
>> If I execute compute and disk offerings that reference that storage tag
>> only, will one primary storage be (essentially) filled up before the other
>> is utilized or do we have an allocator that performs round-robin placement?
>>
>> 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
> *™*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*™*

RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?

Thanks Chip for starting this thread.

I can at least think of the netapp plugin integration as something that was 
tried before ASF but no longer tested and used.

I'm all for coming up with this list but I don't see how this list can be 
conclusive.  The problem that Edison dealt with in swift support is very real.  
I'm not trying to make an excuse for making a unilateral decision to drop 
support without getting community feedback first.  That is wrong and I'm glad 
it's being resolved.  However, without automated testing backing functionality, 
we can have different set of these problems pop up every release.  Should we 
start with only functionalities tested in automated testing to be the supported 
feature set and add features back in as more testing is added back in? 

To that end, how much of 4.0/4.1/4.2 features are actually added to automated 
testing?  Or else we can face the same problem with those features too.

I still support gathering this list, even if it might be inconclusive. 

--Alex

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Wednesday, July 10, 2013 6:23 AM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] What other "features" or code is sitting around that might
> be suffering from bit rot?
> 
> Hi all,
> 
> So we've run into a couple of features that have turned out to have never
> really been "production grade", perhaps due to their creation as prototypes
> during the cloud.com startup period.  Swift, Bare metal provisioning and
> OVM are examples.  Bare metal is obviously resolved now, but Swift is an
> open discussion and OVM remains open for someone to decide to fix it.
> 
> I'd like to propose that those devs that have been around this code-base
> from before it's entry into Apache take some time to review things from the
> past.  What else is lurking in the repo that some of us might
> *think* are functional, but that haven't been tested in years?  What code
> was a prototype that never got fully implemented / supported?
> 
> If we can get all this out in the open, perhaps we can have a solid foundation
> to move forward.
> 
> On the other hand, if nobody has any examples beyond the ones listed
> below, then I think that those of us that are relatively new to the code will
> have to work under the assumption that everything is expected to be
> functional.
> 
> After we establish our foundation, we will need to be very consistent about
> our support of the features.  We'll need to be clear about intentions to
> deprecate something, and perhaps even provide a full feature release cycle
> worth of warning about a pending deprecation.
> 
> As a user, I not been stung by a feature that was yanked... but I was 
> certainly
> surprised when I found out that OVM and Bare Metal weren't being kept up
> to date (again, bare metal is resolved now).  Those features were part of our
> evaluation of the software, and me $dayjob has plans to at least use bare
> metal.
> 
> So why did I share that little story?  Well, it's because features coming and
> going are actually significant events to users of the software.  Just because
> we don't know of someone using a feature doesn't mean that it isn't in use.
> I'd like us to have that solid foundation as a start, and then be very clear
> when we need/want to make a decision that removes a feature from the
> software.
> 
> -chip

RE: Expanding a volume on a SAN

2013-07-10 Thread Anthony Xu

CS will see the new size, 


Anthony

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Tuesday, July 09, 2013 5:25 PM
To: dev@cloudstack.apache.org
Subject: Re: Expanding a volume on a SAN

Hey Anthony,

I assume this would be a candidate situation where you'd put the primary 
storage in maintenance mode and then perform the steps you referred me to?

When the storage is brought out of maintenance mode, will it see the new size 
or is there something more that has to be done on the CS side?

Thanks!


On Tue, Jul 9, 2013 at 6:09 PM, Mike Tutkowski  wrote:

> Thanks!
>
> Anyone know if CloudStack will recognize the new size of a storage 
> repository or datastore on its own?
>
>
> On Tue, Jul 9, 2013 at 4:01 PM, Anthony Xu  wrote:
>
>> http://support.citrix.com/article/CTX120865
>>
>> for XenServer, VMs need to be shut down or migrated away before  
>> expanding a volume.
>>
>>
>> Anthony
>>
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: Tuesday, July 09, 2013 2:25 PM
>> To: dev@cloudstack.apache.org
>> Cc: Edison Su; John Burwell
>> Subject: Expanding a volume on a SAN
>>
>> Hi everyone,
>>
>> I had a question posed to me today regarding how CloudStack and the 
>> underlying hypervisor deal with an iSCSI volume that is expanded.
>>
>> For example, let's say I'm using XenServer or ESX and I create a 
>> storage repository or datastore, respectively, for each hypervisor 
>> based on an iSCSI target. I then tie this into CloudStack as Primary Storage.
>>
>> If I increase the size of the iSCSI target (the SAN volume/LUN), does 
>> this increased size feed into the hypervisor and CloudStack?
>>
>> 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)*
>



--
*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: Storage Allocator Question

'random among the storage pools that have, say, the necessary storage tag'

Prachi

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Wednesday, July 10, 2013 1:44 PM
To: dev@cloudstack.apache.org
Subject: Re: Storage Allocator Question

Oh, when you say "random," does that mean random among the storage pools that 
have, say, the necessary storage tag or does random ignore storage tags?

Thanks


On Wed, Jul 10, 2013 at 2:43 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> 
wrote:

> OK, thanks!
>
>
> On Wed, Jul 10, 2013 at 2:40 PM, Prachi Damle wrote:
>
>> Currently for storage allocators, only random or firstfit or 
>> user-dispersing strategies are present. This is governed by the 
>> 'vm.allocation.algorithm' global config.
>> So for you case with storage tags, if you choose random, either of 
>> the pools can get chosen. For firstfit, you will mostly see one pool 
>> getting filled up first and then the other.
>>
>> There is no round-robin implementation in place. 'User-dispersing' 
>> may provide it to some effect if you are using a single account, 
>> since it always chooses a pool having less number of volumes for a given 
>> account.
>>
>> -Prachi
>>
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: Wednesday, July 10, 2013 1:34 PM
>> To: dev@cloudstack.apache.org
>> Subject: Storage Allocator Question
>>
>> Hi,
>>
>> I have a question about how current storage allocators work.
>>
>> Let's say I have two primary storages with the same storage tag.
>>
>> If I execute compute and disk offerings that reference that storage 
>> tag only, will one primary storage be (essentially) filled up before 
>> the other is utilized or do we have an allocator that performs round-robin 
>> placement?
>>
>> 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)*
>



--
*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: Storage Allocator Question

OK, thanks!


On Wed, Jul 10, 2013 at 2:40 PM, Prachi Damle wrote:

> Currently for storage allocators, only random or firstfit or
> user-dispersing strategies are present. This is governed by the
> 'vm.allocation.algorithm' global config.
> So for you case with storage tags, if you choose random, either of the
> pools can get chosen. For firstfit, you will mostly see one pool getting
> filled up first and then the other.
>
> There is no round-robin implementation in place. 'User-dispersing' may
> provide it to some effect if you are using a single account, since it
> always chooses a pool having less number of volumes for a given account.
>
> -Prachi
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, July 10, 2013 1:34 PM
> To: dev@cloudstack.apache.org
> Subject: Storage Allocator Question
>
> Hi,
>
> I have a question about how current storage allocators work.
>
> Let's say I have two primary storages with the same storage tag.
>
> If I execute compute and disk offerings that reference that storage tag
> only, will one primary storage be (essentially) filled up before the other
> is utilized or do we have an allocator that performs round-robin placement?
>
> 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
*™*

Re: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?

On Wed, Jul 10, 2013 at 08:44:24PM +, Alex Huang wrote:
> Thanks Chip for starting this thread.
> 
> I can at least think of the netapp plugin integration as something that was 
> tried before ASF but no longer tested and used.
> 

Awesome, that's one.  Any others?

> I'm all for coming up with this list but I don't see how this list can be 
> conclusive.  The problem that Edison dealt with in swift support is very 
> real.  I'm not trying to make an excuse for making a unilateral decision to 
> drop support without getting community feedback first.  That is wrong and I'm 
> glad it's being resolved.  However, without automated testing backing 
> functionality, we can have different set of these problems pop up every 
> release.  Should we start with only functionalities tested in automated 
> testing to be the supported feature set and add features back in as more 
> testing is added back in? 
> 
> To that end, how much of 4.0/4.1/4.2 features are actually added to automated 
> testing?  Or else we can face the same problem with those features too.
> 
> I still support gathering this list, even if it might be inconclusive. 

I agree with your points above, but think that we need to take this step
by step.  Let's figure out what code isn't actually in shape, based on
historical understanding first.  We then at least have a target to ask
the next question: what's covered by testing (automated or manual) for
each feature release?  Then we have a list of areas to focus on for
automated testing.

> 
> --Alex

Re: Storage Allocator Question

Very good, thanks you!


On Wed, Jul 10, 2013 at 2:51 PM, Prachi Damle wrote:

> 'random among the storage pools that have, say, the necessary storage tag'
>
> Prachi
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, July 10, 2013 1:44 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Storage Allocator Question
>
> Oh, when you say "random," does that mean random among the storage pools
> that have, say, the necessary storage tag or does random ignore storage
> tags?
>
> Thanks
>
>
> On Wed, Jul 10, 2013 at 2:43 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > OK, thanks!
> >
> >
> > On Wed, Jul 10, 2013 at 2:40 PM, Prachi Damle  >wrote:
> >
> >> Currently for storage allocators, only random or firstfit or
> >> user-dispersing strategies are present. This is governed by the
> >> 'vm.allocation.algorithm' global config.
> >> So for you case with storage tags, if you choose random, either of
> >> the pools can get chosen. For firstfit, you will mostly see one pool
> >> getting filled up first and then the other.
> >>
> >> There is no round-robin implementation in place. 'User-dispersing'
> >> may provide it to some effect if you are using a single account,
> >> since it always chooses a pool having less number of volumes for a
> given account.
> >>
> >> -Prachi
> >>
> >> -Original Message-
> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> Sent: Wednesday, July 10, 2013 1:34 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: Storage Allocator Question
> >>
> >> Hi,
> >>
> >> I have a question about how current storage allocators work.
> >>
> >> Let's say I have two primary storages with the same storage tag.
> >>
> >> If I execute compute and disk offerings that reference that storage
> >> tag only, will one primary storage be (essentially) filled up before
> >> the other is utilized or do we have an allocator that performs
> round-robin placement?
> >>
> >> 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)*
> >
>
>
>
> --
> *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
*™*

Re: Expanding a volume on a SAN

OK, great - thanks!

So, it sounds like on XenServer, you have to perform some manual activity
for it to see the new size of the iSCSI target (and there is probably a
similar requirement with ESX), but CloudStack will notice the size
difference automatically (once the storage repository or datastore has been
manually re-configured).


On Wed, Jul 10, 2013 at 2:48 PM, Anthony Xu  wrote:

> CS will see the new size,
>
>
> Anthony
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Tuesday, July 09, 2013 5:25 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Expanding a volume on a SAN
>
> Hey Anthony,
>
> I assume this would be a candidate situation where you'd put the primary
> storage in maintenance mode and then perform the steps you referred me to?
>
> When the storage is brought out of maintenance mode, will it see the new
> size or is there something more that has to be done on the CS side?
>
> Thanks!
>
>
> On Tue, Jul 9, 2013 at 6:09 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com
> > wrote:
>
> > Thanks!
> >
> > Anyone know if CloudStack will recognize the new size of a storage
> > repository or datastore on its own?
> >
> >
> > On Tue, Jul 9, 2013 at 4:01 PM, Anthony Xu  wrote:
> >
> >> http://support.citrix.com/article/CTX120865
> >>
> >> for XenServer, VMs need to be shut down or migrated away before
> >> expanding a volume.
> >>
> >>
> >> Anthony
> >>
> >> -Original Message-
> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> Sent: Tuesday, July 09, 2013 2:25 PM
> >> To: dev@cloudstack.apache.org
> >> Cc: Edison Su; John Burwell
> >> Subject: Expanding a volume on a SAN
> >>
> >> Hi everyone,
> >>
> >> I had a question posed to me today regarding how CloudStack and the
> >> underlying hypervisor deal with an iSCSI volume that is expanded.
> >>
> >> For example, let's say I'm using XenServer or ESX and I create a
> >> storage repository or datastore, respectively, for each hypervisor
> >> based on an iSCSI target. I then tie this into CloudStack as Primary
> Storage.
> >>
> >> If I increase the size of the iSCSI target (the SAN volume/LUN), does
> >> this increased size feed into the hypervisor and CloudStack?
> >>
> >> 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)*
> >
>
>
>
> --
> *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
*™*

Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

2013-07-10 Thread John Burwell

All,

For me, there are significant issues with the object_store patch.  First, it 
was merged to master with a unresolved -1 against it.  Second, it merged a 
feature depreciation without community consensus.  On their own, each of these 
actions violate core community values.  Cumulatively, I am concerned that these 
actions will erode our self governance, collaboration, technical quality, and 
community growth.  So, as Matt suggested, let's focus on re-implementing and 
testing Swift integration, and ensuring that these process anomalies remain 
isolated rather than the beginning of a destructive trend.  In that vein, how 
can I help fill this gap?

Thanks,
-John

P.S. I highly suggest the devstack (http://devstack.org) project to get a Swift 
instance up and running.  With it, you can build a full OpenStack (including 
Swift) environment locally in an hour or two (dependent on Internet connection 
speeds).  

On Jul 10, 2013, at 2:35 PM, Chip Childers  wrote:

> On Wed, Jul 10, 2013 at 06:13:07PM +, Edison Su wrote:
>> 1. Add swift back is just one or two days work, plus maybe one or two days, 
>> to setup a swift environment.
> 
> Great!
> 
>> 3. If we add this feature back, will we test it for each release? Such as 
>> adding it into automate test? Right now, I break this feature, I am pretty 
>> sure, it will be broken by other developers, if we continue adding feature 
>> without test.
> 
> Then let's test it until such time that we actually agree to deprecate
> it (if that ever happens).
> 
>> 4.  Claim a feature is supported for each release without test, is worse 
>> than saying not supported a feature. If we want to support a feature, we 
>> should test it for each release. If so, who will want to test this feature?
> 
> As stated earlier, we have a user that's volunteered to test it out for
> us already.

RE: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

John,

I'm concerned that object store implementations that's going into 4.2 will 
repeat this fate if we don't add them into the automated test environment.  
Perhaps, you, me, Edison, Prassana, and perhaps Thomas can work together about 
how to add the current implementations into the regression test suite?

--Alex

> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Wednesday, July 10, 2013 2:15 PM
> To: dev@cloudstack.apache.org
> Cc: 'Caleb Call'
> Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?
> 
> All,
> 
> For me, there are significant issues with the object_store patch.  First, it 
> was
> merged to master with a unresolved -1 against it.  Second, it merged a
> feature depreciation without community consensus.  On their own, each of
> these actions violate core community values.  Cumulatively, I am concerned
> that these actions will erode our self governance, collaboration, technical
> quality, and community growth.  So, as Matt suggested, let's focus on re-
> implementing and testing Swift integration, and ensuring that these process
> anomalies remain isolated rather than the beginning of a destructive trend.
> In that vein, how can I help fill this gap?
> 
> Thanks,
> -John
> 
> P.S. I highly suggest the devstack (http://devstack.org) project to get a 
> Swift
> instance up and running.  With it, you can build a full OpenStack (including
> Swift) environment locally in an hour or two (dependent on Internet
> connection speeds).
> 
> On Jul 10, 2013, at 2:35 PM, Chip Childers 
> wrote:
> 
> > On Wed, Jul 10, 2013 at 06:13:07PM +, Edison Su wrote:
> >> 1. Add swift back is just one or two days work, plus maybe one or two
> days, to setup a swift environment.
> >
> > Great!
> >
> >> 3. If we add this feature back, will we test it for each release? Such as
> adding it into automate test? Right now, I break this feature, I am pretty 
> sure,
> it will be broken by other developers, if we continue adding feature without
> test.
> >
> > Then let's test it until such time that we actually agree to deprecate
> > it (if that ever happens).
> >
> >> 4.  Claim a feature is supported for each release without test, is worse
> than saying not supported a feature. If we want to support a feature, we
> should test it for each release. If so, who will want to test this feature?
> >
> > As stated earlier, we have a user that's volunteered to test it out
> > for us already.

Re: Review Request 12227: NPE while deploying any instances in kvm/vmware using ZWPS due to capacityIops

2013-07-10 Thread edison su


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

Ship it!


Ship It!

- edison su


On July 4, 2013, 12:32 p.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12227/
> ---
> 
> (Updated July 4, 2013, 12:32 p.m.)
> 
> 
> Review request for cloudstack, edison su, Ram Ganesh, and Sateesh 
> Chodapuneedi.
> 
> 
> Bugs: 3301
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Issue: 
> When VM is getting deployed in ZWPS(kvm, vmware), NPE is occuring.
> 
> Fixed:
> SolidFire storage had introduced iops, its setting capacityIops on the pool 
> level. Only solidfire is setting and getting it which is causing NPE when 
> checking this value for other type PS.
> This fixed will resolve the issue for any storage provider which don't set 
> capacityIops.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/StorageManagerImpl.java bb21afb 
> 
> Diff: https://reviews.apache.org/r/12227/diff/
> 
> 
> Testing
> ---
> 
> 1. Adding ZWPS, and deployed the VM in KVM. Vm got successfully deployed.
> 2. Adding CWPS and deployed the VM in KVM. VM got deployed successfully.
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

Re: Review Request 11984: Fix primary datastore NPE/incorrect db entry/exception propagation for KVM on cloudstack

2013-07-10 Thread edison su


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

Ship it!


Ship It!

- edison su


On July 2, 2013, 11:09 p.m., Venkata Siva Vijayendra Bhamidipati wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11984/
> ---
> 
> (Updated July 2, 2013, 11:09 p.m.)
> 
> 
> Review request for cloudstack, Chip Childers, edison su, and Min Chen.
> 
> 
> Bugs: CLOUDSTACK-1510
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Patch for fixes for issues detected while working on bug CLOUDSTACK-1510 
> (https://issues.apache.org/jira/browse/CLOUDSTACK-1510).
> 
> 
> Diffs
> -
> 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
>  f5750b9 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
>  89e22c8 
>   
> plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
>  2e0ff66 
>   server/src/com/cloud/storage/StorageManagerImpl.java bb21afb 
> 
> Diff: https://reviews.apache.org/r/11984/diff/
> 
> 
> Testing
> ---
> 
> Deploy KVM cluster in cloudstack. Attempt to add a primary NFS datastore 
> using an invalid path. NPE is not encountered anymore. If KVM host is down or 
> the cloud-agent on the KVM host is down, the primary datastore (whether valid 
> or otherwise) is not logged to the db's storage_pool table. So invalid 
> datastores do not show up in the GUI when listing the primary datastores 
> available. Also, exception is propagated to GUI.
> 
> 
> Thanks,
> 
> Venkata Siva Vijayendra Bhamidipati
> 
>

RE: Expanding a volume on a SAN

You might have to force a reconnection to the xenserver in order for CS to see 
it.  On every connection, CS checks these items and updates its database.

--Alex

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, July 10, 2013 2:14 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Expanding a volume on a SAN
> 
> OK, great - thanks!
> 
> So, it sounds like on XenServer, you have to perform some manual activity
> for it to see the new size of the iSCSI target (and there is probably a 
> similar
> requirement with ESX), but CloudStack will notice the size difference
> automatically (once the storage repository or datastore has been manually
> re-configured).
> 
> 
> On Wed, Jul 10, 2013 at 2:48 PM, Anthony Xu  wrote:
> 
> > CS will see the new size,
> >
> >
> > Anthony
> >
> > -Original Message-
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Tuesday, July 09, 2013 5:25 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Expanding a volume on a SAN
> >
> > Hey Anthony,
> >
> > I assume this would be a candidate situation where you'd put the
> > primary storage in maintenance mode and then perform the steps you
> referred me to?
> >
> > When the storage is brought out of maintenance mode, will it see the
> > new size or is there something more that has to be done on the CS side?
> >
> > Thanks!
> >
> >
> > On Tue, Jul 9, 2013 at 6:09 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com
> > > wrote:
> >
> > > Thanks!
> > >
> > > Anyone know if CloudStack will recognize the new size of a storage
> > > repository or datastore on its own?
> > >
> > >
> > > On Tue, Jul 9, 2013 at 4:01 PM, Anthony Xu 
> wrote:
> > >
> > >> http://support.citrix.com/article/CTX120865
> > >>
> > >> for XenServer, VMs need to be shut down or migrated away before
> > >> expanding a volume.
> > >>
> > >>
> > >> Anthony
> > >>
> > >> -Original Message-
> > >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > >> Sent: Tuesday, July 09, 2013 2:25 PM
> > >> To: dev@cloudstack.apache.org
> > >> Cc: Edison Su; John Burwell
> > >> Subject: Expanding a volume on a SAN
> > >>
> > >> Hi everyone,
> > >>
> > >> I had a question posed to me today regarding how CloudStack and the
> > >> underlying hypervisor deal with an iSCSI volume that is expanded.
> > >>
> > >> For example, let's say I'm using XenServer or ESX and I create a
> > >> storage repository or datastore, respectively, for each hypervisor
> > >> based on an iSCSI target. I then tie this into CloudStack as
> > >> Primary
> > Storage.
> > >>
> > >> If I increase the size of the iSCSI target (the SAN volume/LUN),
> > >> does this increased size feed into the hypervisor and CloudStack?
> > >>
> > >> 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)*
> > >
> >
> >
> >
> > --
> > *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)*

XenServer 'can not create vdi in sr ' and other system vm creation issues

2013-07-10 Thread SuichII, Christopher

I'm working on setting up a CS installation with a single XenServer host. 
However, once I add the primary and secondary storage, the system vms fail to 
start up.

For readability, I've put several logs and traces here:

http://pastebin.com/eb51JDHF <--- CS Mgmt Log 1
http://pastebin.com/mbfRCei3 <--- XenServer Log from the same time as CS Mgmt 
Log 1

http://pastebin.com/Sm56N5ZX <--- Another CS Mgmt log that is likely related. 
This one clearly states that the host is placed on the avoid list and therefore 
no suitable hosts were found, but I can't figure out why the host is on the 
avoid list.

http://pastebin.com/21R9auwb <--- Another CS Mgmt log indicating it was 'Unable 
to acquire lock on VMTemplateStoragePool'



Those 4 groups of logs just repeat over and over.

I know that is a lot to read through, but can anyone provide any insight here? 
I've been stuck on this for quite a while today. I'm building CS from the 
latest code as of this morning with the following commands:

mvn -e -Dmaven.test.skip=true -P systemvm,developer clean install
mvn -e -Dmaven.test.skip=true -P developer -pl developer,tools/devcloud 
-Ddeploydb
mvn -e -pl :cloud-client-ui jetty:run

and I have downloaded and placed the vhd-util accordingly. Is there some 
obvious step I'm missing?

Thanks!
Chris

Re: Expanding a volume on a SAN

Hey Alex,

When you say, "force a reconnection," I'm not sure to what part of the
system you're referring. Is this an action performed on the CloudStack side?

Thanks!


On Wed, Jul 10, 2013 at 4:10 PM, Alex Huang  wrote:

> You might have to force a reconnection to the xenserver in order for CS to
> see it.  On every connection, CS checks these items and updates its
> database.
>
> --Alex
>
> > -Original Message-
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Wednesday, July 10, 2013 2:14 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Expanding a volume on a SAN
> >
> > OK, great - thanks!
> >
> > So, it sounds like on XenServer, you have to perform some manual activity
> > for it to see the new size of the iSCSI target (and there is probably a
> similar
> > requirement with ESX), but CloudStack will notice the size difference
> > automatically (once the storage repository or datastore has been manually
> > re-configured).
> >
> >
> > On Wed, Jul 10, 2013 at 2:48 PM, Anthony Xu 
> wrote:
> >
> > > CS will see the new size,
> > >
> > >
> > > Anthony
> > >
> > > -Original Message-
> > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > Sent: Tuesday, July 09, 2013 5:25 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: Expanding a volume on a SAN
> > >
> > > Hey Anthony,
> > >
> > > I assume this would be a candidate situation where you'd put the
> > > primary storage in maintenance mode and then perform the steps you
> > referred me to?
> > >
> > > When the storage is brought out of maintenance mode, will it see the
> > > new size or is there something more that has to be done on the CS side?
> > >
> > > Thanks!
> > >
> > >
> > > On Tue, Jul 9, 2013 at 6:09 PM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com
> > > > wrote:
> > >
> > > > Thanks!
> > > >
> > > > Anyone know if CloudStack will recognize the new size of a storage
> > > > repository or datastore on its own?
> > > >
> > > >
> > > > On Tue, Jul 9, 2013 at 4:01 PM, Anthony Xu 
> > wrote:
> > > >
> > > >> http://support.citrix.com/article/CTX120865
> > > >>
> > > >> for XenServer, VMs need to be shut down or migrated away before
> > > >> expanding a volume.
> > > >>
> > > >>
> > > >> Anthony
> > > >>
> > > >> -Original Message-
> > > >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > >> Sent: Tuesday, July 09, 2013 2:25 PM
> > > >> To: dev@cloudstack.apache.org
> > > >> Cc: Edison Su; John Burwell
> > > >> Subject: Expanding a volume on a SAN
> > > >>
> > > >> Hi everyone,
> > > >>
> > > >> I had a question posed to me today regarding how CloudStack and the
> > > >> underlying hypervisor deal with an iSCSI volume that is expanded.
> > > >>
> > > >> For example, let's say I'm using XenServer or ESX and I create a
> > > >> storage repository or datastore, respectively, for each hypervisor
> > > >> based on an iSCSI target. I then tie this into CloudStack as
> > > >> Primary
> > > Storage.
> > > >>
> > > >> If I increase the size of the iSCSI target (the SAN volume/LUN),
> > > >> does this increased size feed into the hypervisor and CloudStack?
> > > >>
> > > >> 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)*
> > > >
> > >
> > >
> > >
> > > --
> > > *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)*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*™*

Re: [GSOC] ldap feature branch

@Abhi - Just to keep you updated code will be pushed here frequently
to show progress. I will let you know when it is in a good enough
state to be reviewed/merged.

On 10 July 2013 16:54, Sebastien Goasguen  wrote:
> Hi,
>
> FYI: I created a ldapplugin feature branch for Ian to commit his patches in.
>
> Cheers,
>
> -Sebastien

Re: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?


On Jul 10, 2013, at 5:06 PM, Chip Childers  wrote:

> On Wed, Jul 10, 2013 at 08:44:24PM +, Alex Huang wrote:
>> Thanks Chip for starting this thread.
>> 
>> I can at least think of the netapp plugin integration as something that was 
>> tried before ASF but no longer tested and used.
>> 
> 
> Awesome, that's one.  Any others?

The S3 interface in awsapi ?

> 
>> I'm all for coming up with this list but I don't see how this list can be 
>> conclusive.  The problem that Edison dealt with in swift support is very 
>> real.  I'm not trying to make an excuse for making a unilateral decision to 
>> drop support without getting community feedback first.  That is wrong and 
>> I'm glad it's being resolved.  However, without automated testing backing 
>> functionality, we can have different set of these problems pop up every 
>> release.  Should we start with only functionalities tested in automated 
>> testing to be the supported feature set and add features back in as more 
>> testing is added back in? 
>> 
>> To that end, how much of 4.0/4.1/4.2 features are actually added to 
>> automated testing?  Or else we can face the same problem with those features 
>> too.
>> 
>> I still support gathering this list, even if it might be inconclusive. 
> 
> I agree with your points above, but think that we need to take this step
> by step.  Let's figure out what code isn't actually in shape, based on
> historical understanding first.  We then at least have a target to ask
> the next question: what's covered by testing (automated or manual) for
> each feature release?  Then we have a list of areas to focus on for
> automated testing.
> 
>> 
>> --Alex

Tiny template for ESX?

Hi,

I was hoping to run a little VM from CloudStack on a host in an ESX cluster.

Do we have a tiny template similar to the one we use for XenServer that I
might be able to leverage?

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
*™*

RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?



> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Wednesday, July 10, 2013 3:38 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] What other "features" or code is sitting around that
> might be suffering from bit rot?
> 
> 
> On Jul 10, 2013, at 5:06 PM, Chip Childers 
> wrote:
> 
> > On Wed, Jul 10, 2013 at 08:44:24PM +, Alex Huang wrote:
> >> Thanks Chip for starting this thread.
> >>
> >> I can at least think of the netapp plugin integration as something that was
> tried before ASF but no longer tested and used.
> >>
> >
> > Awesome, that's one.  Any others?
> 
> The S3 interface in awsapi ?
> 


AFAIK, awsapi was EC2 only.  Prachi?

--Alex

Re: Review Request 11910: Fix for CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable dynamic scaling of vm

2013-07-10 Thread ASF Subversion and Git Services


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


Commit 79bec35476508b23077311888a00189573c5c9d9 in branch refs/heads/4.2 from 
Jessica Wang
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=79bec35 ]

CLOUDSTACK-2987: UI > Templates menu > register template action: add 
Dynamically Scalable field.


- ASF Subversion and Git Services


On June 20, 2013, 5:19 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11910/
> ---
> 
> (Updated June 20, 2013, 5:19 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Nitin Mehta.
> 
> 
> Bugs: CLOUDSTACK-2987 and CLOUDSTACK-3042
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable 
> dynamic scaling of vm 
> 
> CLOUDSTACK-3042 - handle Scaling up of vm memory/CPU based on the presence of 
> XS tools in the template
> This should also take care of updation of VM after XS tools are installed in 
> the vm and set memory values accordingly to support dynamic scaling after 
> stop start of VM
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/template/VirtualMachineTemplate.java cedc793 
>   api/src/com/cloud/vm/VirtualMachine.java ce9add6 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 12e5097 
>   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 6fd9773 
>   api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java 
> 284d553 
>   
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
>  c9da0c2 
>   api/src/org/apache/cloudstack/api/command/user/vm/UpdateVMCmd.java 2860283 
>   api/src/org/apache/cloudstack/api/response/TemplateResponse.java ed933ff 
>   api/src/org/apache/cloudstack/api/response/UserVmResponse.java 5b71ba2 
>   core/src/com/cloud/agent/api/ScaleVmCommand.java b361485 
>   engine/schema/src/com/cloud/storage/VMTemplateVO.java e643d75 
>   engine/schema/src/com/cloud/vm/VMInstanceVO.java fbe03dc 
>   
> engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java
>  4d162bb 
>   plugins/hypervisors/xen/src/com/cloud/hypervisor/XenServerGuru.java 8c38a69 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  5e8283a 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
>  8e37809 
>   server/src/com/cloud/api/ApiResponseHelper.java 7ffa30f 
>   server/src/com/cloud/api/query/dao/UserVmJoinDaoImpl.java f9877ab 
>   server/src/com/cloud/api/query/vo/UserVmJoinVO.java c97d71a 
>   server/src/com/cloud/hypervisor/HypervisorGuruBase.java 1ad9a1f 
>   server/src/com/cloud/server/ManagementServerImpl.java cfc8333 
>   server/src/com/cloud/storage/TemplateProfile.java 0b55f1f 
>   server/src/com/cloud/template/TemplateAdapter.java 9a2d877 
>   server/src/com/cloud/template/TemplateAdapterBase.java 0940d3e 
>   server/src/com/cloud/vm/UserVmManagerImpl.java e8ea024 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 5814075 
>   server/test/com/cloud/vm/VirtualMachineManagerImplTest.java 8715c9e 
>   setup/db/db/schema-410to420.sql c782234 
> 
> Diff: https://reviews.apache.org/r/11910/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?

Code for S3 API is lying under awsapi project. Only EC2 API under awsapi is 
functionally tested.

-Original Message-
From: Alex Huang 
Sent: Wednesday, July 10, 2013 3:40 PM
To: dev@cloudstack.apache.org
Cc: Prachi Damle
Subject: RE: [DISCUSS] What other "features" or code is sitting around that 
might be suffering from bit rot?



> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Wednesday, July 10, 2013 3:38 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] What other "features" or code is sitting around 
> that might be suffering from bit rot?
> 
> 
> On Jul 10, 2013, at 5:06 PM, Chip Childers 
> wrote:
> 
> > On Wed, Jul 10, 2013 at 08:44:24PM +, Alex Huang wrote:
> >> Thanks Chip for starting this thread.
> >>
> >> I can at least think of the netapp plugin integration as something 
> >> that was
> tried before ASF but no longer tested and used.
> >>
> >
> > Awesome, that's one.  Any others?
> 
> The S3 interface in awsapi ?
> 


AFAIK, awsapi was EC2 only.  Prachi?

--Alex

RE: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

2013-07-10 Thread Edison Su



> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Wednesday, July 10, 2013 2:15 PM
> To: dev@cloudstack.apache.org
> Cc: 'Caleb Call'
> Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?
> 
> All,
> 
> For me, there are significant issues with the object_store patch.  First, it 
> was
> merged to master with a unresolved -1 against it.  Second, it merged a
> feature depreciation without community consensus.  On their own, each of
> these actions violate core community values.  Cumulatively, I am concerned
> that these actions will erode our self governance, collaboration, technical
> quality, and community growth.  So, as Matt suggested, let's focus on re-
> implementing and testing Swift integration, and ensuring that these process
> anomalies remain isolated rather than the beginning of a destructive trend.
> In that vein, how can I help fill this gap?
> 
> Thanks,
> -John
> 
> P.S. I highly suggest the devstack (http://devstack.org) project to get a 
> Swift
> instance up and running.  With it, you can build a full OpenStack (including
> Swift) environment locally in an hour or two (dependent on Internet
> connection speeds).

Oh man, my two hours are wasted on devstack already. After installed devstack, 
there is no swift service at all.

> 
> On Jul 10, 2013, at 2:35 PM, Chip Childers 
> wrote:
> 
> > On Wed, Jul 10, 2013 at 06:13:07PM +, Edison Su wrote:
> >> 1. Add swift back is just one or two days work, plus maybe one or two
> days, to setup a swift environment.
> >
> > Great!
> >
> >> 3. If we add this feature back, will we test it for each release? Such as
> adding it into automate test? Right now, I break this feature, I am pretty 
> sure,
> it will be broken by other developers, if we continue adding feature without
> test.
> >
> > Then let's test it until such time that we actually agree to deprecate
> > it (if that ever happens).
> >
> >> 4.  Claim a feature is supported for each release without test, is worse
> than saying not supported a feature. If we want to support a feature, we
> should test it for each release. If so, who will want to test this feature?
> >
> > As stated earlier, we have a user that's volunteered to test it out
> > for us already.

Re: Tiny template for ESX?

2013-07-10 Thread Ahmad Emneina

short answer... dont think so. having said that, I believe we used DSL
which can be downloaded from:
http://www.damnsmalllinux.org/

its around 50 megs :)


On Wed, Jul 10, 2013 at 3:37 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> I was hoping to run a little VM from CloudStack on a host in an ESX
> cluster.
>
> Do we have a tiny template similar to the one we use for XenServer that I
> might be able to leverage?
>
> 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
> *™*
>

RE: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

2013-07-10 Thread Edison Su

I spent two days to install Basio, about one week to get Cloudian work, don't 
know how many days I need to get swift work.
Guys, don't blame me not support this feature and that feature, please just 
take a look at how many work/hours I need, to a simple thing work.

> -Original Message-
> From: Edison Su [mailto:edison...@citrix.com]
> Sent: Wednesday, July 10, 2013 3:53 PM
> To: dev@cloudstack.apache.org
> Cc: 'Caleb Call'
> Subject: RE: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?
> 
> 
> 
> > -Original Message-
> > From: John Burwell [mailto:jburw...@basho.com]
> > Sent: Wednesday, July 10, 2013 2:15 PM
> > To: dev@cloudstack.apache.org
> > Cc: 'Caleb Call'
> > Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in 
> > 4.2?
> >
> > All,
> >
> > For me, there are significant issues with the object_store patch.
> > First, it was merged to master with a unresolved -1 against it.
> > Second, it merged a feature depreciation without community consensus.
> > On their own, each of these actions violate core community values.
> > Cumulatively, I am concerned that these actions will erode our self
> > governance, collaboration, technical quality, and community growth.
> > So, as Matt suggested, let's focus on re- implementing and testing
> > Swift integration, and ensuring that these process anomalies remain
> isolated rather than the beginning of a destructive trend.
> > In that vein, how can I help fill this gap?
> >
> > Thanks,
> > -John
> >
> > P.S. I highly suggest the devstack (http://devstack.org) project to
> > get a Swift instance up and running.  With it, you can build a full
> > OpenStack (including
> > Swift) environment locally in an hour or two (dependent on Internet
> > connection speeds).
> 
> Oh man, my two hours are wasted on devstack already. After installed
> devstack, there is no swift service at all.
> 
> >
> > On Jul 10, 2013, at 2:35 PM, Chip Childers 
> > wrote:
> >
> > > On Wed, Jul 10, 2013 at 06:13:07PM +, Edison Su wrote:
> > >> 1. Add swift back is just one or two days work, plus maybe one or
> > >> two
> > days, to setup a swift environment.
> > >
> > > Great!
> > >
> > >> 3. If we add this feature back, will we test it for each release?
> > >> Such as
> > adding it into automate test? Right now, I break this feature, I am
> > pretty sure, it will be broken by other developers, if we continue
> > adding feature without test.
> > >
> > > Then let's test it until such time that we actually agree to
> > > deprecate it (if that ever happens).
> > >
> > >> 4.  Claim a feature is supported for each release without test, is
> > >> worse
> > than saying not supported a feature. If we want to support a feature,
> > we should test it for each release. If so, who will want to test this 
> > feature?
> > >
> > > As stated earlier, we have a user that's volunteered to test it out
> > > for us already.

RE: Expanding a volume on a SAN

ah sorry.  Yes.  From the CloudStack management UI, you can force cloudstack to 
reconnect to the host.  This forces cloudstack to flush it's connection and 
restablish the connection.  On restablishing the connection, there's a series 
of checks and information gathered.  Size of the storage pool is one such 
information.

--Alex

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, July 10, 2013 3:13 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Expanding a volume on a SAN
> 
> Hey Alex,
> 
> When you say, "force a reconnection," I'm not sure to what part of the
> system you're referring. Is this an action performed on the CloudStack side?
> 
> Thanks!
> 
> 
> On Wed, Jul 10, 2013 at 4:10 PM, Alex Huang  wrote:
> 
> > You might have to force a reconnection to the xenserver in order for
> > CS to see it.  On every connection, CS checks these items and updates
> > its database.
> >
> > --Alex
> >
> > > -Original Message-
> > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > Sent: Wednesday, July 10, 2013 2:14 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: Expanding a volume on a SAN
> > >
> > > OK, great - thanks!
> > >
> > > So, it sounds like on XenServer, you have to perform some manual
> > > activity for it to see the new size of the iSCSI target (and there
> > > is probably a
> > similar
> > > requirement with ESX), but CloudStack will notice the size
> > > difference automatically (once the storage repository or datastore
> > > has been manually re-configured).
> > >
> > >
> > > On Wed, Jul 10, 2013 at 2:48 PM, Anthony Xu 
> > wrote:
> > >
> > > > CS will see the new size,
> > > >
> > > >
> > > > Anthony
> > > >
> > > > -Original Message-
> > > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > > Sent: Tuesday, July 09, 2013 5:25 PM
> > > > To: dev@cloudstack.apache.org
> > > > Subject: Re: Expanding a volume on a SAN
> > > >
> > > > Hey Anthony,
> > > >
> > > > I assume this would be a candidate situation where you'd put the
> > > > primary storage in maintenance mode and then perform the steps you
> > > referred me to?
> > > >
> > > > When the storage is brought out of maintenance mode, will it see
> > > > the new size or is there something more that has to be done on the CS
> side?
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > On Tue, Jul 9, 2013 at 6:09 PM, Mike Tutkowski <
> > > > mike.tutkow...@solidfire.com
> > > > > wrote:
> > > >
> > > > > Thanks!
> > > > >
> > > > > Anyone know if CloudStack will recognize the new size of a
> > > > > storage repository or datastore on its own?
> > > > >
> > > > >
> > > > > On Tue, Jul 9, 2013 at 4:01 PM, Anthony Xu
> > > > > 
> > > wrote:
> > > > >
> > > > >> http://support.citrix.com/article/CTX120865
> > > > >>
> > > > >> for XenServer, VMs need to be shut down or migrated away before
> > > > >> expanding a volume.
> > > > >>
> > > > >>
> > > > >> Anthony
> > > > >>
> > > > >> -Original Message-
> > > > >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > > >> Sent: Tuesday, July 09, 2013 2:25 PM
> > > > >> To: dev@cloudstack.apache.org
> > > > >> Cc: Edison Su; John Burwell
> > > > >> Subject: Expanding a volume on a SAN
> > > > >>
> > > > >> Hi everyone,
> > > > >>
> > > > >> I had a question posed to me today regarding how CloudStack and
> > > > >> the underlying hypervisor deal with an iSCSI volume that is
> expanded.
> > > > >>
> > > > >> For example, let's say I'm using XenServer or ESX and I create
> > > > >> a storage repository or datastore, respectively, for each
> > > > >> hypervisor based on an iSCSI target. I then tie this into
> > > > >> CloudStack as Primary
> > > > Storage.
> > > > >>
> > > > >> If I increase the size of the iSCSI target (the SAN
> > > > >> volume/LUN), does this increased size feed into the hypervisor and
> CloudStack?
> > > > >>
> > > > >> 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)*
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *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 De

RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?

> 
> I agree with your points above, but think that we need to take this step by
> step.  Let's figure out what code isn't actually in shape, based on historical
> understanding first.  We then at least have a target to ask the next question:
> what's covered by testing (automated or manual) for each feature release?
> Then we have a list of areas to focus on for automated testing.
> 

Agreed.  I guess I'm just thinking ahead given that this thread is already 
started.

Here's some more I can think of:

CloudZones implementation which allows someone to deploy a zone in their own 
data center but uses a hosted management server to manage it.
Local Storage based secondary storage which uses available local storage in the 
hypervisor host for secondary storage.
HyperV prototype (Not the new one that Donal is working on)
Cifs based secondary storage as part of the HyperV work

--Alex

Re: New Install: CS 4.1 | Cent OS 6.4 | KVM


On Jul 8, 2013, at 11:58 PM, Maurice Lawler  wrote:

> Hello,
> 
> Fresh install /setup, I am getting error: 
> 
> [root@cloud ~]# /etc/init.d/cloudstack-management start
> /etc/sysconfig/cloudstack-management: line 21: 
> /etc/cloudstack/management/tomcat6.conf: No such file or directory
> Starting cloudstack-management: awk: cmd. line:1: fatal: cannot open file 
> `/etc/cloudstack/management/tomcat6.conf' for reading (No such file or 
> directory)
> Error code 4   [FAILED]
> 
> However, I read of a work around, copy tomcat6-nonssl.conf to tomcat6.conf 
> and that allowed me to start the management server.
> 
> Why is this error on going? 
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-1802

I am copying Marcus since 180 points to :
https://issues.apache.org/jira/browse/CLOUDSTACK-1694

Which he is listed as "assignee" and bugs seems fixed.

Marcus, any thoughts ?

-sebastien


> 
> 
>

Re: Is there any patch file CS 4.1 to xen-6.2.0

Geoff, can you answer Keerthi ?

thanks

On Jun 29, 2013, at 3:39 AM, Keerthiraja SJ  wrote:

> Hi All,
> 
> 
> 
> Is there any patch file for cloudstack-4.1 to added xenserver-6.2.0 .
> 
> 
> 
> I knew that
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/discoverer/XcpServerDiscoverer.java
> this file plays vital role to added xenserver-6.2.0 but it support only
> upto 6.1 do u guys have any patch Just but adding into my cloudstack
> location will help me.
> 
> 
> 
> I have installed Cloudstack as RPM it would be better to patch like script
> to work in my installed CS.
> 
> 
> 
> Thanks,
> 
> Keerthi

RE: Expanding a volume on a SAN

2013-07-10 Thread Anthony Xu

If you put the primary storage in maintenance mode to evacuate the VM, when you 
cancel maintenance mode for the primary storage, CS will get the new size of 
the primary storage.


Anthony

-Original Message-
From: Alex Huang [mailto:alex.hu...@citrix.com] 
Sent: Wednesday, July 10, 2013 4:07 PM
To: dev@cloudstack.apache.org
Subject: RE: Expanding a volume on a SAN

ah sorry.  Yes.  From the CloudStack management UI, you can force cloudstack to 
reconnect to the host.  This forces cloudstack to flush it's connection and 
restablish the connection.  On restablishing the connection, there's a series 
of checks and information gathered.  Size of the storage pool is one such 
information.

--Alex

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, July 10, 2013 3:13 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Expanding a volume on a SAN
> 
> Hey Alex,
> 
> When you say, "force a reconnection," I'm not sure to what part of the 
> system you're referring. Is this an action performed on the CloudStack side?
> 
> Thanks!
> 
> 
> On Wed, Jul 10, 2013 at 4:10 PM, Alex Huang  wrote:
> 
> > You might have to force a reconnection to the xenserver in order for 
> > CS to see it.  On every connection, CS checks these items and 
> > updates its database.
> >
> > --Alex
> >
> > > -Original Message-
> > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > Sent: Wednesday, July 10, 2013 2:14 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: Expanding a volume on a SAN
> > >
> > > OK, great - thanks!
> > >
> > > So, it sounds like on XenServer, you have to perform some manual 
> > > activity for it to see the new size of the iSCSI target (and there 
> > > is probably a
> > similar
> > > requirement with ESX), but CloudStack will notice the size 
> > > difference automatically (once the storage repository or datastore 
> > > has been manually re-configured).
> > >
> > >
> > > On Wed, Jul 10, 2013 at 2:48 PM, Anthony Xu 
> > wrote:
> > >
> > > > CS will see the new size,
> > > >
> > > >
> > > > Anthony
> > > >
> > > > -Original Message-
> > > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > > Sent: Tuesday, July 09, 2013 5:25 PM
> > > > To: dev@cloudstack.apache.org
> > > > Subject: Re: Expanding a volume on a SAN
> > > >
> > > > Hey Anthony,
> > > >
> > > > I assume this would be a candidate situation where you'd put the 
> > > > primary storage in maintenance mode and then perform the steps 
> > > > you
> > > referred me to?
> > > >
> > > > When the storage is brought out of maintenance mode, will it see 
> > > > the new size or is there something more that has to be done on 
> > > > the CS
> side?
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > On Tue, Jul 9, 2013 at 6:09 PM, Mike Tutkowski < 
> > > > mike.tutkow...@solidfire.com
> > > > > wrote:
> > > >
> > > > > Thanks!
> > > > >
> > > > > Anyone know if CloudStack will recognize the new size of a 
> > > > > storage repository or datastore on its own?
> > > > >
> > > > >
> > > > > On Tue, Jul 9, 2013 at 4:01 PM, Anthony Xu 
> > > > > 
> > > wrote:
> > > > >
> > > > >> http://support.citrix.com/article/CTX120865
> > > > >>
> > > > >> for XenServer, VMs need to be shut down or migrated away 
> > > > >> before expanding a volume.
> > > > >>
> > > > >>
> > > > >> Anthony
> > > > >>
> > > > >> -Original Message-
> > > > >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > > >> Sent: Tuesday, July 09, 2013 2:25 PM
> > > > >> To: dev@cloudstack.apache.org
> > > > >> Cc: Edison Su; John Burwell
> > > > >> Subject: Expanding a volume on a SAN
> > > > >>
> > > > >> Hi everyone,
> > > > >>
> > > > >> I had a question posed to me today regarding how CloudStack 
> > > > >> and the underlying hypervisor deal with an iSCSI volume that 
> > > > >> is
> expanded.
> > > > >>
> > > > >> For example, let's say I'm using XenServer or ESX and I 
> > > > >> create a storage repository or datastore, respectively, for 
> > > > >> each hypervisor based on an iSCSI target. I then tie this 
> > > > >> into CloudStack as Primary
> > > > Storage.
> > > > >>
> > > > >> If I increase the size of the iSCSI target (the SAN 
> > > > >> volume/LUN), does this increased size feed into the 
> > > > >> hypervisor and
> CloudStack?
> > > > >>
> > > > >> 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

RE: Expanding a volume on a SAN