RE: [PROPOSAL] Windowsfication Of ACS

[Paul Angus]

I don't know if you guys already know this, but the mounting of sec storage on 
the management server to pass the systemvm.iso is also done when using hyper-v 
as well. So for hyper-v, samba support is required on the management server.

Regards

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
paul.an...@shapeblue.com

-Original Message-
From: Kelven Yang [mailto:kelven.y...@citrix.com]
Sent: 25 February 2014 23:07
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] Windowsfication Of ACS

Current way of mounting NFS into management server is the legacy of the rushing 
old days when VMware support was originally built. To get rid of NFS mount in 
management server, we should file it as a feature request along with the 
Windowsfication effort

Kelven

On 2/25/14, 1:54 PM, "Alex Huang"  wrote:

>Damodar,
>
>I think you'll find that earlier in the thread I have said that these
>should not be part of the management server startup but rather the
>install.  The install scripts for Linux is probably python or shell
>script based.  The install for windows is an app that can do this work.
>
>Other than these, the main problem for you will be the VmWare code that
>mounts secondary storage to the management server machine.  That's a
>design flaw in VmWare code that we should rectify.  You can speak to
>Kelven about how to fix that.
>
>--Alex
>
>> -Original Message-
>> From: Damoder Reddy [mailto:damoder.re...@citrix.com]
>> Sent: Monday, February 24, 2014 9:48 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [PROPOSAL] Windowsfication Of ACS
>>
>> Hi Alex,
>>
>>  Apart from agent scripts, there are couple of scripts those gets
>>executed for  during the management server startup like injecting ssh
>>keys into  systemvm.iso etc.. Still I am in search of any other
>>scripts will get called in  management server, though I could not find
>>any as of now.
>>
>> Thanks & Regards
>> Damodar/
>>
>> -Original Message-
>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>> Sent: Tuesday, February 25, 2014 10:10 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [PROPOSAL] Windowsfication Of ACS
>>
>> Abhi,
>>
>> I think you misunderstood.  I meant that it should not depend on
>>things later  releases like .net framework.  See the following wiki
>>page.
>>
>> http://en.wikipedia.org/wiki/.NET_Framework#Versions
>>
>> I would imagine .net framework 3 or 3.5 would be ideal.  If you use
>> .net framework 4, then libraries need to be installed and they
>> sometimes have conflicts with existing apps.
>>
>>
>> As for python or shell scripts, I don't see why we should need any
>>python  scripts on management server, regardless if it's windows or
>>Linux.
>>Python
>> scripts can be included and executed by agents on Linux systems but I
>>don't  see a place for them on the management server.  For windows,
>>specifically,  asking a windows admin to install python is not unlike
>>asking them to install  Cygwin.
>>
>> --Alex
>>
>> > -Original Message-
>> > From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
>> > Sent: Monday, February 24, 2014 8:31 PM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: [PROPOSAL] Windowsfication Of ACS
>> >
>> > Yes, that is one of the objective to make MS not dependant on
>> > cygwin or any other windows tools and utilities. The bash scripts
>> > are all
>>converted
>> to Python.
>> >
>> > -abhi
>> >
>> >
>> > On 25/02/14 12:06 am, "Alex Huang"  wrote:
>> >
>> > >One additional requirement I have would be don't use any windows
>> > >components that don't come with the default systems targeted.  I
>> > >know it sounds great to use the latest and greatest but actually
>> > >the end users will have to install that and it may mess with their
>> > >existing setup.  In this proposal, the purely windows parts are
>> > >fairly basic parts of windows.  Don't bind it to libraries that
>> > >require installation of additional libraries.
>> > >
>> > >--Alex
>> > >
>> > >> -Original Message-
>> > >> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
>> > >> Sent: Friday, February 21, 2014 1:00 AM
>> > >> To: dev@cloudstack.apache.org
>> > >> Subject: RE: [PROPOSAL] Windowsfication Of ACS
>> > >>
>> > >> I prefer the focus on support that comes with David's suggestion.
>> > >>Targeting
>> > >> the latest stable release for a new platform greatly reduces the
>> > >>number of  permutations to test.
>> > >>
>> > >> Pursuing legacy systems limits the flexibility of ACS to evolve.
>> > >>For instance,  we'll probably be on Java 7 in the next while, and
>> > >>W2K3 doesn't appear on  the supported system list (see
>> > >>https://www.java.com/en/download/help/sysreq.xml).  Likewise,
>> > >>older versions of Internet Explorer can be quite different than
>> > >>what Microsoft has  recently published.
>> > >>
>> > >> My guess is that the engineering effort to get ACS working on a
>> > >> legacy system makes sense as a consultancy se

Re: cidrs in acls

[Daan Hoogland]

thanks, will find some time to add those.

On Wed, Feb 26, 2014 at 7:36 AM, Kishan Kavala  wrote:
> Daan,
>  I looked at the code in acl-item-cidrs. Persisting cidrs in separate table 
> looks good.
> Pending items:
>
> 1. All references to NetworkACLItemVO.getSourceCidrList() should call 
> NetworkACLItemDao.loadCidrs. Cidr list won't be available otherwise.
> 2. Migration code should be added to upgrade path to move existing cidrs to 
> new network_acl_item_cidr table
>
> Regards,
> kishan
>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Wednesday, 19 February 2014 8:33 PM
>> To: dev; Kishan Kavala
>> Subject: Re: cidrs in acls
>>
>> Kishan,
>>
>> Can you have a look  at the branch acl-item-cidrs. I made some code to
>> handle the cidrs from a separate table. I hardly think this can be enough and
>> would like to create a checklist on what I need to do next.
>> (item one is use the new transaction model;)
>>
>> thanks,
>> Daan
>>
>> On Fri, Jan 17, 2014 at 1:19 PM, Daan Hoogland
>>  wrote:
>> > That was what I thought as well. What was the retionale to join them
>> > into one field?
>> >
>> > On Fri, Jan 17, 2014 at 8:32 AM, Kishan Kavala 
>> wrote:
>> >> Daan,
>> >>   Similar to firewall_rules_cidrs, separate table can be used to store acl
>> cidrs. Maybe in network_acl_item_cidrs.
>> >>
>> >> Regards,
>> >> kishan
>> >>
>> >>> -Original Message-
>> >>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> >>> Sent: Friday, 17 January 2014 1:05 AM
>> >>> To: Kishan Kavala
>> >>> Cc: dev
>> >>> Subject: cidrs in acls
>> >>>
>> >>> H Kishan,
>> >>>
>> >>> I see you implemented CLOUDSTACK-763. it merges a lot of cidrs into
>> one field.
>> >>> The api doesn't check the field length. I enlarged the field in the
>> >>> create table statement to 2048 for the 4.3 branch. Can you help me
>> >>> think about a more solid solution, please. It seems to me those cidrs
>> shouldn't be joint into one field.
>> >>>
>> >>> regards,
>> >>> Daan
>>
>>
>>
>> --
>> Daan



-- 
Daan

Re: Review Request 17995: Added fix for CLOUDSTACK - 6164

[Santhosh Edukulla]

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

(Updated Feb. 26, 2014, 8:34 a.m.)


Review request for cloudstack and Girish Shilamkar.


Changes
---

Adding the correct patch file.


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


Repository: cloudstack-git


Description
---

Currently,Host class has a create method, uses addHost Command, but 

1. It does not verify the output of addHost command is valid output in all 
forms. 
2. Tests some times directly goes to using Host post Host.create, but we are 
not sure whether the host is up or not, they have to explicitly call again 
listHosts api call, so every where host is added list host is called. Instead, 
the create method now returns the FAILED or host object based upon the api 
success and whether the host is up. 
3. Added a try\except block and return FAILED to tests in case of an exception. 


Diffs
-

  tools/marvin/marvin/config/test_data.py PRE-CREATION 
  tools/marvin/marvin/deployDataCenter.py c8feaaf 

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


Testing
---

Tested indentation and import changes.


File Attachments (updated)


Attached wrong file. Adding correct file
  
https://reviews.apache.org/media/uploaded/files/2014/02/26/ca183e80-434c-4750-876c-fb4b6a377201__0001-Added-fix-for-CLOUDSTACK-6164.patch


Thanks,

Santhosh Edukulla

[4.3] [Cherry-pick] CLOUDSTACK-6146

[Likitha Shetty]

Animesh,

Can you cherry pick 8cb03ddb2387c7aebf20dc0aa011e41f227e9f68 and 
c652ff45dffaafa1cb0de29103e90fe936382028 from 4.3-forward to 4.3?

Thanks,
Likitha

Re: devcloud - can't mount 192.168.56.10:/opt/storage/secondary/template/tmpl/1/1

[chris snow]

Ah, just noticed the link on Rohit's page to here [1].  Looks like the
packer build will need to checkout and build cloudstack, install the
templates and then remove the install and m2 dir afterwards.

---
[1] 
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.0-incubating/html/Installation_Guide/management-server-install-flow.html#prepare-system-vm-template


On Tue, Feb 25, 2014 at 11:36 PM, chris snow  wrote:
> I have re-checked Rohit's blog page and also checked the devcloud2
> box, and I have mistakenly thought that the line beginning with '$
> #preseed ..' was a comment, but instead it seems to be another step
> that I needed to perform.
>
> The steps on Rohit's blog are:
>
>   $ mkdir -p /opt/storage/secondary
>   $ mkdir -p /opt/storage/primary
>   $ hostuuid=`xe host-list |grep uuid|awk '{print $5}'`
>   $ xe sr-create host-uuid=$hostuuid name-label=local-storage
> shared=false type=file device-config:location=/opt/storage/primary
>   $ echo "/opt/storage/secondary
> *(rw,no_subtree_check,no_root_squash,fsid=0)" > /etc/exports
>   $ #preseed systemvm template, may be copy files from devcloud's
> /opt/storage/secondary
>   $ /etc/init.d/nfs-kernel-server restart
>
> Rohit's devcloud2 environment /opt/storage/secondary folder looks like this:
>
>   root@devcloud:~# tree /opt/storage/secondary/
>   /opt/storage/secondary/
>   └── template
>   └── tmpl
>   └── 1
>   ├── 1
>   │   ├── edd5d5e5-b363-4926-a85b-d742ddd4a801.vhd
>   │   └── template.properties
>   └── 5
>   ├── ce5b212e-215a-3461-94fb-814a635b2215.vhd
>   └── template.properties
>
>   5 directories, 4 files
>
> Question 1) Am I correct in thinking that preseed'ing is a step I need
> to perform?
> Question 2) How do I preseed to create the /opt/storage/secondary
> structure as shown above?
>
> Many thanks,
>
> Chris
>
> On Mon, Feb 24, 2014 at 8:18 AM, chris snow  wrote:
>> I've fixed one issue with the new devcloud environment that I'm
>> working on, but I'm now running into another issue when running python
>> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
>>
>> WARN  [c.c.h.x.r.XenServerStorageProcessor]
>> (DirectAgent-5:ctx-c5ad1fa5) can't mount
>> 192.168.56.10:/opt/storage/secondary/template/tmpl/1/1 to
>> /var/run/cloud_mount/ad3779f0-a29d-42c0-a894-9f5198e46022
>> WARN  [c.c.h.x.r.XenServerStorageProcessor]
>> (DirectAgent-5:ctx-c5ad1fa5) Catch Exception
>> com.cloud.utils.exception.CloudRuntimeException for template +  due to
>> com.cloud.utils.exception.CloudRuntimeException: can't mount
>> 192.168.56.10:/opt/storage/secondary/template/tmpl/1/1 to
>> /var/run/cloud_mount/ad3779f0-a29d-42c0-a894-9f5198e46022
>> com.cloud.utils.exception.CloudRuntimeException: can't mount
>> 192.168.56.10:/opt/storage/secondary/
>>
>> See here for more information: https://github.com/snowch/devcloud/issues/15
>>
>> The only nfs setup that I'm doing is here:
>> https://github.com/snowch/devcloud/blob/master/packer/scripts/postinstall_nfs.sh
>>
>> Any pointers to help me resolve this will be gratefully received!
>>
>> Many thanks.
>>
>> Chris
>
>
>
> --
> Check out my professional profile and connect with me on LinkedIn.
> http://lnkd.in/cw5k69



-- 
Check out my professional profile and connect with me on LinkedIn.
http://lnkd.in/cw5k69

RE: Review Request 18310: dnsmasq fix for bridged networks

[Joris van Lieshout]

Cool! Thanks :)

Kind regards, 
Joris van Lieshout


Schuberg Philis
Boeingavenue 271
1119 PD  Schiphol-Rijk
schubergphilis.com 

+31 207506672
+31651428188
_ 


-Original Message-
From: Sheng Yang [mailto:sh...@yasker.org] 
Sent: dinsdag 25 februari 2014 23:51
To: Joris van Lieshout
Cc: daan Hoogland; Hugo Trippaers; cloudstack
Subject: Re: Review Request 18310: dnsmasq fix for bridged networks

Yes, that make sense.

DHCPINFORM wouldn't limited by "static", and seems Windows likes using it.

Would apply the patch.

Thanks.

--Sheng

On Mon, Feb 24, 2014 at 10:53 PM, Joris van Lieshout 
 wrote:
> Hi Sheng,
>
> Based on your feedback I did some testing and it appears that the issue is 
> not with offering addresses but with dhcp-options. The static option indeed 
> prevents addresses being leased to unknown macs but it does not prevent other 
> dhcp-options, like dns servers, to be handed out. So far I have not been able 
> to find any supporting documentation on this behavior but perhaps this 
> explanation is sufficient.
>
> What happens is that dhcp client on the other side of the bridge (physical 
> Lan) don't get addresses from dnsmasq on the RVM but do get dhcp-option 6 
> from the dnsmasq on the RVM.
>
> This is a bit of (scrutinized) logging where "dhcp-ignore=tag:!known" has 
> been disabled (so here non ACS hosts are getting dns server settings from the 
> RVM):
> Feb 25 00:00:00 dnsmasq-dhcp[5017]: DHCPINFORM(eth0) 10.xxx.xxx.104 
> xx:xx:xx:xx:xx:xx Feb 25 00:00:00 dnsmasq-dhcp[5017]: DHCPACK(eth0) 
> 10.xxx.xxx.104 xx:xx:xx:xx:xx:xx LAPTOP001
>
> And here with "dhcp-ignore=tag:!known" enabled:
> Feb 25 00:00:00 dnsmasq-dhcp[5079]: DHCPINFORM(eth0) 10...104 
> xx:xx:xx:xx:xx:xx ignored
>
> In both cases the dhcp-range option is set to by ACS:
> dhcp-range=10.xxx.xxx.1,static
>
> Kind regards,
> Joris van Lieshout
>
> -Original Message-
> From: Sheng Yang [mailto:sh...@yasker.org]
> Sent: maandag 24 februari 2014 23:30
> To: Joris van Lieshout
> Cc: daan Hoogland; Hugo Trippaers; cloudstack
> Subject: Re: Review Request 18310: dnsmasq fix for bridged networks
>
> Yes, it would provide extra failsafe.
>
> But the issue is if there is anything wrong, this patch may or may not 
> prevent it. So I think it's necessary to identify the root cause 
> first.
>
> The dhcp-range option already specified as "static" which means:
>
> 
> The optional  keyword may be static which tells dnsmasq to 
> enable DHCP for the network specified, but not to dynamically allocate 
> IP addresses: only hosts which have static addresses given via 
> dhcp-host or from /etc/ethers will be served. A static-only subnet 
> with address all zeros may be used as a "catch-all" address to enable 
> replies to all Information-request packets on a subnet which is 
> provided with stateless DHCPv6, ie --dhcp=range=::,static 
>
> So it should already served the purpose.
>
> --Sheng
>
> On Sat, Feb 22, 2014 at 9:28 AM, Joris van Lieshout 
>  wrote:
>> Hi Sheng,
>>
>> First of thanks you for reviewing my first attempt to contribute :) 
>> and sorry for my late response. I want to gadder a bit more info 
>> because I've seen it hand out adresses. Besides that this setting 
>> should at least provide an extra failsafe.
>>
>> Regards, Joris
>>
>> Sent from my iPhone
>>
>> On 21 feb. 2014, at 20:00, "Sheng Yang"  wrote:
>>
>> Hi Joris,
>>
>> This patch hasn't been applied yet, sorry for my second thought.
>>
>> Could you comment on it?
>>
>> --Sheng
>>
>>
>> On Thu, Feb 20, 2014 at 10:29 AM, Sheng Yang  wrote:
>>>
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/18310/
>>>
>>> On February 20th, 2014, 6:17 p.m. UTC, Sheng Yang wrote:
>>>
>>> Looks good to me.
>>>
>>> Also I've confirmed that even with this option, the MAC would show 
>>> in dnsmasq.log, which is necessary for debug.
>>>
>>> Applied to MASTER. Thanks!
>>>
>>> On February 20th, 2014, 6:28 p.m. UTC, Sheng Yang wrote:
>>>
>>> One moment, on a second thought, even with current setup, dnsmasq 
>>> won't hand out IP to unknown host. So why this option is needed?
>>>
>>> And the log would show "DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 no 
>>> address available" instead of "DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 
>>> ignored" with the option.
>>>
>>> Is there anything I missed?
>>>
>>> And the patch hasn't been applied yet...
>>>
>>>
>>> - Sheng
>>>
>>>
>>> On February 20th, 2014, 2:01 p.m. UTC, Joris van Lieshout wrote:
>>>
>>> Review request for cloudstack, daan Hoogland, Hugo Trippaers, and 
>>> Sheng Yang.
>>> By Joris van Lieshout.
>>>
>>> Updated Feb. 20, 2014, 2:01 p.m.
>>>
>>> Repository: cloudstack-git
>>>
>>> Description
>>>
>>> When a ACS network is bridged to another non-ACS network (for 
>>> instance using a NSX Bridge) this will prevent dnsmasq from 
>>> responding to requests from the other network that have traversed the 
>>> bridge.
>>>
>>> Testing
>>>
>>> We have been running this 

Jenkins build is back to normal : build-master-noredist #2357

[jenkins]

See 

Build failed in Jenkins: build-master-slowbuild #303

[jenkins]

See 

--
[...truncated 17678 lines...]
Running com.cloud.gate.testcase.BaseTestCase
Configure log4j with default properties
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec

Results :

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-awsapi <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-awsapi ---
[INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/amazon/ec2/AmazonEC2SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/amazon/s3/AmazonS3SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SAcl.java.  Ensure this class was instrumented, and this 
data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SBucket.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SHost.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/BucketPolicyDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackAccountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java.  Ensure this 
class was instrumented, and this data file contains the instrumentation 
information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java.  Ensure this class 
was instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackUserDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostMountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartPartsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartUploadsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultipartMetaDao.java.  Ensure this class was 
inst

Re: Yet another mail on code quality

[Hugo Trippaers]

Thank Rajani!

I’ve put the information on using FindBugs here: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Using+FindBugs

Cheers,

Hugo

On 26 feb. 2014, at 07:31, Rajani Karuturi  wrote:

> intellij findbugs plugin can be downloaded @ 
> http://plugins.jetbrains.com/plugin/3847
> once its installed, you can right click on the file -> FindBugs -> Analyze 
> current file
> This will show the results in the find bugs console with a nice explanation 
> for each error.
> 
> you could also run $mvn findbugs:check -PDeveloper -Dsimulator -pl 
> :cloud-plugin-hypervisor-simulator from the source root for any project.
> The results will also be at SOURCE-ROOT/module-dir/target/findbugs.xml
> 
> ~Rajani
> 
> 
> 
> On 26-Feb-2014, at 11:03 am, Abhinandan Prateek 
> mailto:abhinandan.prat...@citrix.com>> wrote:
> 
> Hugo,
> 
> It will benefit the community if you can advise on how to setup the find
> bug tool. Is there a wiki on how to use find bug ?
> I know some tools that you can install on eclipse, but not sure about
> intellij etc.
> 
> -abhi
> 
> On 24/02/14 9:44 pm, "Hugo Trippaers" 
> mailto:h...@trippaers.nl>> wrote:
> 
> Guys,
> 
> Please pay attention to the code you are committing. Today i fixed a
> number of issues that were introduced in recent code, these are bugs that
> could have been prevented from entering master by either testing or
> running the findbugs checks. One was committed directly, the other one
> through a reviewed patch.
> 
> 
> @@ -116,7 +116,7 @@ public class Upgrade430to440 implements DbUpgrade {
>   if (networkRs.next()) {
>   String guesttype = networkRs.getString(1);
> 
> -if (guesttype ==
> Network.GuestType.Shared.toString()) {
> +if
> (guesttype.equals(Network.GuestType.Shared.toString())) {
>   pstmtUpdate =
> conn.prepareStatement("UPDATE `cloud`.`user_ip_address` SET account_id =
> ?, domain_id= ? WHERE public_ip_address = ?");
>   pstmtUpdate.setLong(1,vmAccountId);
>   pstmtUpdate.setLong(2,vmDomainId);
> 
> 
> 
> @@ -80,11 +80,11 @@ public class LibvirtStoragePoolXMLParser {
>   String targetPath = getTagValue("path", target);
> 
>   String portValue = getAttrValue("host", "port", source);
> -if (portValue != "")
> +if (portValue != null && !portValue.isEmpty())
>   port = Integer.parseInt(portValue);
> 
>   return new
> LibvirtStoragePoolDef(LibvirtStoragePoolDef.poolType.valueOf(format.toUppe
> rCase()),
> 
> 
> To help, i¹ve configured the slowbuild to alert if the number of high
> priority findings from findbugs differs from the previous run. It will
> notify all developers that had changes during this period (slowbuild runs
> every 4 hours).
> 
> Cheers,
> 
> Hugo
> 

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Antonio Fornie]

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

(Updated Feb. 26, 2014, 9:12 a.m.)


Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and Hugo 
Trippaers.


Changes
---

Fix based on last comments. Mainly adding signature and apikey to the geeric 
expected params.


Repository: cloudstack-git


Description
---

Dispatcher corrections, refactoring and tests. Corrects problems from previous 
attempts that were reverted by Alena. Most of the changes are the same, but 
this one is not creating conflicts of Map types for Aync Commands or for 
parameters as Lists or Maps.


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
  api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
  api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
  api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java 592b828 
  api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java 
de6e550 
  
api/src/org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmProfileCmd.java
 06d86ec 
  server/resources/META-INF/cloudstack/core/spring-server-core-misc-context.xml 
fd2f5fb 
  server/src/com/cloud/api/ApiAsyncJobDispatcher.java 71ac616 
  server/src/com/cloud/api/ApiDispatcher.java ed95c72 
  server/src/com/cloud/api/ApiServer.java d715db6 
  server/src/com/cloud/api/ApiServlet.java 46f7eba 
  server/src/com/cloud/api/dispatch/CommandCreationWorker.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchChain.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchChainFactory.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchTask.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchWorker.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamGenericValidationWorker.java 
PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamProcessWorker.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamSemanticValidationWorker.java 
PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamUnpackWorker.java PRE-CREATION 
  server/src/com/cloud/network/as/AutoScaleManagerImpl.java ff2b2ea 
  server/src/com/cloud/storage/snapshot/SnapshotSchedulerImpl.java 3159059 
  server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
  server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
PRE-CREATION 

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


Testing
---

Full build and test plus manually testing many features. Also including 
CreateTagsCommand that failed in previous commit.

All unit and integration tests.

Test CS Web UI with the browser going through several use cases.

Also use the CS API by sending HTTP requests generated manually including 
requests for Async Commands with Map parameters and during these tests apart 
fromtesting correct functionality I also debugged to check that Maps created 
correctly where they should but also that in the cases where the async command 
must be persisted and later on retrieved and deserialized by gson everything 
works ok and does what and where is expected. An example based on the comment 
by Alena:
http://localhost:8096/client/api?command=createTags&resourceids=ids&resourcetype=type&tags[0].key=region&tags[0].value=canada
Also other examples like
http://localhost:8096/client/api?command=createSecondaryStagingStore&url=httpbla&details[0].key=region&details[0].value=canada&details[1].key=element&details[1].value=fire


Thanks,

Antonio Fornie

Failed to create a template

[Tejas Gadaria]

Hi,

I am trying to create template on vmware with CS 4.0.2, its giving

2014-02-26 14:21:44,578 DEBUG [agent.transport.Request]
(AgentManager-Handler-1:null) Seq 39-1804402824: Processing:  { Ans: ,
MgmtId: 345051457089, via: 39, Ver: v1, Flags: 10,
[{"storage.CreatePrivateTemplateAnswer":{"_virtualSize":0,"_physicalSize":0,"result":false,"details":"CreatePrivateTemplateFromVolumeCommand
exception: java.lang.Exception: unable to prepare template directory:
template/tmpl/4/256, storage: nfs://10.129.150.25/vol/Cloud/Secondary,
error msg: mkdir: cannot create directory
`/mnt/SecStorage/72b70605-0c7c-37af-bb6e-4cf0b65760db/template/tmpl/4/256':
Permission
denied\ncom.cloud.hypervisor.vmware.manager.VmwareStorageManagerImpl.createTemplateFromVolume(VmwareStorageManagerImpl.java:497)\ncom.cloud.hypervisor.vmware.manager.VmwareStorageManagerImpl.execute(VmwareStorageManagerImpl.java:277)\ncom.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.execute(VmwareSecondaryStorageResourceHandler.java:121)\ncom.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.executeRequest(VmwareSecondaryStorageResourceHandler.java:73)\ncom.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:54)\ncom.cloud.agent.Agent.processRequest(Agent.java:518)\ncom.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:831)\ncom.cloud.utils.nio.Task.run(Task.java:83)\njava.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)\njava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)\njava.lang.Thread.run(Thread.java:662)\n","wait":0}}]
}
2014-02-26 14:21:44,578 DEBUG [agent.transport.Request]
(Job-Executor-7:job-99) Seq 39-1804402824: Received:  { Ans: , MgmtId:
345051457089, via: 39, Ver: v1, Flags: 10, { CreatePrivateTemplateAnswer } }
2014-02-26 14:21:44,718 DEBUG [cloud.server.StatsCollector]
(StatsCollector-3:null) VmStatsCollector is running...
2014-02-26 14:21:44,727 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-278:null) Seq 28-1947018449: Executing request
2014-02-26 14:21:44,782 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-294:null) Seq 21-1191253522: Response Received:
2014-02-26 14:21:44,782 DEBUG [agent.transport.Request]
(StatsCollector-2:null) Seq 21-1191253522: Received:  { Ans: , MgmtId:
345051457089, via: 21, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
2014-02-26 14:21:44,786 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-222:null) Seq 28-1947018450: Executing request
2014-02-26 14:21:44,801 ERROR [cloud.api.ApiDispatcher]
(Job-Executor-7:job-99) Exception while executing CreateTemplateCmd:
com.cloud.utils.exception.CloudRuntimeException: Failed to create a template
at
com.cloud.vm.UserVmManagerImpl.createPrivateTemplate(UserVmManagerImpl.java:1662)
at
com.cloud.utils.component.ComponentLocator$InterceptorDispatcher.intercept(ComponentLocator.java:1231)
at
com.cloud.vm.UserVmManagerImpl.createPrivateTemplate(UserVmManagerImpl.java:237)
at
com.cloud.api.commands.CreateTemplateCmd.execute(CreateTemplateCmd.java:265)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:432)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2014-02-26 14:21:44,801 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-7:job-99) Complete async job-99, jobStatus: 2, resultCode:
530, result: Error Code: 530 Error text: Failed to create a template


Need help

Regards,
Tejas

Re: Build failed in Jenkins: build-master-slowbuild #300

[Hugo Trippaers]

Daan,

You have the dubious honor to be the first victim of the findbugs check :-)

Can you check your commit b0c6d4734724358df97b6fa4d8c5beb0f447745e?


Cheers,

Hugo

On 26 feb. 2014, at 01:05, jenk...@cloudstack.org wrote:

> See 
> 
> Changes:
> 
> [jessicawang] BUG-ID: CLOUDSTACK-6162: UI > zone > physical network > service 
> provider > add OVS.
> 
> [laszlo.hornyak] replace String != operation with .equals
> 
> [laszlo.hornyak] Fixed some resource files issues, namely 1) invalid text and 
> duplicate keys resulting from bad merge and 2) trailing spaces which can 
> potentially cause UI issues.
> 
> [Daan Hoogland] - Updated APICommand annotation to add new flags that 
> indicate if API request or response carry sensitive info - Updated all API 
> classes with the new annotation flag values as per the API's sensitivity - 
> Updated server code to check response annotation before audit logging
> 
> [sheng.yang] Prevent DHCPACK for DHCPINFORM in the DHCP server
> 
> --
> [...truncated 17678 lines...]
> Running com.cloud.gate.testcase.BaseTestCase
> Configure log4j with default properties
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> 
> Results :
> 
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
> 
> [INFO] 
> [INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-awsapi 
> <<<
> [INFO] 
> [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-awsapi 
> ---
> [INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/amazon/ec2/AmazonEC2SkeletonInterface.java.  Ensure this class was 
> instrumented, and this data file contains the instrumentation information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/amazon/s3/AmazonS3SkeletonInterface.java.  Ensure this class was 
> instrumented, and this data file contains the instrumentation information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/cloud/bridge/model/SAcl.java.  Ensure this class was instrumented, and 
> this data file contains the instrumentation information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/cloud/bridge/model/SBucket.java.  Ensure this class was instrumented, and 
> this data file contains the instrumentation information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/cloud/bridge/model/SHost.java.  Ensure this class was instrumented, and 
> this data file contains the instrumentation information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/cloud/bridge/persist/dao/BucketPolicyDao.java.  Ensure this class was 
> instrumented, and this data file contains the instrumentation information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/cloud/bridge/persist/dao/CloudStackAccountDao.java.  Ensure this class 
> was instrumented, and this data file contains the instrumentation information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java.  Ensure this 
> class was instrumented, and this data file contains the instrumentation 
> information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java.  Ensure this 
> class was instrumented, and this data file contains the instrumentation 
> information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/cloud/bridge/persist/dao/CloudStackUserDao.java.  Ensure this class was 
> instrumented, and this data file contains the instrumentation information.
> [cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport 
> - Data file does not contain instrumentation information for the file 
> com/cloud/bridge/persist/dao/MHostDao.java.  Ensure this class was 
> instrumented, and this data file contains the instrumentation information.
> [cobertura]

RE: Failed to create a template

[Sailaja Mada]

Hi,

This seems similar to the bug @ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3604  . It is root caused to 
permissions set on the folder.

Can you please check the permissions set on the secondary storage folder . 

Thanks,
Sailaja.M

-Original Message-
From: Tejas Gadaria [mailto:refond.g...@gmail.com] 
Sent: 26 February 2014 14:45
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Failed to create a template

Hi,

I am trying to create template on vmware with CS 4.0.2, its giving

2014-02-26 14:21:44,578 DEBUG [agent.transport.Request]
(AgentManager-Handler-1:null) Seq 39-1804402824: Processing:  { Ans: ,
MgmtId: 345051457089, via: 39, Ver: v1, Flags: 10, 
[{"storage.CreatePrivateTemplateAnswer":{"_virtualSize":0,"_physicalSize":0,"result":false,"details":"CreatePrivateTemplateFromVolumeCommand
exception: java.lang.Exception: unable to prepare template directory:
template/tmpl/4/256, storage: nfs://10.129.150.25/vol/Cloud/Secondary,
error msg: mkdir: cannot create directory
`/mnt/SecStorage/72b70605-0c7c-37af-bb6e-4cf0b65760db/template/tmpl/4/256':
Permission
denied\ncom.cloud.hypervisor.vmware.manager.VmwareStorageManagerImpl.createTemplateFromVolume(VmwareStorageManagerImpl.java:497)\ncom.cloud.hypervisor.vmware.manager.VmwareStorageManagerImpl.execute(VmwareStorageManagerImpl.java:277)\ncom.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.execute(VmwareSecondaryStorageResourceHandler.java:121)\ncom.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.executeRequest(VmwareSecondaryStorageResourceHandler.java:73)\ncom.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:54)\ncom.cloud.agent.Agent.processRequest(Agent.java:518)\ncom.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:831)\ncom.cloud.utils.nio.Task.run(Task.java:83)\njava.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)\njava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)\njava.lang.Thread.run(Thread.java:662)\n","wait":0}}]
}
2014-02-26 14:21:44,578 DEBUG [agent.transport.Request]
(Job-Executor-7:job-99) Seq 39-1804402824: Received:  { Ans: , MgmtId:
345051457089, via: 39, Ver: v1, Flags: 10, { CreatePrivateTemplateAnswer } }
2014-02-26 14:21:44,718 DEBUG [cloud.server.StatsCollector]
(StatsCollector-3:null) VmStatsCollector is running...
2014-02-26 14:21:44,727 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-278:null) Seq 28-1947018449: Executing request
2014-02-26 14:21:44,782 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-294:null) Seq 21-1191253522: Response Received:
2014-02-26 14:21:44,782 DEBUG [agent.transport.Request]
(StatsCollector-2:null) Seq 21-1191253522: Received:  { Ans: , MgmtId:
345051457089, via: 21, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
2014-02-26 14:21:44,786 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-222:null) Seq 28-1947018450: Executing request
2014-02-26 14:21:44,801 ERROR [cloud.api.ApiDispatcher]
(Job-Executor-7:job-99) Exception while executing CreateTemplateCmd:
com.cloud.utils.exception.CloudRuntimeException: Failed to create a template
at
com.cloud.vm.UserVmManagerImpl.createPrivateTemplate(UserVmManagerImpl.java:1662)
at
com.cloud.utils.component.ComponentLocator$InterceptorDispatcher.intercept(ComponentLocator.java:1231)
at
com.cloud.vm.UserVmManagerImpl.createPrivateTemplate(UserVmManagerImpl.java:237)
at
com.cloud.api.commands.CreateTemplateCmd.execute(CreateTemplateCmd.java:265)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:432)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2014-02-26 14:21:44,801 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-7:job-99) Complete async job-99, jobStatus: 2, resultCode:
530, result: Error Code: 530 Error text: Failed to create a template


Need help

Regards,
Tejas

[jira] punith shared "CLOUDSTACK-6173: Implement a CloudByte storage plugin." with you

[punith (JIRA)]

punith shared an issue with you




> Implement a CloudByte storage plugin.
> -
>
> Key: CLOUDSTACK-6173
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6173
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
>Affects Versions: Future, 4.4.0
> Environment: All supported CloudStack platforms
>Reporter: punith
>   Original Estimate: $issue.getNiceTimeOriginalEstimate($i18n)
>  Remaining Estimate: $issue.getNiceTimeEstimate($i18n)
>
> The new plugin will follow the design principles abstracted by CloudStack API 
> for implementing a storage plugin.
> This new enhancement will try to reuse the QoS params ( i.e. max IOPs) 
> exposed in the modified Disk-Offering UI page.
>  
>  The basic behavior of this plugin will be to :
>  - Allow CloudStack(CS) Admin to invoke CS API to add Primary Storage based 
> on Elastistor's plug-in.
> This will create a volume (Storage IP:/path)  in the Elastistor.
> The newly created volume will be attached as a SR in Xen Hypervisor.
>  - Allow CS Admin to create a desired Disk Offering. The access control 
> followed for creation of Disk Offering will be maintained in this feature too.
>  - Allow an end user to use above created Disk Offering to add a new Volume.
>  - Allow an end user to attach the above created volume (i.e. DataDisk) to a 
> VM. 
>  - Allow an end user to detach a volume from a VM.
>  - Allow an end user to delete a volume from a VM.
>  - Allow and end user to edit the iops of the data disk on fly without 
> detaching it.
>  - support for both nfs and iscsi at primary storage.
>  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Build failed in Jenkins: build-master-slowbuild #300

[Daan Hoogland]

At a desk in 20 :/

mobile bilingual spell checker used
Op 26 feb. 2014 10:19 schreef "Hugo Trippaers" :

> Daan,
>
> You have the dubious honor to be the first victim of the findbugs check :-)
>
> Can you check your commit b0c6d4734724358df97b6fa4d8c5beb0f447745e?
>
>
> Cheers,
>
> Hugo
>
> On 26 feb. 2014, at 01:05, jenk...@cloudstack.org wrote:
>
> > See <
> http://jenkins.buildacloud.org/job/build-master-slowbuild/300/changes>
> >
> > Changes:
> >
> > [jessicawang] BUG-ID: CLOUDSTACK-6162: UI > zone > physical network >
> service provider > add OVS.
> >
> > [laszlo.hornyak] replace String != operation with .equals
> >
> > [laszlo.hornyak] Fixed some resource files issues, namely 1) invalid
> text and duplicate keys resulting from bad merge and 2) trailing spaces
> which can potentially cause UI issues.
> >
> > [Daan Hoogland] - Updated APICommand annotation to add new flags that
> indicate if API request or response carry sensitive info - Updated all API
> classes with the new annotation flag values as per the API's sensitivity -
> Updated server code to check response annotation before audit logging
> >
> > [sheng.yang] Prevent DHCPACK for DHCPINFORM in the DHCP server
> >
> > --
> > [...truncated 17678 lines...]
> > Running com.cloud.gate.testcase.BaseTestCase
> > Configure log4j with default properties
> > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> >
> > Results :
> >
> > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
> >
> > [INFO]
> > [INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @
> cloud-awsapi <<<
> > [INFO]
> > [INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @
> cloud-awsapi ---
> > [INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT
> file
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/amazon/ec2/AmazonEC2SkeletonInterface.java.  Ensure this class was
> instrumented, and this data file contains the instrumentation information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/amazon/s3/AmazonS3SkeletonInterface.java.  Ensure this class was
> instrumented, and this data file contains the instrumentation information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/cloud/bridge/model/SAcl.java.  Ensure this class was instrumented, and
> this data file contains the instrumentation information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/cloud/bridge/model/SBucket.java.  Ensure this class was instrumented,
> and this data file contains the instrumentation information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/cloud/bridge/model/SHost.java.  Ensure this class was instrumented, and
> this data file contains the instrumentation information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/cloud/bridge/persist/dao/BucketPolicyDao.java.  Ensure this class was
> instrumented, and this data file contains the instrumentation information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/cloud/bridge/persist/dao/CloudStackAccountDao.java.  Ensure this class
> was instrumented, and this data file contains the instrumentation
> information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java.  Ensure this
> class was instrumented, and this data file contains the instrumentation
> information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java.  Ensure this
> class was instrumented, and this data file contains the instrumentation
> information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation information for the file
> com/cloud/bridge/persist/dao/CloudStackUserDao.java.  Ensure this class was
> instrumented, and this data file contains the instrumentation information.
> > [cobertura] INFO  [main]
> net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not
> contain instrumentation infor

Re: Failed to create a template

[Tejas Gadaria]

Hi Sailaja,

Thanks for replay,

I am always running Management server under root.
Do I need to delete stale systemvm.iso and try it?

Regards,
Tejas



On Wed, Feb 26, 2014 at 2:52 PM, Sailaja Mada wrote:

> Hi,
>
> This seems similar to the bug @
> https://issues.apache.org/jira/browse/CLOUDSTACK-3604  . It is root
> caused to permissions set on the folder.
>
> Can you please check the permissions set on the secondary storage folder .
>
> Thanks,
> Sailaja.M
>
> -Original Message-
> From: Tejas Gadaria [mailto:refond.g...@gmail.com]
> Sent: 26 February 2014 14:45
> To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
> Subject: Failed to create a template
>
> Hi,
>
> I am trying to create template on vmware with CS 4.0.2, its giving
>
> 2014-02-26 14:21:44,578 DEBUG [agent.transport.Request]
> (AgentManager-Handler-1:null) Seq 39-1804402824: Processing:  { Ans: ,
> MgmtId: 345051457089, via: 39, Ver: v1, Flags: 10,
> [{"storage.CreatePrivateTemplateAnswer":{"_virtualSize":0,"_physicalSize":0,"result":false,"details":"CreatePrivateTemplateFromVolumeCommand
> exception: java.lang.Exception: unable to prepare template directory:
> template/tmpl/4/256, storage: nfs://10.129.150.25/vol/Cloud/Secondary,
> error msg: mkdir: cannot create directory
> `/mnt/SecStorage/72b70605-0c7c-37af-bb6e-4cf0b65760db/template/tmpl/4/256':
> Permission
>
> denied\ncom.cloud.hypervisor.vmware.manager.VmwareStorageManagerImpl.createTemplateFromVolume(VmwareStorageManagerImpl.java:497)\ncom.cloud.hypervisor.vmware.manager.VmwareStorageManagerImpl.execute(VmwareStorageManagerImpl.java:277)\ncom.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.execute(VmwareSecondaryStorageResourceHandler.java:121)\ncom.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.executeRequest(VmwareSecondaryStorageResourceHandler.java:73)\ncom.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:54)\ncom.cloud.agent.Agent.processRequest(Agent.java:518)\ncom.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:831)\ncom.cloud.utils.nio.Task.run(Task.java:83)\njava.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)\njava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)\njava.lang.Thread.run(Thread.java:662)\n","wait":0}}]
> }
> 2014-02-26 14:21:44,578 DEBUG [agent.transport.Request]
> (Job-Executor-7:job-99) Seq 39-1804402824: Received:  { Ans: , MgmtId:
> 345051457089, via: 39, Ver: v1, Flags: 10, { CreatePrivateTemplateAnswer }
> }
> 2014-02-26 14:21:44,718 DEBUG [cloud.server.StatsCollector]
> (StatsCollector-3:null) VmStatsCollector is running...
> 2014-02-26 14:21:44,727 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-278:null) Seq 28-1947018449: Executing request
> 2014-02-26 14:21:44,782 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-294:null) Seq 21-1191253522: Response Received:
> 2014-02-26 14:21:44,782 DEBUG [agent.transport.Request]
> (StatsCollector-2:null) Seq 21-1191253522: Received:  { Ans: , MgmtId:
> 345051457089, via: 21, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
> 2014-02-26 14:21:44,786 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-222:null) Seq 28-1947018450: Executing request
> 2014-02-26 14:21:44,801 ERROR [cloud.api.ApiDispatcher]
> (Job-Executor-7:job-99) Exception while executing CreateTemplateCmd:
> com.cloud.utils.exception.CloudRuntimeException: Failed to create a
> template
> at
>
> com.cloud.vm.UserVmManagerImpl.createPrivateTemplate(UserVmManagerImpl.java:1662)
> at
>
> com.cloud.utils.component.ComponentLocator$InterceptorDispatcher.intercept(ComponentLocator.java:1231)
> at
>
> com.cloud.vm.UserVmManagerImpl.createPrivateTemplate(UserVmManagerImpl.java:237)
> at
>
> com.cloud.api.commands.CreateTemplateCmd.execute(CreateTemplateCmd.java:265)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:432)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2014-02-26 14:21:44,801 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-7:job-99) Complete async job-99, jobStatus: 2, resultCode:
> 530, result: Error Code: 530 Error text: Failed to create a template
>
>
> Need help
>
> Regards,
> Tejas
>

license analysis

[Daan Hoogland]

H,

I made contact with Armijn Hemel (Tjaldur Software Governance Solutions) who 
scans software for the purpose of making sure no unwanted licenses are in 
products. I am going to ask him to look at a Jenkins 4.3 build and talk about 
the results. He does this for a living so money may be involved but he is also 
a oss enthusiast so maybe not so much.

Will let you know,
Daan

Re: CLOUDSTACK-5663

[Saurav Lahiri]

Thank you very much. I will follow up on this with Parth.


Saurav


On Tue, Feb 25, 2014 at 11:50 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> Thank you, Dave.
>
> Saurav, I¹ve assigned the bug to you.
>
> -Alena.
>
> On 2/25/14, 10:15 AM, "David Nalley"  wrote:
>
> >> As for the bug, you need to be added to the Jira users DB in order to
> >> become an assignee. Whoever administers Jira, can you please do it?
> >>
> >
> >
> >Done
> >
> >--David
>
>
>

Re: 4.4 Feature Freeze

[Abhinandan Prateek]

+1 for 4.4 feature freeze on 3/28.

On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
 wrote:

>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: 26 February 2014 04:46
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>> 
>> I think this is a good idea, Animesh (to push out feature freeze to
>>3/28).
>
>+1 to move 4.4 feature freeze date to 3/28.
>
>Regards,
>Sateesh 
>
>> I also agree we should discuss 4+ month development cycles again.
>> 
>> 
>> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
>>animesh.chaturv...@citrix.com> wrote:
>> 
>> > I will start a separate discussion on 4 month cycle or longer, but
>> > wanted to call out one more important date.
>> >
>> > We have a last day for feature proposal date which is typically a
>> > month before feature freeze date. If following 4.3 schedule + 4 month
>> > it would have been 2/14 and we are already past that. Since it was not
>> > announced for
>> > 4.4 release yet my suggestion would be to keep feature proposal open
>> > for another week and push all  the dates out by 2 weeks to give folks
>> > opportunity to finish up their features for new proposals that are yet
>> > to come out.
>> >
>> > To be clear that would mean pushing out feature freeze to 3/28 from
>> > 3/14 and all the other dates likewise.
>> >
>> >
>> > Thanks
>> > Animesh
>> >
>> > > -Original Message-
>> > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> > > Sent: Tuesday, February 25, 2014 1:05 PM
>> > > To: dev@cloudstack.apache.org
>> > > Subject: RE: 4.4 Feature Freeze
>> > >
>> > > With the experience of 4.2 and 4.3 I think we should discuss if we
>> > > can realistically achieve 4 month cycle our RCs take 2 months. I was
>> > > going to open up the discussion after 4.3 is shipped though.
>> > >
>> > > > -Original Message-
>> > > > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
>> > > > Trippaers
>> > > > Sent: Tuesday, February 25, 2014 8:50 AM
>> > > > To: 
>> > > > Subject: Re: 4.4 Feature Freeze
>> > > >
>> > > > Hey,
>> > > >
>> > > > If we stick to our 4 month release schedule the feature freeze is
>> > > > four months after the feature freeze of 4.3. The feature freeze of
>> > > > 4.3 was
>> > 8 Nov
>> > > 2013.
>> > > >
>> > > > So the proposed release schedule for 4.4 would look like this
>> > > > (dates slightly modified to take efficiency and RM's personal life
>> > > > into
>> > account ;-) ):
>> > > >
>> > > > Feature Freeze: March 14, 2014
>> > > > Testing/Bug Fixes:  March 15, 2014 till April 18,
>>2014
>> > > > (direct access for committers)
>> > > > Stability Fixes only:   April 19, 2014 till
>> > release (cherry picks
>> > > > by RM only)
>> > > > First RC:   May 9, 2014
>> > > > Optimistic Release Date:May 19, 2014
>> > > >
>> > > > Cheers,
>> > > >
>> > > > Hugo
>> > > >
>> > > >
>> > > > On 25 feb. 2014, at 16:35, Sudha Ponnaganti
>> > > > 
>> > > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > I am also looking for feature freeze dates for 4.4. Can RM post
>> > those?
>> > > > >
>> > > > > Thanks
>> > > > > /Sudha
>> > > > >
>> > > > > -Original Message-
>> > > > > From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
>> > > > > Sent: Tuesday, February 25, 2014 7:00 AM
>> > > > > To: dev@cloudstack.apache.org
>> > > > > Subject: 4.4 Feature Freeze
>> > > > >
>> > > > > All,
>> > > > >
>> > > > > I know the 4.3 isn't quite out the door yet, but is there a
>> > > > > timetable
>> > > > somewhere stating when the feature freeze for 4.4 will be?
>> > > > >
>> > > > > I would like to submit a feature and want to ensure that It's
>> > > > > prepared in
>> > > > time.
>> > > > >
>> > > > > Many thanks,
>> > > > >
>> > > > > Alex
>> > > > >
>> > > > >
>> > > > > Regards,
>> > > > >
>> > > > > Alex Hitchins
>> > > > > VP Software Engineering
>> > > > > D: +44 1892 523 587 | S: +44 20 3603 0540 |
>>M:
>> > > > +44 7788 423 969
>> > > > >
>> > > > > ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>> > > > >
>> > > > > Need Enterprise Grade Support for Apache CloudStack?
>> > > > > Our CloudStack Infrastructure
>> > > > > Support> > > > infrastructure-support/> offers the best 24/7 SLA for CloudStack
>> > > > Environments.
>> > > > >
>> > > > > Apache CloudStack Bootcamp training courses
>> > > > >
>> > > > > **NEW!** CloudStack 4.2.1
>> > > > > training> > > > training/>
>> > > > > 18th-19th February 2014, Brazil.
>> > > > Classroom
>> > > > > 17th-23rd March 2014, Region A. Instructor led, On-
>> > > > line
>> > > > > 24th-28th March 2014, Region B. Instructor led, On-
>> > > > line
>> > > > > 16th-20th June 2014, Region A. Instructor

Re: 4.4 Feature Freeze

[Guo Star]

+1


2014-02-26 20:01 GMT+08:00 Abhinandan Prateek :

> +1 for 4.4 feature freeze on 3/28.
>
> On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
>  wrote:
>
> >> -Original Message-
> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> Sent: 26 February 2014 04:46
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: 4.4 Feature Freeze
> >>
> >> I think this is a good idea, Animesh (to push out feature freeze to
> >>3/28).
> >
> >+1 to move 4.4 feature freeze date to 3/28.
> >
> >Regards,
> >Sateesh
> >
> >> I also agree we should discuss 4+ month development cycles again.
> >>
> >>
> >> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
> >>animesh.chaturv...@citrix.com> wrote:
> >>
> >> > I will start a separate discussion on 4 month cycle or longer, but
> >> > wanted to call out one more important date.
> >> >
> >> > We have a last day for feature proposal date which is typically a
> >> > month before feature freeze date. If following 4.3 schedule + 4 month
> >> > it would have been 2/14 and we are already past that. Since it was not
> >> > announced for
> >> > 4.4 release yet my suggestion would be to keep feature proposal open
> >> > for another week and push all  the dates out by 2 weeks to give folks
> >> > opportunity to finish up their features for new proposals that are yet
> >> > to come out.
> >> >
> >> > To be clear that would mean pushing out feature freeze to 3/28 from
> >> > 3/14 and all the other dates likewise.
> >> >
> >> >
> >> > Thanks
> >> > Animesh
> >> >
> >> > > -Original Message-
> >> > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> >> > > Sent: Tuesday, February 25, 2014 1:05 PM
> >> > > To: dev@cloudstack.apache.org
> >> > > Subject: RE: 4.4 Feature Freeze
> >> > >
> >> > > With the experience of 4.2 and 4.3 I think we should discuss if we
> >> > > can realistically achieve 4 month cycle our RCs take 2 months. I was
> >> > > going to open up the discussion after 4.3 is shipped though.
> >> > >
> >> > > > -Original Message-
> >> > > > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> >> > > > Trippaers
> >> > > > Sent: Tuesday, February 25, 2014 8:50 AM
> >> > > > To: 
> >> > > > Subject: Re: 4.4 Feature Freeze
> >> > > >
> >> > > > Hey,
> >> > > >
> >> > > > If we stick to our 4 month release schedule the feature freeze is
> >> > > > four months after the feature freeze of 4.3. The feature freeze of
> >> > > > 4.3 was
> >> > 8 Nov
> >> > > 2013.
> >> > > >
> >> > > > So the proposed release schedule for 4.4 would look like this
> >> > > > (dates slightly modified to take efficiency and RM's personal life
> >> > > > into
> >> > account ;-) ):
> >> > > >
> >> > > > Feature Freeze: March 14, 2014
> >> > > > Testing/Bug Fixes:  March 15, 2014 till April 18,
> >>2014
> >> > > > (direct access for committers)
> >> > > > Stability Fixes only:   April 19, 2014 till
> >> > release (cherry picks
> >> > > > by RM only)
> >> > > > First RC:   May 9, 2014
> >> > > > Optimistic Release Date:May 19, 2014
> >> > > >
> >> > > > Cheers,
> >> > > >
> >> > > > Hugo
> >> > > >
> >> > > >
> >> > > > On 25 feb. 2014, at 16:35, Sudha Ponnaganti
> >> > > > 
> >> > > > wrote:
> >> > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > I am also looking for feature freeze dates for 4.4. Can RM post
> >> > those?
> >> > > > >
> >> > > > > Thanks
> >> > > > > /Sudha
> >> > > > >
> >> > > > > -Original Message-
> >> > > > > From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
> >> > > > > Sent: Tuesday, February 25, 2014 7:00 AM
> >> > > > > To: dev@cloudstack.apache.org
> >> > > > > Subject: 4.4 Feature Freeze
> >> > > > >
> >> > > > > All,
> >> > > > >
> >> > > > > I know the 4.3 isn't quite out the door yet, but is there a
> >> > > > > timetable
> >> > > > somewhere stating when the feature freeze for 4.4 will be?
> >> > > > >
> >> > > > > I would like to submit a feature and want to ensure that It's
> >> > > > > prepared in
> >> > > > time.
> >> > > > >
> >> > > > > Many thanks,
> >> > > > >
> >> > > > > Alex
> >> > > > >
> >> > > > >
> >> > > > > Regards,
> >> > > > >
> >> > > > > Alex Hitchins
> >> > > > > VP Software Engineering
> >> > > > > D: +44 1892 523 587 | S: +44 20 3603 0540 |
> >>M:
> >> > > > +44 7788 423 969
> >> > > > >
> >> > > > > ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
> >> > > > >
> >> > > > > Need Enterprise Grade Support for Apache CloudStack?
> >> > > > > Our CloudStack Infrastructure
> >> > > > > Support >> > > > infrastructure-support/> offers the best 24/7 SLA for CloudStack
> >> > > > Environments.
> >> > > > >
> >> > > > > Apache CloudStack Bootcamp training courses
> >> > > > >
> >> > > > > **NEW!** CloudStack 4.2.1
> >> > > > > training >> > > > training/>
> >> > > > > 18th-19th February 2014, Brazil.
> >> > > > Classroo

Re: [DISCUSS][PROPOSAL] (CLOUDSTACK-3272)

[Sonal Ojha]

Hello Murali,

I have started working on the changes required to control publishing of
events on the event bus based on the event category config parameter. While
working on the changes I could come across the following approach

a.) Changed the routing key and binding key format to the following adding
the boolean eventCategoryConfig. The changes to the routing key are meant
for the re-connection logic to the AMQP server in case of loss of
connection, file RabbitMQEventBus.java function ReconnectionTask s

eventSource.eventCategory.eventType.resourceType.resourceUuid.
*eventCategoryConfig*

I am attaching the patch with the email kindly let me know your comments.
For now, the evtn category configuration parameter is hard coded (default
to True) when the EventCategory object is instantiated, I am working to
move it out to a configuration file. Any suggestions?


>
> -- Forwarded message --
> From: Murali Reddy 
> Date: Tue, Dec 17, 2013 at 12:20 PM
> Subject: Re: [DISCUSS][PROPOSAL] (CLOUDSTACK-3272)
> To: "dev@cloudstack.apache.org" , Chiradeep
> Vittal 
>
>
>
> Sonal,
>
> There may be mix up on the problem statement of the bug 3272. Sorry I did
> not elaborate enough in the bug.
>
> So there are multiple event types that are generated by CS, action events,
> usage events, resource state change events and alerts. Current problem is
> all the events gets published on the event bus when event bus is enabled.
> Intent of the bug is to introduce global setting config parameters to
> specify which category of events to be published or not be published on
> the event bus. For e.g if global config param says to publish only usage
> events, then only usage events should be published on the event bus.
>
> If your intent is to create generic mechanism to add meta-data to events
> that event bus can interpret and do specific action/configuration then it
> might make sense to open a different bug and elaborate what you want to
> address.
>
> Thanks,
> Murali
>
>
> On 16/12/13 1:11 PM, "Sonal Ojha"  wrote:
>
> >As per the problem statement the config parameters would be the deciding
> >factor for the behavior of the events on the event bus. A subscriber would
> >never decide the behavior , instead the publisher of the event would add
> >config parameters to the events. On basis of these parameters the wrapper
> >over the queue broker could decide the actions to be performed on the
> >events. For example, the publisher of vm start event added a configuration
> >parameter "expiry" to the event. On basis of this parameter the wrapper
> >over the message queue broker would decide when should the vm start event
> >be expired / deleted from the queue. The subscriber of the event will be
> >able to read / fetch the event until its expired.
> >
> >There could be more than one config parameters attached to an event and so
> >the proposal is to add all these config parameters into a Map instead of
> >having only one config parameter added as a variable to the EventCategory
> >class.
> >
> >
> >On Fri, Dec 13, 2013 at 11:26 PM, Chiradeep Vittal <
> >chiradeep.vit...@citrix.com> wrote:
> >
> >>  Forgive me for my ignorance , why can't this be done by the client that
> >> is receiving the events? Note that multiple clients can subscribe to the
> >> event bus: this requirement is specific to one client?
> >>
> >>   From: Sonal Ojha 
> >> Date: Wednesday, December 11, 2013 11:36 PM
> >> To: Chiradeep Vittal 
> >> Cc: "dev@cloudstack.apache.org" 
> >> Subject: Re: [DISCUSS][PROPOSAL] (CLOUDSTACK-3272)
> >>
> >>   One of the use case be to delete only vm power on/off events from the
> >> event queue, other be to persist all the update events on virtual
> >>machines
> >> on the queue. The map of configuration parameters would be helpful to
> >> decide such behaviors.
> >>
> >>
> >> On Thu, Dec 12, 2013 at 3:26 AM, Chiradeep Vittal <
> >> chiradeep.vit...@citrix.com> wrote:
> >>
> >>> Some more description of the use cases would be helpful. What is the
> >>>pain
> >>> point it is addressing?
> >>>
> >>> On 12/11/13 3:26 AM, "Sonal Ojha"  wrote:
> >>>
> >>> >Hello,
> >>> >
> >>> >As per the description in the bug I would like to propose to
> >>>introduce a
> >>> >new instance variable configParameters of type HashMap to the
> >>> >EventCategory
> >>> >class.Currently, it could store one config parameter
> >>> >"publish.action.events"(key as String) and True (value as Boolean) but
> >>> >later it could add more config parameters to change the behavior of
> >>> >events.
> >>> >
> >>> >Thoughts / suggestions ?
> >>> >
> >>> >
> >>> >--
> >>> >
> >>> >Thanks and Regards,
> >>> >
> >>>  >*Sonal Ojha* EURO Senior Engineer Product Development EURO  SunGard IT
> >>>  >Availability
> >>> >
> >>> >Mobile +91-9922412645 EURO E-Mail: sonal.o...@sungard.com
> >>>
> >>>
> >>>
> >>
> >>
> >>  --
> >>
> >> Thanks and Regards,
> >>
> >> *Sonal Ojha* * Senior Engineer Product Development *  SunGard IT
> >> Availability
> >>
> >> Mobile +91

Re: 4.4 Feature Freeze

[Daan Hoogland]

-1 for postponing the feature freeze. It will amount to more features
in the release. I'd rather shorten the cycle and do more releases then
to pack more bugs in a single go.

On Wed, Feb 26, 2014 at 1:13 PM, Guo Star  wrote:
> +1
>
>
> 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek >:
>
>> +1 for 4.4 feature freeze on 3/28.
>>
>> On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
>>  wrote:
>>
>> >> -Original Message-
>> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> >> Sent: 26 February 2014 04:46
>> >> To: dev@cloudstack.apache.org
>> >> Subject: Re: 4.4 Feature Freeze
>> >>
>> >> I think this is a good idea, Animesh (to push out feature freeze to
>> >>3/28).
>> >
>> >+1 to move 4.4 feature freeze date to 3/28.
>> >
>> >Regards,
>> >Sateesh
>> >
>> >> I also agree we should discuss 4+ month development cycles again.
>> >>
>> >>
>> >> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
>> >>animesh.chaturv...@citrix.com> wrote:
>> >>
>> >> > I will start a separate discussion on 4 month cycle or longer, but
>> >> > wanted to call out one more important date.
>> >> >
>> >> > We have a last day for feature proposal date which is typically a
>> >> > month before feature freeze date. If following 4.3 schedule + 4 month
>> >> > it would have been 2/14 and we are already past that. Since it was not
>> >> > announced for
>> >> > 4.4 release yet my suggestion would be to keep feature proposal open
>> >> > for another week and push all  the dates out by 2 weeks to give folks
>> >> > opportunity to finish up their features for new proposals that are yet
>> >> > to come out.
>> >> >
>> >> > To be clear that would mean pushing out feature freeze to 3/28 from
>> >> > 3/14 and all the other dates likewise.
>> >> >
>> >> >
>> >> > Thanks
>> >> > Animesh
>> >> >
>> >> > > -Original Message-
>> >> > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> >> > > Sent: Tuesday, February 25, 2014 1:05 PM
>> >> > > To: dev@cloudstack.apache.org
>> >> > > Subject: RE: 4.4 Feature Freeze
>> >> > >
>> >> > > With the experience of 4.2 and 4.3 I think we should discuss if we
>> >> > > can realistically achieve 4 month cycle our RCs take 2 months. I was
>> >> > > going to open up the discussion after 4.3 is shipped though.
>> >> > >
>> >> > > > -Original Message-
>> >> > > > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
>> >> > > > Trippaers
>> >> > > > Sent: Tuesday, February 25, 2014 8:50 AM
>> >> > > > To: 
>> >> > > > Subject: Re: 4.4 Feature Freeze
>> >> > > >
>> >> > > > Hey,
>> >> > > >
>> >> > > > If we stick to our 4 month release schedule the feature freeze is
>> >> > > > four months after the feature freeze of 4.3. The feature freeze of
>> >> > > > 4.3 was
>> >> > 8 Nov
>> >> > > 2013.
>> >> > > >
>> >> > > > So the proposed release schedule for 4.4 would look like this
>> >> > > > (dates slightly modified to take efficiency and RM's personal life
>> >> > > > into
>> >> > account ;-) ):
>> >> > > >
>> >> > > > Feature Freeze: March 14, 2014
>> >> > > > Testing/Bug Fixes:  March 15, 2014 till April 18,
>> >>2014
>> >> > > > (direct access for committers)
>> >> > > > Stability Fixes only:   April 19, 2014 till
>> >> > release (cherry picks
>> >> > > > by RM only)
>> >> > > > First RC:   May 9, 2014
>> >> > > > Optimistic Release Date:May 19, 2014
>> >> > > >
>> >> > > > Cheers,
>> >> > > >
>> >> > > > Hugo
>> >> > > >
>> >> > > >
>> >> > > > On 25 feb. 2014, at 16:35, Sudha Ponnaganti
>> >> > > > 
>> >> > > > wrote:
>> >> > > >
>> >> > > > > Hi,
>> >> > > > >
>> >> > > > > I am also looking for feature freeze dates for 4.4. Can RM post
>> >> > those?
>> >> > > > >
>> >> > > > > Thanks
>> >> > > > > /Sudha
>> >> > > > >
>> >> > > > > -Original Message-
>> >> > > > > From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
>> >> > > > > Sent: Tuesday, February 25, 2014 7:00 AM
>> >> > > > > To: dev@cloudstack.apache.org
>> >> > > > > Subject: 4.4 Feature Freeze
>> >> > > > >
>> >> > > > > All,
>> >> > > > >
>> >> > > > > I know the 4.3 isn't quite out the door yet, but is there a
>> >> > > > > timetable
>> >> > > > somewhere stating when the feature freeze for 4.4 will be?
>> >> > > > >
>> >> > > > > I would like to submit a feature and want to ensure that It's
>> >> > > > > prepared in
>> >> > > > time.
>> >> > > > >
>> >> > > > > Many thanks,
>> >> > > > >
>> >> > > > > Alex
>> >> > > > >
>> >> > > > >
>> >> > > > > Regards,
>> >> > > > >
>> >> > > > > Alex Hitchins
>> >> > > > > VP Software Engineering
>> >> > > > > D: +44 1892 523 587 | S: +44 20 3603 0540 |
>> >>M:
>> >> > > > +44 7788 423 969
>> >> > > > >
>> >> > > > > ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>> >> > > > >
>> >> > > > > Need Enterprise Grade Support for Apache CloudStack?
>> >> > > > > Our CloudStack Infrastructure
>> >> > > > > Support

Jenkins build is back to normal : build-master-slowbuild #304

[jenkins]

See 

Submitting a Feature Proposal

[Alex Hitchins]

Firstly, thanks to all those who took part in the discussion on the 4.4 FF 
date. I think we should have a discussion on altering the release/development 
schedule.

That said, what is the process to submit a feature proposal?


Regards,

Alex Hitchins
VP Software Engineering


D: +44 1892 523 587 | S: +44 20 3603 0540 | M: 
+44 7788 423 969

ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line
24th-28th March 2014, Region B. Instructor led, 
On-line
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: 4.4 Feature Freeze

[Tracy Phillips]

+1 to Daan.

Tracy Phillips
Weberize, Inc.


On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland wrote:

> -1 for postponing the feature freeze. It will amount to more features
> in the release. I'd rather shorten the cycle and do more releases then
> to pack more bugs in a single go.
>
> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star  wrote:
> > +1
> >
> >
> > 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
> abhinandan.prat...@citrix.com
> >>:
> >
> >> +1 for 4.4 feature freeze on 3/28.
> >>
> >> On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
> >>  wrote:
> >>
> >> >> -Original Message-
> >> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> >> Sent: 26 February 2014 04:46
> >> >> To: dev@cloudstack.apache.org
> >> >> Subject: Re: 4.4 Feature Freeze
> >> >>
> >> >> I think this is a good idea, Animesh (to push out feature freeze to
> >> >>3/28).
> >> >
> >> >+1 to move 4.4 feature freeze date to 3/28.
> >> >
> >> >Regards,
> >> >Sateesh
> >> >
> >> >> I also agree we should discuss 4+ month development cycles again.
> >> >>
> >> >>
> >> >> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
> >> >>animesh.chaturv...@citrix.com> wrote:
> >> >>
> >> >> > I will start a separate discussion on 4 month cycle or longer, but
> >> >> > wanted to call out one more important date.
> >> >> >
> >> >> > We have a last day for feature proposal date which is typically a
> >> >> > month before feature freeze date. If following 4.3 schedule + 4
> month
> >> >> > it would have been 2/14 and we are already past that. Since it was
> not
> >> >> > announced for
> >> >> > 4.4 release yet my suggestion would be to keep feature proposal
> open
> >> >> > for another week and push all  the dates out by 2 weeks to give
> folks
> >> >> > opportunity to finish up their features for new proposals that are
> yet
> >> >> > to come out.
> >> >> >
> >> >> > To be clear that would mean pushing out feature freeze to 3/28 from
> >> >> > 3/14 and all the other dates likewise.
> >> >> >
> >> >> >
> >> >> > Thanks
> >> >> > Animesh
> >> >> >
> >> >> > > -Original Message-
> >> >> > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> >> >> > > Sent: Tuesday, February 25, 2014 1:05 PM
> >> >> > > To: dev@cloudstack.apache.org
> >> >> > > Subject: RE: 4.4 Feature Freeze
> >> >> > >
> >> >> > > With the experience of 4.2 and 4.3 I think we should discuss if
> we
> >> >> > > can realistically achieve 4 month cycle our RCs take 2 months. I
> was
> >> >> > > going to open up the discussion after 4.3 is shipped though.
> >> >> > >
> >> >> > > > -Original Message-
> >> >> > > > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> >> >> > > > Trippaers
> >> >> > > > Sent: Tuesday, February 25, 2014 8:50 AM
> >> >> > > > To: 
> >> >> > > > Subject: Re: 4.4 Feature Freeze
> >> >> > > >
> >> >> > > > Hey,
> >> >> > > >
> >> >> > > > If we stick to our 4 month release schedule the feature freeze
> is
> >> >> > > > four months after the feature freeze of 4.3. The feature
> freeze of
> >> >> > > > 4.3 was
> >> >> > 8 Nov
> >> >> > > 2013.
> >> >> > > >
> >> >> > > > So the proposed release schedule for 4.4 would look like this
> >> >> > > > (dates slightly modified to take efficiency and RM's personal
> life
> >> >> > > > into
> >> >> > account ;-) ):
> >> >> > > >
> >> >> > > > Feature Freeze: March 14, 2014
> >> >> > > > Testing/Bug Fixes:  March 15, 2014 till April
> 18,
> >> >>2014
> >> >> > > > (direct access for committers)
> >> >> > > > Stability Fixes only:   April 19, 2014 till
> >> >> > release (cherry picks
> >> >> > > > by RM only)
> >> >> > > > First RC:   May 9, 2014
> >> >> > > > Optimistic Release Date:May 19, 2014
> >> >> > > >
> >> >> > > > Cheers,
> >> >> > > >
> >> >> > > > Hugo
> >> >> > > >
> >> >> > > >
> >> >> > > > On 25 feb. 2014, at 16:35, Sudha Ponnaganti
> >> >> > > > 
> >> >> > > > wrote:
> >> >> > > >
> >> >> > > > > Hi,
> >> >> > > > >
> >> >> > > > > I am also looking for feature freeze dates for 4.4. Can RM
> post
> >> >> > those?
> >> >> > > > >
> >> >> > > > > Thanks
> >> >> > > > > /Sudha
> >> >> > > > >
> >> >> > > > > -Original Message-
> >> >> > > > > From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
> >> >> > > > > Sent: Tuesday, February 25, 2014 7:00 AM
> >> >> > > > > To: dev@cloudstack.apache.org
> >> >> > > > > Subject: 4.4 Feature Freeze
> >> >> > > > >
> >> >> > > > > All,
> >> >> > > > >
> >> >> > > > > I know the 4.3 isn't quite out the door yet, but is there a
> >> >> > > > > timetable
> >> >> > > > somewhere stating when the feature freeze for 4.4 will be?
> >> >> > > > >
> >> >> > > > > I would like to submit a feature and want to ensure that It's
> >> >> > > > > prepared in
> >> >> > > > time.
> >> >> > > > >
> >> >> > > > > Many thanks,
> >> >> > > > >
> >> >> > > > > Alex
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > Regards,
> >> >> > > > >
> 

Re: [DISCUSS] Policy blocker?

[Chip Childers]

On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi
 wrote:
>
> Folks since the liability of Release manager has been called out explicitly 
> for the release I want to call out that I cannot take personal liability for 
> a release and I am not sure why would anyone else in Release Manager role 
> will take up personal liability. I don't see anything called out in our 
> bylaws that states Release Manager being liable.
>
> That being said I am seeking advice from ASF mentors and will discuss it in  
> PMC. I  will proceed and build an RC after this issue is resolved.
>
> Thanks
> Animesh

A couple of things:

First, we don't have any "mentors" anymore...  we're a TLP.

Second, although the question of "liability" has been clarified in the
private@ thread, I'll summarize briefly here:

The reason that we follow the voting process (where the PMC votes are
binding) and other ASF-wide policies, is so that any release is an
"act of the foundation" and not an act of an individual.  The point is
that if someone were to purposefully ignore policy, then they put
themselves at risk.  The whole reason for the foundation to have it's
policies is to protect all of the committers and contributors from
personal liability!  So the only thing that really matters is that if
we follow the policies of the foundation, there's nothing to worry
about.

Being a release manager is nothing to worry about...  the whole PMC is
helping to ensure that we follow policies.  As our current 4.3 issue
has pointed out, sometimes this means we have to slow down to fix
something.  If something slipped through, it's still not a "liability"
issue in practical terms.  It's just a mistake that we would then work
to correct.

Make sense?

-chip

Fwd: ASF Board Report - Initial Reminder for Mar 2014

[Chip Childers]

Any volunteers to pull together a first draft of the report?


-- Forwarded message --
From: ASF Board 
Date: Wed, Feb 26, 2014 at 9:15 AM
Subject: ASF Board Report - Initial Reminder for Mar 2014
To: Chip Childers 




This email was sent by an automated system on behalf of the ASF Board.
It is an initial reminder to give you plenty of time to prepare the report.

The meeting is scheduled for Wed, 19 March 2014, 10:30:30:00 PST and
the deadline for
submitting your report is 1 full week prior to that (Wed, Mar 12th)!

According to board records, you are listed as the chair of at least one
committee that is due to submit a report this month. [1] [2]

Details on which project reports are due and how to submit a report
are enclosed below.

Please submit your report with sufficient time to allow the board members
to review and digest. Again, the very latest you should submit your report
is 1 full week (7days) prior to the board meeting (Wed, Mar 12th).

If you feel that an error has been made, please consult [1] and if there
is still an issue then contact the board directly.

As always, PMC chairs are welcome to attend the board meeting.

Thanks,
The ASF Board

[1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt
[2] - https://svn.apache.org/repos/private/committers/board/calendar.txt
[3] - https://svn.apache.org/repos/private/committers/board/templates


Submitting your Report
--

Full details about the process and schedule are in [1].

The report should be committed to the meeting agenda in the board directory
in the foundation repository, trying to keep a similar format to the others.
This can be found at:

  https://svn.apache.org/repos/private/foundation/board

Your report should also be sent in plain-text format to bo...@apache.org
with a Subject line that follows the below format:

Subject: [REPORT] Project Name

Cutting and pasting directly from a Wiki is not acceptable due to formatting
issues. Line lengths should be limited to 77 characters.


Resolutions
---

There are several templates for use for various Board resolutions.
They can be found in [3] and you are encouraged to use them. It is
strongly recommended that if you have a resolution before the board,
you are encouraged to attend that board meeting.


ASF Board Reports
-

Reports are due from you for the following committees:

 - CloudStack

Re: 4.4 Feature Freeze

[Hugo Trippaers]

-1 on postponing the feature freeze. We are having this discussion after every 
release, however we agreed to do a 4 month cycle so let's stick to it.

If there are important features that are currently being developed but might 
not make this cut-off date we should discuss that separately, but as a point of 
principle lets stick to the release schedule as proposed.


Cheers,

Hugo


On 26 feb. 2014, at 15:23, Tracy Phillips  wrote:

> +1 to Daan.
> 
> Tracy Phillips
> Weberize, Inc.
> 
> 
> On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland wrote:
> 
>> -1 for postponing the feature freeze. It will amount to more features
>> in the release. I'd rather shorten the cycle and do more releases then
>> to pack more bugs in a single go.
>> 
>> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star  wrote:
>>> +1
>>> 
>>> 
>>> 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
>> abhinandan.prat...@citrix.com
 :
>>> 
 +1 for 4.4 feature freeze on 3/28.
 
 On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
  wrote:
 
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: 26 February 2014 04:46
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>> 
>> I think this is a good idea, Animesh (to push out feature freeze to
>> 3/28).
> 
> +1 to move 4.4 feature freeze date to 3/28.
> 
> Regards,
> Sateesh
> 
>> I also agree we should discuss 4+ month development cycles again.
>> 
>> 
>> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
>> animesh.chaturv...@citrix.com> wrote:
>> 
>>> I will start a separate discussion on 4 month cycle or longer, but
>>> wanted to call out one more important date.
>>> 
>>> We have a last day for feature proposal date which is typically a
>>> month before feature freeze date. If following 4.3 schedule + 4
>> month
>>> it would have been 2/14 and we are already past that. Since it was
>> not
>>> announced for
>>> 4.4 release yet my suggestion would be to keep feature proposal
>> open
>>> for another week and push all  the dates out by 2 weeks to give
>> folks
>>> opportunity to finish up their features for new proposals that are
>> yet
>>> to come out.
>>> 
>>> To be clear that would mean pushing out feature freeze to 3/28 from
>>> 3/14 and all the other dates likewise.
>>> 
>>> 
>>> Thanks
>>> Animesh
>>> 
 -Original Message-
 From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
 Sent: Tuesday, February 25, 2014 1:05 PM
 To: dev@cloudstack.apache.org
 Subject: RE: 4.4 Feature Freeze
 
 With the experience of 4.2 and 4.3 I think we should discuss if
>> we
 can realistically achieve 4 month cycle our RCs take 2 months. I
>> was
 going to open up the discussion after 4.3 is shipped though.
 
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> Trippaers
> Sent: Tuesday, February 25, 2014 8:50 AM
> To: 
> Subject: Re: 4.4 Feature Freeze
> 
> Hey,
> 
> If we stick to our 4 month release schedule the feature freeze
>> is
> four months after the feature freeze of 4.3. The feature
>> freeze of
> 4.3 was
>>> 8 Nov
 2013.
> 
> So the proposed release schedule for 4.4 would look like this
> (dates slightly modified to take efficiency and RM's personal
>> life
> into
>>> account ;-) ):
> 
> Feature Freeze: March 14, 2014
> Testing/Bug Fixes:  March 15, 2014 till April
>> 18,
>> 2014
> (direct access for committers)
> Stability Fixes only:   April 19, 2014 till
>>> release (cherry picks
> by RM only)
> First RC:   May 9, 2014
> Optimistic Release Date:May 19, 2014
> 
> Cheers,
> 
> Hugo
> 
> 
> On 25 feb. 2014, at 16:35, Sudha Ponnaganti
> 
> wrote:
> 
>> Hi,
>> 
>> I am also looking for feature freeze dates for 4.4. Can RM
>> post
>>> those?
>> 
>> Thanks
>> /Sudha
>> 
>> -Original Message-
>> From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
>> Sent: Tuesday, February 25, 2014 7:00 AM
>> To: dev@cloudstack.apache.org
>> Subject: 4.4 Feature Freeze
>> 
>> All,
>> 
>> I know the 4.3 isn't quite out the door yet, but is there a
>> timetable
> somewhere stating when the feature freeze for 4.4 will be?
>> 
>> I would like to submit a feature and want to ensure that It's
>> prepared in
>>>

Review Request 18516: CLOUDSTACK-6015: add apache license headers, add a new test: navigation test and related code.

[Yichi Lu]

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

Review request for cloudstack, Nitin Mehta, Parth Jagirdar, and Sebastien 
Goasguen.


Repository: cloudstack-git


Description
---

add apache license headers to all files. add a new test: navigation_test.py.

The tests were done against the 4.4.0 commit: 
5c8bd6657323c7ea27b06777fb9e1b87a0af5680


Diffs
-

  test/selenium/browser/__init__.py e69de29 
  test/selenium/browser/firefox.py PRE-CREATION 
  test/selenium/browser/firefox.py PRE-CREATION 
  test/selenium/common/Global_Locators.py PRE-CREATION 
  test/selenium/common/Global_Locators.py PRE-CREATION 
  test/selenium/common/__init__.py e69de29 
  test/selenium/common/shared.py PRE-CREATION 
  test/selenium/common/shared.py PRE-CREATION 
  test/selenium/cspages/__init__.py e69de29 
  test/selenium/cspages/dashboard/__init__.py PRE-CREATION 
  test/selenium/cspages/dashboard/dashboardpage.py PRE-CREATION 
  test/selenium/cspages/login/__init__.py PRE-CREATION 
  test/selenium/cspages/login/loginpage.py PRE-CREATION 
  test/selenium/cspages/login/loginpage.py 39e4295 
  test/selenium/cspages/loginpage.py PRE-CREATION 
  test/selenium/cspages/loginpage.py PRE-CREATION 
  test/selenium/cstests/__init__.py e69de29 
  test/selenium/cstests/regressiontests/__init__.py PRE-CREATION 
  test/selenium/cstests/smoketests/__init__.py e69de29 
  test/selenium/cstests/smoketests/global_settings_test.py PRE-CREATION 
  test/selenium/cstests/smoketests/login_logout_test.py PRE-CREATION 
  test/selenium/cstests/smoketests/login_logout_test.py PRE-CREATION 
  test/selenium/cstests/smoketests/login_logout_test.py PRE-CREATION 
  test/selenium/cstests/smoketests/navigation_test.py PRE-CREATION 
  test/selenium/cstests/smoketests/smokecfg.py PRE-CREATION 
  test/selenium/cstests/smoketests/smokecfg.py PRE-CREATION 

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


Testing
---

USLT-205731:selenium yichi.lu$ python cstests/smoketests/login_logout_test.py 
.
--
Ran 9 tests in 219.643s

OK
USLT-205731:selenium yichi.lu$ python cstests/smoketests/navigation_test.py 
.
--
Ran 1 test in 69.194s

OK


Thanks,

Yichi Lu

Re: 4.4 Feature Freeze

[Mike Tutkowski]

I think we're having this discussion after every release because we're
beginning to realize that a four-month release cycle has not been very
realistic for us yet.

The main issue I encounter is our month-long RC cycle where I spend a bunch
of time validating the RC and (during that timeframe) less time developing
for the next release as I had initially planned.

Perhaps instead of extending the cycle we could consider ways to actually
meet the schedule on a consistent basis. That would be fine, as well.


On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers  wrote:

> -1 on postponing the feature freeze. We are having this discussion after
> every release, however we agreed to do a 4 month cycle so let's stick to it.
>
> If there are important features that are currently being developed but
> might not make this cut-off date we should discuss that separately, but as
> a point of principle lets stick to the release schedule as proposed.
>
>
> Cheers,
>
> Hugo
>
>
> On 26 feb. 2014, at 15:23, Tracy Phillips 
> wrote:
>
> > +1 to Daan.
> >
> > Tracy Phillips
> > Weberize, Inc.
> >
> >
> > On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland  >wrote:
> >
> >> -1 for postponing the feature freeze. It will amount to more features
> >> in the release. I'd rather shorten the cycle and do more releases then
> >> to pack more bugs in a single go.
> >>
> >> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star  wrote:
> >>> +1
> >>>
> >>>
> >>> 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
> >> abhinandan.prat...@citrix.com
>  :
> >>>
>  +1 for 4.4 feature freeze on 3/28.
> 
>  On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
>   wrote:
> 
> >> -Original Message-
> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> Sent: 26 February 2014 04:46
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: 4.4 Feature Freeze
> >>
> >> I think this is a good idea, Animesh (to push out feature freeze to
> >> 3/28).
> >
> > +1 to move 4.4 feature freeze date to 3/28.
> >
> > Regards,
> > Sateesh
> >
> >> I also agree we should discuss 4+ month development cycles again.
> >>
> >>
> >> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
> >> animesh.chaturv...@citrix.com> wrote:
> >>
> >>> I will start a separate discussion on 4 month cycle or longer, but
> >>> wanted to call out one more important date.
> >>>
> >>> We have a last day for feature proposal date which is typically a
> >>> month before feature freeze date. If following 4.3 schedule + 4
> >> month
> >>> it would have been 2/14 and we are already past that. Since it was
> >> not
> >>> announced for
> >>> 4.4 release yet my suggestion would be to keep feature proposal
> >> open
> >>> for another week and push all  the dates out by 2 weeks to give
> >> folks
> >>> opportunity to finish up their features for new proposals that are
> >> yet
> >>> to come out.
> >>>
> >>> To be clear that would mean pushing out feature freeze to 3/28 from
> >>> 3/14 and all the other dates likewise.
> >>>
> >>>
> >>> Thanks
> >>> Animesh
> >>>
>  -Original Message-
>  From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>  Sent: Tuesday, February 25, 2014 1:05 PM
>  To: dev@cloudstack.apache.org
>  Subject: RE: 4.4 Feature Freeze
> 
>  With the experience of 4.2 and 4.3 I think we should discuss if
> >> we
>  can realistically achieve 4 month cycle our RCs take 2 months. I
> >> was
>  going to open up the discussion after 4.3 is shipped though.
> 
> > -Original Message-
> > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> > Trippaers
> > Sent: Tuesday, February 25, 2014 8:50 AM
> > To: 
> > Subject: Re: 4.4 Feature Freeze
> >
> > Hey,
> >
> > If we stick to our 4 month release schedule the feature freeze
> >> is
> > four months after the feature freeze of 4.3. The feature
> >> freeze of
> > 4.3 was
> >>> 8 Nov
>  2013.
> >
> > So the proposed release schedule for 4.4 would look like this
> > (dates slightly modified to take efficiency and RM's personal
> >> life
> > into
> >>> account ;-) ):
> >
> > Feature Freeze: March 14, 2014
> > Testing/Bug Fixes:  March 15, 2014 till April
> >> 18,
> >> 2014
> > (direct access for committers)
> > Stability Fixes only:   April 19, 2014 till
> >>> release (cherry picks
> > by RM only)
> > First RC:   May 9, 2014
> > Optimistic Release Date:May 19, 2014
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 25 feb.

Re: Submitting a Feature Proposal

[Mike Tutkowski]

Anyone feel free to correct me if I'm wrong, but I typically open up a JIRA
ticket and a corresponding Review Board Request (
https://reviews.apache.org/dashboard/).

If it's a brand-new feature, I would suggest sending a message to dev@ with
the [PROPOSAL] tag in the subject line and filling people in on what you'd
like to do. This is a good way of collecting input from the group.


On Wed, Feb 26, 2014 at 6:35 AM, Alex Hitchins
wrote:

> Firstly, thanks to all those who took part in the discussion on the 4.4 FF
> date. I think we should have a discussion on altering the
> release/development schedule.
>
> That said, what is the process to submit a feature proposal?
>
>
> Regards,
>
> Alex Hitchins
> VP Software Engineering
>
>
> D: +44 1892 523 587 | S: +44 20 3603 0540 | M: +44 +447968161581> 7788 423 969
>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/> offers the best
> 24/7 SLA for CloudStack Environments.
>
> Apache CloudStack Bootcamp training courses
>
> **NEW!** CloudStack 4.2.1 training<
> http://shapeblue.com/cloudstack-training/>
> 18th-19th February 2014, Brazil. Classroom<
> http://shapeblue.com/cloudstack-training/>
> 17th-23rd March 2014, Region A. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 24th-28th March 2014, Region B. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 16th-20th June 2014, Region A. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 23rd-27th June 2014, Region B. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue is a
> registered trademark.
>



-- 
*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: license analysis

[Mike Tutkowski]

Thanks, Daan!

By the way, are you having him perform this in-depth analysis on 4.3 or is
this going to be done first on master?


On Wed, Feb 26, 2014 at 3:55 AM, Daan Hoogland  wrote:

> H,
>
> I made contact with Armijn Hemel (Tjaldur Software Governance Solutions)
> who scans software for the purpose of making sure no unwanted licenses are
> in products. I am going to ask him to look at a Jenkins 4.3 build and talk
> about the results. He does this for a living so money may be involved but
> he is also a oss enthusiast so maybe not so much.
>
> Will let you know,
> Daan
>



-- 
*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: [DISCUSS] Policy blocker?

[John Kinsella]

+1 well put.

On Feb 26, 2014, at 6:44 AM, Chip Childers  wrote:

> On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi
>  wrote:
>> 
>> Folks since the liability of Release manager has been called out explicitly 
>> for the release I want to call out that I cannot take personal liability for 
>> a release and I am not sure why would anyone else in Release Manager role 
>> will take up personal liability. I don't see anything called out in our 
>> bylaws that states Release Manager being liable.
>> 
>> That being said I am seeking advice from ASF mentors and will discuss it in  
>> PMC. I  will proceed and build an RC after this issue is resolved.
>> 
>> Thanks
>> Animesh
> 
> A couple of things:
> 
> First, we don't have any "mentors" anymore...  we're a TLP.
> 
> Second, although the question of "liability" has been clarified in the
> private@ thread, I'll summarize briefly here:
> 
> The reason that we follow the voting process (where the PMC votes are
> binding) and other ASF-wide policies, is so that any release is an
> "act of the foundation" and not an act of an individual.  The point is
> that if someone were to purposefully ignore policy, then they put
> themselves at risk.  The whole reason for the foundation to have it's
> policies is to protect all of the committers and contributors from
> personal liability!  So the only thing that really matters is that if
> we follow the policies of the foundation, there's nothing to worry
> about.
> 
> Being a release manager is nothing to worry about...  the whole PMC is
> helping to ensure that we follow policies.  As our current 4.3 issue
> has pointed out, sometimes this means we have to slow down to fix
> something.  If something slipped through, it's still not a "liability"
> issue in practical terms.  It's just a mistake that we would then work
> to correct.
> 
> Make sense?
> 
> -chip

Re: Submitting a Feature Proposal

[John Kinsella]

Actually, if it’s a Significant Feature, I like seeing a spec put together to 
be referenced by the [PROPOSAL] thread. Take a look at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design and in particular 
the Design Document Template.

John

On Feb 26, 2014, at 7:34 AM, Mike Tutkowski 
mailto:mike.tutkow...@solidfire.com>> wrote:

Anyone feel free to correct me if I'm wrong, but I typically open up a JIRA
ticket and a corresponding Review Board Request (
https://reviews.apache.org/dashboard/).

If it's a brand-new feature, I would suggest sending a message to dev@ with
the [PROPOSAL] tag in the subject line and filling people in on what you'd
like to do. This is a good way of collecting input from the group.


On Wed, Feb 26, 2014 at 6:35 AM, Alex Hitchins
mailto:alex.hitch...@shapeblue.com>>wrote:

Firstly, thanks to all those who took part in the discussion on the 4.4 FF
date. I think we should have a discussion on altering the
release/development schedule.

That said, what is the process to submit a feature proposal?


Regards,

Alex Hitchins
VP Software Engineering


D: +44 1892 523 587 | S: +44 20 3603 0540 | M: +44 7788 423 969

ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure Support<
http://shapeblue.com/cloudstack-infrastructure-support/> offers the best
24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training<
http://shapeblue.com/cloudstack-training/>
18th-19th February 2014, Brazil. Classroom<
http://shapeblue.com/cloudstack-training/>
17th-23rd March 2014, Region A. Instructor led, On-line<
http://shapeblue.com/cloudstack-training/>
24th-28th March 2014, Region B. Instructor led, On-line<
http://shapeblue.com/cloudstack-training/>
16th-20th June 2014, Region A. Instructor led, On-line<
http://shapeblue.com/cloudstack-training/>
23rd-27th June 2014, Region B. Instructor led, On-line<
http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Shape Blue Ltd or related companies. If you are not the
intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender
if you believe you have received this email in error. Shape Blue Ltd is a
company incorporated in England & Wales. ShapeBlue Services India LLP is a
company incorporated in India and is operated under license from Shape Blue
Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
and is operated under license from Shape Blue Ltd. ShapeBlue is a
registered trademark.




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

Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: Submitting a Feature Proposal

[Mike Tutkowski]

Good point, John.


On Wed, Feb 26, 2014 at 9:00 AM, John Kinsella  wrote:

> Actually, if it's a Significant Feature, I like seeing a spec put together
> to be referenced by the [PROPOSAL] thread. Take a look at
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design and in
> particular the Design Document Template.
>
> John
>
> On Feb 26, 2014, at 7:34 AM, Mike Tutkowski  > wrote:
>
> Anyone feel free to correct me if I'm wrong, but I typically open up a JIRA
> ticket and a corresponding Review Board Request (
> https://reviews.apache.org/dashboard/).
>
> If it's a brand-new feature, I would suggest sending a message to dev@with
> the [PROPOSAL] tag in the subject line and filling people in on what you'd
> like to do. This is a good way of collecting input from the group.
>
>
> On Wed, Feb 26, 2014 at 6:35 AM, Alex Hitchins
> mailto:alex.hitch...@shapeblue.com>>wrote:
>
> Firstly, thanks to all those who took part in the discussion on the 4.4 FF
> date. I think we should have a discussion on altering the
> release/development schedule.
>
> That said, what is the process to submit a feature proposal?
>
>
> Regards,
>
> Alex Hitchins
> VP Software Engineering
>
>
> D: +44 1892 523 587 | S: +44 20 3603 0540 | M: +44 +447968161581> 7788 423 969
>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/> offers the best
> 24/7 SLA for CloudStack Environments.
>
> Apache CloudStack Bootcamp training courses
>
> **NEW!** CloudStack 4.2.1 training<
> http://shapeblue.com/cloudstack-training/>
> 18th-19th February 2014, Brazil. Classroom<
> http://shapeblue.com/cloudstack-training/>
> 17th-23rd March 2014, Region A. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 24th-28th March 2014, Region B. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 16th-20th June 2014, Region A. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 23rd-27th June 2014, Region B. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue is a
> registered trademark.
>
>
>
>
> --
> *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)*
>
> Stratosec - Compliance as a Service
> o: 415.315.9385
> @johnlkinsella
>
>


-- 
*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: Submitting a Feature Proposal

[Alex Hitchins]

I will check out that link and put together any required documentation.

Thanks for the info and pointers.


> On 26 Feb 2014, at 16:03, "Mike Tutkowski"  
> wrote:
>
> Good point, John.
>
>
>> On Wed, Feb 26, 2014 at 9:00 AM, John Kinsella  wrote:
>>
>> Actually, if it's a Significant Feature, I like seeing a spec put together
>> to be referenced by the [PROPOSAL] thread. Take a look at
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design and in
>> particular the Design Document Template.
>>
>> John
>>
>> On Feb 26, 2014, at 7:34 AM, Mike Tutkowski > > wrote:
>>
>> Anyone feel free to correct me if I'm wrong, but I typically open up a JIRA
>> ticket and a corresponding Review Board Request (
>> https://reviews.apache.org/dashboard/).
>>
>> If it's a brand-new feature, I would suggest sending a message to dev@with
>> the [PROPOSAL] tag in the subject line and filling people in on what you'd
>> like to do. This is a good way of collecting input from the group.
>>
>>
>> On Wed, Feb 26, 2014 at 6:35 AM, Alex Hitchins
>> mailto:alex.hitch...@shapeblue.com>>wrote:
>>
>> Firstly, thanks to all those who took part in the discussion on the 4.4 FF
>> date. I think we should have a discussion on altering the
>> release/development schedule.
>>
>> That said, what is the process to submit a feature proposal?
>>
>>
>> Regards,
>>
>> Alex Hitchins
>> VP Software Engineering
>>
>>
>> D: +44 1892 523 587 | S: +44 20 3603 0540 | M: +44> +447968161581> 7788 423 969
>>
>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>
>> Need Enterprise Grade Support for Apache CloudStack?
>> Our CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/> offers the best
>> 24/7 SLA for CloudStack Environments.
>>
>> Apache CloudStack Bootcamp training courses
>>
>> **NEW!** CloudStack 4.2.1 training<
>> http://shapeblue.com/cloudstack-training/>
>> 18th-19th February 2014, Brazil. Classroom<
>> http://shapeblue.com/cloudstack-training/>
>> 17th-23rd March 2014, Region A. Instructor led, On-line<
>> http://shapeblue.com/cloudstack-training/>
>> 24th-28th March 2014, Region B. Instructor led, On-line<
>> http://shapeblue.com/cloudstack-training/>
>> 16th-20th June 2014, Region A. Instructor led, On-line<
>> http://shapeblue.com/cloudstack-training/>
>> 23rd-27th June 2014, Region B. Instructor led, On-line<
>> http://shapeblue.com/cloudstack-training/>
>>
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error. Shape Blue Ltd is a
>> company incorporated in England & Wales. ShapeBlue Services India LLP is a
>> company incorporated in India and is operated under license from Shape Blue
>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
>> and is operated under license from Shape Blue Ltd. ShapeBlue is a
>> registered trademark.
>>
>>
>>
>>
>> --
>> *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)*
>>
>> Stratosec - Compliance as a Service
>> o: 415.315.9385
>> @johnlkinsella
>
>
> --
> *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)*
This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: license analysis

[Mike Tutkowski]

Sounds good - I figured that's what you were going to say, but just wanted
to confirm. Thanks


On Wed, Feb 26, 2014 at 9:09 AM, Daan Hoogland wrote:

> We are still exploring but the initial goal is get 4.3 straight
>
> On Wed, Feb 26, 2014 at 4:36 PM, Mike Tutkowski
>  wrote:
> > Thanks, Daan!
> >
> > By the way, are you having him perform this in-depth analysis on 4.3 or
> is
> > this going to be done first on master?
> >
> >
> > On Wed, Feb 26, 2014 at 3:55 AM, Daan Hoogland <
> dhoogl...@schubergphilis.com
> >> wrote:
> >
> >> H,
> >>
> >> I made contact with Armijn Hemel (Tjaldur Software Governance Solutions)
> >> who scans software for the purpose of making sure no unwanted licenses
> are
> >> in products. I am going to ask him to look at a Jenkins 4.3 build and
> talk
> >> about the results. He does this for a living so money may be involved
> but
> >> he is also a oss enthusiast so maybe not so much.
> >>
> >> Will let you know,
> >> Daan
> >>
> >
> >
> >
> > --
> > *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)*
>
>
>
> --
> Daan
>



-- 
*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: license analysis

[Daan Hoogland]

We are still exploring but the initial goal is get 4.3 straight

On Wed, Feb 26, 2014 at 4:36 PM, Mike Tutkowski
 wrote:
> Thanks, Daan!
>
> By the way, are you having him perform this in-depth analysis on 4.3 or is
> this going to be done first on master?
>
>
> On Wed, Feb 26, 2014 at 3:55 AM, Daan Hoogland > wrote:
>
>> H,
>>
>> I made contact with Armijn Hemel (Tjaldur Software Governance Solutions)
>> who scans software for the purpose of making sure no unwanted licenses are
>> in products. I am going to ask him to look at a Jenkins 4.3 build and talk
>> about the results. He does this for a living so money may be involved but
>> he is also a oss enthusiast so maybe not so much.
>>
>> Will let you know,
>> Daan
>>
>
>
>
> --
> *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)*



-- 
Daan

Re: [DISCUSS] Policy blocker?

[Abhinandan Prateek]

+1 this is reasonable.

On 26/02/14 8:14 pm, "Chip Childers"  wrote:

>On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi
> wrote:
>>
>> Folks since the liability of Release manager has been called out
>>explicitly for the release I want to call out that I cannot take
>>personal liability for a release and I am not sure why would anyone else
>>in Release Manager role will take up personal liability. I don't see
>>anything called out in our bylaws that states Release Manager being
>>liable.
>>
>> That being said I am seeking advice from ASF mentors and will discuss
>>it in  PMC. I  will proceed and build an RC after this issue is resolved.
>>
>> Thanks
>> Animesh
>
>A couple of things:
>
>First, we don't have any "mentors" anymore...  we're a TLP.
>
>Second, although the question of "liability" has been clarified in the
>private@ thread, I'll summarize briefly here:
>
>The reason that we follow the voting process (where the PMC votes are
>binding) and other ASF-wide policies, is so that any release is an
>"act of the foundation" and not an act of an individual.  The point is
>that if someone were to purposefully ignore policy, then they put
>themselves at risk.  The whole reason for the foundation to have it's
>policies is to protect all of the committers and contributors from
>personal liability!  So the only thing that really matters is that if
>we follow the policies of the foundation, there's nothing to worry
>about.
>
>Being a release manager is nothing to worry about...  the whole PMC is
>helping to ensure that we follow policies.  As our current 4.3 issue
>has pointed out, sometimes this means we have to slow down to fix
>something.  If something slipped through, it's still not a "liability"
>issue in practical terms.  It's just a mistake that we would then work
>to correct.
>
>Make sense?
>
>-chip

Re: [VOTE] Apache CloudStack 4.3.0 (sixth round)

[John Kinsella]

Just pushed a fix for that to master.

On Feb 25, 2014, at 5:55 PM, Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>> wrote:

So how do you now Œprovide¹ the jdbc connector on a Mac?
mvn -Pdeveloper -pl developer -Ddeploydb-simulator
Š

SQL exception in trying initDB: java.sql.SQLException: No suitable driver
found for jdbc:mysql://localhost:3306/



On 2/21/14, 5:56 AM, "Hugo Trippaers" 
mailto:h...@trippaers.nl>> wrote:


Heya,

Just pushed commit ac00ab0087ca8f59184121697f7ac4343a694093
Author: Hugo Trippaers 
mailto:htrippa...@schubergphilis.com>>
Date:   Fri Feb 21 14:54:38 2014 +0100

  Cleanup all mysql dependencies and set all to provided.


This will set all mysql dependencies to provided and clean them up in the
process.

Tested:
Hugos-MacBook-Pro:cloudstack hugo (master)$ ls agent/target/dependencies/
| grep mysql
Hugos-MacBook-Pro:cloudstack hugo (master)$ jar -tf
awsapi/target/cloud-awsapi-4.4.0-SNAPSHOT.war | grep mysql
Hugos-MacBook-Pro:cloudstack hugo (master)$ jar -tf
client/target/cloud-client-ui-4.4.0-SNAPSHOT.war | grep mysql


Cheers,

Hugo


On 21 feb. 2014, at 13:48, Abhinandan Prateek
mailto:abhinandan.prat...@citrix.com>> wrote:

What I get is that by fixing the pom.xml, maven will not package the
connector.
The dependency for the connector was set to compile time that made the
maven to download the connector at compile time instead of at run-time.
Due to this the connector got packaged.

Now changing it to provided will make maven get the connector for
compilation but  due to expectation that this is available at run-time
it
will not be packaged.

-abhi

On 21/02/14 6:01 pm, "Daan Hoogland" 
mailto:daan.hoogl...@gmail.com>> wrote:

sure,

we will need to do something in install instructions as well, do we?

thanks,
Daan

On Fri, Feb 21, 2014 at 1:28 PM, Abhinandan Prateek
mailto:abhinandan.prat...@citrix.com>> wrote:
Daan,

It seems that the dependency on the connector can be changed so that
the
connector is not packaged with the product.
Once Damodar, who is fixing it provides a patch we can take a call.

-abhi



On 21/02/14 5:31 pm, "Daan Hoogland" 
mailto:daan.hoogl...@gmail.com>> wrote:

Animesh,

Having followed the legal discussions and remarks from David on these
matters, I will have to retract my +1 and cast a -1 (binding). I
suggest we postpone 4.3 indefinitely awaiting legal advice and
discussion on how to proceed on this list.

sorry,
Daan

On Fri, Feb 21, 2014 at 12:16 PM, benoit lair 
mailto:kurushi4...@gmail.com>>
wrote:
Hi,

I agree with Florin about GRE tunnel. It is very problematic. If i
can't
get GRE tunnels working with xenserver 6.2, i won't be able to use
the
ACS
4.3

So the jira CLOUDSTACK-5967 is not resolved, isn't it ?

Murali, you said on the Feb 14th (CLOUDSTACK-5967) that if there is
a
new
RC :
"Fix is simple, but not sure we can get this into 4.3, given
its not regression. Will get this in if there is a new RC."

Is it still relevant ?

Regards.

Benoit Lair.



2014-02-21 11:29 GMT+01:00 Srikanteswararao Talluri <
srikanteswararao.tall...@citrix.com>:

There is a bug filed for live migration on ESXi 5.5.
https://issues.apache.org/jira/browse/CLOUDSTACK-6146

I feel we need to fix this bug too in 4.3.

Thanks,
~Talluri

On 20/02/14 11:19 pm, "David Nalley"  wrote:

On Thu, Feb 20, 2014 at 11:23 AM, Chip Childers

wrote:
On Wed, Feb 19, 2014 at 04:25:21AM +, Animesh Chaturvedi
wrote:

[ ] +1  approve

[ ] +0  no opinion

[ ] -1  disapprove (and reason why)


Given the recently noticed legal issues with the
mysql-connector-java
dependency, I'm -1 (binding) until that is resolved.


I hate to have to issue a -1 (binding) but will do so as well.

--David





--
Daan




--
Daan




Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Alena Prokharchyk]

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


Antonio, in general looks good to me. There are some minor fixes that need to 
be done though.

1) ApiServer.java

@Inject()
177
protected DispatchChainFactory dispatchChainFactory = null;


Why do you use @Inject with ()?


2) ApiServlet.java

 domainIdArr = (String[])params.get(ApiConstants.DOMAIN__ID);

* Why do we have DOMAIN__ID and DOMAIN_ID as separate parameters?

public static final String DOMAIN_ID = "domainid";
public static final String DOMAIN__ID = "domainId";

The above doesn't look right to me. Why do we care about the case? the API 
parameter is always transformed to all lowercase letters


3)  CommandCreationWorker.java


  throw new ServerApiException(ApiErrorCode.INTERNAL_ERROR,
50
"Trying to invoke creation on a Command that is not  
BaseAsyncCreateCmd");


* Don't hardcode the class name; retrieve it from the .simpleName method called 
on the class object


4) DispatchChain

for (final DispatchWorker worker : workers) {
if (!worker.handle(task)) {
break;
}
}

* Why do we just break when workder can't handle the task? Aren't we supposed 
to do something?
* Can you please add more logging? At least log in trace that some worker 
handled/coudln't handle the task



4) I can see that you do a lot of initialization like that for private 
variables:

protected AccountManager _accountMgr = null;

its not necessary step as private variables are being initialized to NULL by 
default during declaration. Can you please clean it out?


- Alena Prokharchyk


On Feb. 26, 2014, 9:12 a.m., Antonio Fornie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17888/
> ---
> 
> (Updated Feb. 26, 2014, 9:12 a.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Dispatcher corrections, refactoring and tests. Corrects problems from 
> previous attempts that were reverted by Alena. Most of the changes are the 
> same, but this one is not creating conflicts of Map types for Aync Commands 
> or for parameters as Lists or Maps.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
>   api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
>   api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
>   api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java 
> 592b828 
>   api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java 
> de6e550 
>   
> api/src/org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmProfileCmd.java
>  06d86ec 
>   
> server/resources/META-INF/cloudstack/core/spring-server-core-misc-context.xml 
> fd2f5fb 
>   server/src/com/cloud/api/ApiAsyncJobDispatcher.java 71ac616 
>   server/src/com/cloud/api/ApiDispatcher.java ed95c72 
>   server/src/com/cloud/api/ApiServer.java d715db6 
>   server/src/com/cloud/api/ApiServlet.java 46f7eba 
>   server/src/com/cloud/api/dispatch/CommandCreationWorker.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/DispatchChain.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/DispatchChainFactory.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/DispatchTask.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/DispatchWorker.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/ParamGenericValidationWorker.java 
> PRE-CREATION 
>   server/src/com/cloud/api/dispatch/ParamProcessWorker.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/ParamSemanticValidationWorker.java 
> PRE-CREATION 
>   server/src/com/cloud/api/dispatch/ParamUnpackWorker.java PRE-CREATION 
>   server/src/com/cloud/network/as/AutoScaleManagerImpl.java ff2b2ea 
>   server/src/com/cloud/storage/snapshot/SnapshotSchedulerImpl.java 3159059 
>   server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
>   server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/17888/diff/
> 
> 
> Testing
> ---
> 
> Full build and test plus manually testing many features. Also including 
> CreateTagsCommand that failed in previous commit.
> 
> All unit and integration tests.
> 
> Test CS Web UI with the browser going thr

Re: developers and mysql

[Sonal Ojha]

I am seeing the issue on 4.3 branch, can someone help me how can that be
made to work ??


On Wed, Feb 26, 2014 at 3:32 AM, Hugo Trippaers  wrote:

> We are already pretty much locked in as all our database scripts are MySQL
> specific. If we want to be neutral we should fix that.
>
> Cheers,
>
> Hugo
>
> Sent from my iPhone
>
> > On 25 feb. 2014, at 22:57, David Nalley  wrote:
> >
> > git blame showed that it came from the HA/replication work from Damoder.
> > I didn't speak up at the time, but I am really reluctant for
> > mysql-specific features to sneak in and lock us in.
> >
> >> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang 
> wrote:
> >> Who added the dependency on mysql for framework-db?  We actually worked
> hard to keep that depending on jdbc only.  It should not depend on mysql.
>  We need to fix that.
> >>
> >> --Alex
> >>
> >>> -Original Message-
> >>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> >>> Sent: Tuesday, February 25, 2014 3:34 AM
> >>> To: 
> >>> Subject: Re: developers and mysql
> >>>
> >>> Heya,
> >>>
> >>> Just pushed a change that will make the database work again. :-)
> >>>
> >>>
> >>> @Alex. The mysql jar used to be pulled in as a dependency from
> framework-
> >>> db. As the client target is responsible for building the war file for
> the
> >>> packages including this in the client pom would also put it in the war
> file and
> >>> in the packages.
> >>>
> >>> I think i have an elegant solution, its now included as a dependency
> for both
> >>> the database deploy and the jetty:run target. Which makes it
> effectively a
> >>> "provided" library for the purpose of our maven build. See commit
> >>> 8e6b86ae23dce802044388c5420ff61511d7115b and
> >>> e883877c7a6f9df04b572afd4ee5f10d265bcc3a.
> >>>
> >>> I can deploy a database and start the jetty:run target now without any
> >>> trouble (at least not more trouble than usual ;-) )
> >>>
> >>> My next step is to clean up some of the dependencies. I think that only
> >>> cloud-framework-db should have a provided dependency on mysql. It's the
> >>> only piece of source code that actually needs the mysql driver to be
> present
> >>> during compilation for the optional HA configuration. There are some
> test
> >>> classes that depend on database functionally but those should be moved
> to
> >>> an integration test profile that could include the database driver,
> those tests
> >>> are disabled anyway so they don't cause any trouble now.
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Hugo
> >>>
>  On 25 feb. 2014, at 06:39, Rajani Karuturi <
> rajani.karut...@citrix.com> wrote:
> 
>  Can we move the mysql-connector-java dependency to the parent
> >>> POM(SOURCE-ROOT/pom.xml) and define it different scopes for each
> profile?
> 
>  ie)
> 
> 
>  
>  developer
>    
>    
>  mysql
>  mysql-connector-java
>  compile
>    
>    
>  
>  
>    production
>    
>    
>  mysql
>  mysql-connector-java
>  provided
>    
>    
>  
> 
>  Thanks,
>  ~Rajani
> 
> 
> 
>  On 24-Feb-2014, at 11:41 pm, Hugo Trippaers
> >>> mailto:trip...@gmail.com>> wrote:
> 
>  Indeed,
> 
>  I've been fighting with maven all day to get the development profile
>  to include MySql. No luck yet, will give it another shot tomorrow :-)
> 
>  Hugo
> 
>  Sent from my iPhone
> 
>  On 24 feb. 2014, at 18:21, David Nalley
> >>> mailto:da...@gnsa.us>> wrote:
> 
>  So it should be ok to include the jar in non-default builds. developer
>  and deploydb are not what we'd expect a normal user to consume.
>  (Anyone else's head spinning?)
> 
>  --David
> 
>  On Mon, Feb 24, 2014 at 11:44 AM, John Kinsella
> >>> mailto:j...@stratosec.co>> wrote:
>  I created CLOUDSTACK-6157 over the weekend to track this. Not sure
> >>> adding the jar after compile will help the deploydb target, but will
> give it a try
> >>> this morning.
> 
>  Could we set up the pom.xmls to use the jar for execution if it's
> found in
> >>> the user/system classpaths while respecting the legal requirements?
> 
>  Rayees' suggestion for cloud.spec makes sense for the RPM builds, but
> >>> doesn't affect the developer issues.
> 
>  -He who needs more maven experience
> 
>  On Feb 24, 2014, at 7:36 AM, Hugo Trippaers
> >>> mailto:h...@trippaers.nl>> wrote:
> 
>  Heya,
> 
>  as the mysql dependency is now set to provided in all the poms to fix
> our
> >>> license compliancy the jetty target and the deployed targets are not
> working.
> 
>  I'm trying to configure an optional profile to enable those targets
> to include
> >>> the mysql dependency while executing, but so far no luck. If anyone has
> >>> some bright ideas on how to do this i'm all ears. In the meantime the
>

FYI: 4.3 and 4.3-forward branches not building

[John Kinsella]

Before we go to another vote - apidocs build is failing with:

Traceback (most recent call last):
  File "/home/jlk/code/cloudstack/tools/apidoc/gen_toc.py", line 195, in 

category = choose_category(fn)
  File "/home/jlk/code/cloudstack/tools/apidoc/gen_toc.py", line 175, in 
choose_category
(fn, __file__))
Exception: Need to add a category for listOvsElements.xml to 
/home/jlk/code/cloudstack/tools/apidoc/gen_toc.py:known_categories

It’s working on master, so I’ll presume something needs to be cherry picked…

InsufficientServerCapacityException running "deployDataCenter.py -i devcloud.cfg"

[chris snow]

I am running into the following error when I run "deployDataCenter.py
-i devcloud.cfg".

I get the same error when I run against Rohit's devcloud2 and my
devcloud environments.

I have tried stepping through the code in the eclipse debugger, but
that hasn't helped my to identify the issue.

I have seen some other posts stating this error could be caused by a
multitude of issues. How can I work out the specific issue I am
experiencing?

---

WARN  [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-be33afd5)
Exception while trying to start console proxy
com.cloud.exception.InsufficientServerCapacityException: Unable to
create a deployment for VM[ConsoleProxy|v-1-VM]Scope=interface
com.cloud.dc.DataCenter; id=1
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:925)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
at 
com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:554)
at 
com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:939)
at 
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1660)
at 
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1)
at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:118)
at com.cloud.vm.SystemVmLoadScanner.access$1(SystemVmLoadScanner.java:93)
at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:88)
at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:79)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
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$301(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
WARN  [c.c.s.s.SecondaryStorageManagerImpl]
(secstorage-1:ctx-90f831be) Exception while trying to start secondary
storage vm
com.cloud.exception.InsufficientServerCapacityException: Unable to
create a deployment for VM[SecondaryStorageVm|s-2-VM]Scope=interface
com.cloud.dc.DataCenter; id=1
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:925)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745)
at 
com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
at 
com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:693)
at 
com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1270)
at 
com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
at 
com.cloud.storage.secondary.SecondaryStorageManagerImpl.scanPool(SecondaryStorageManagerImpl.java:1)
at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
at com.cloud.vm.SystemVmLoadScanner.access$1(SystemVmLoadScanner.java:93)
at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:88)
at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:79)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerR

Re: cidrs in acls

[Daan Hoogland]

H Kishan,

I implemented point 1, even though I had some doubts at what you
meant. If you have a minute please look at the last commit in
acl-item-cidrs again. I will work on the migration code as time falls
free.

thanks,
Daan

On Wed, Feb 26, 2014 at 9:12 AM, Daan Hoogland  wrote:
> thanks, will find some time to add those.
>
> On Wed, Feb 26, 2014 at 7:36 AM, Kishan Kavala  
> wrote:
>> Daan,
>>  I looked at the code in acl-item-cidrs. Persisting cidrs in separate table 
>> looks good.
>> Pending items:
>>
>> 1. All references to NetworkACLItemVO.getSourceCidrList() should call 
>> NetworkACLItemDao.loadCidrs. Cidr list won't be available otherwise.
>> 2. Migration code should be added to upgrade path to move existing cidrs to 
>> new network_acl_item_cidr table
>>
>> Regards,
>> kishan
>>
>>> -Original Message-
>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>>> Sent: Wednesday, 19 February 2014 8:33 PM
>>> To: dev; Kishan Kavala
>>> Subject: Re: cidrs in acls
>>>
>>> Kishan,
>>>
>>> Can you have a look  at the branch acl-item-cidrs. I made some code to
>>> handle the cidrs from a separate table. I hardly think this can be enough 
>>> and
>>> would like to create a checklist on what I need to do next.
>>> (item one is use the new transaction model;)
>>>
>>> thanks,
>>> Daan
>>>
>>> On Fri, Jan 17, 2014 at 1:19 PM, Daan Hoogland
>>>  wrote:
>>> > That was what I thought as well. What was the retionale to join them
>>> > into one field?
>>> >
>>> > On Fri, Jan 17, 2014 at 8:32 AM, Kishan Kavala 
>>> wrote:
>>> >> Daan,
>>> >>   Similar to firewall_rules_cidrs, separate table can be used to store 
>>> >> acl
>>> cidrs. Maybe in network_acl_item_cidrs.
>>> >>
>>> >> Regards,
>>> >> kishan
>>> >>
>>> >>> -Original Message-
>>> >>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>>> >>> Sent: Friday, 17 January 2014 1:05 AM
>>> >>> To: Kishan Kavala
>>> >>> Cc: dev
>>> >>> Subject: cidrs in acls
>>> >>>
>>> >>> H Kishan,
>>> >>>
>>> >>> I see you implemented CLOUDSTACK-763. it merges a lot of cidrs into
>>> one field.
>>> >>> The api doesn't check the field length. I enlarged the field in the
>>> >>> create table statement to 2048 for the 4.3 branch. Can you help me
>>> >>> think about a more solid solution, please. It seems to me those cidrs
>>> shouldn't be joint into one field.
>>> >>>
>>> >>> regards,
>>> >>> Daan
>>>
>>>
>>>
>>> --
>>> Daan
>
>
>
> --
> Daan



-- 
Daan

Re: [DISCUSS][PROPOSAL] (CLOUDSTACK-3272)

[Chip Childers]

On Wed, Feb 26, 2014 at 7:37 AM, Sonal Ojha  wrote:
> I am attaching the patch with the email kindly let me know your comments.

Sonal,

Attachments are stripped by the listserv.  You might have to include the text.

[GSoC] Fwd: Google Summer of Code 2013 Mentor Registration

[Sebastien Goasguen]

Folks,

ASF has been accepted has a mentoring organization for Google Summer of Code 
2014.

If you are interested and have the time to be a mentor for a CloudStack project 
please see below to register as a mentor.
Also enter your project idea in JIRA and tag it with 'gsoc2014'

Currently Mike Tutkowski and I are planning to mentor.

-Sebastien

Begin forwarded message:

> From: Ulrich Stärk 
> Subject: Google Summer of Code 2013 Mentor Registration
> Date: February 26, 2014 1:38:16 PM EST
> To: p...@apache.org
> Cc: ment...@community.apache.org
> Reply-To: priv...@libcloud.apache.org
> Reply-To: ment...@community.apache.org
> 
> Dear PMCs,
> 
> I'm happy to announce that the ASF has made it onto the list of 190 accepted 
> organizations for
> Google Summer of Code 2014! [1,2]
> 
> It is now time for the mentors to sign up, so please pass this email on to 
> your community and podlings. If you aren’t already subscribed to 
> ment...@community.apache.org (formerly code-awa...@apache.org) you should do 
> so now else you might miss important information.
> 
> Mentor signup requires two steps: mentor signup in Melange and PMC 
> acknowledgement.
> 
> If you want to mentor a project in this year's SoC you will have to
> 
> 1. Be an Apache committer.
> 2. Register with Melange and set up a profile [3].
> 3. Add your username (formerly known as link_id) to [4]. This is NOT your 
> email address but your
> Melange username. You can find it at the top of any page once you are logged 
> in.
> 4. Request an acknowledgement from the PMC for which you want to mentor 
> projects. Use the below
> template and do not forget to copy ment...@community.apache.org.
> 5. Once a PMC member acknowledges the request to mentor, and only then, go to 
> [5] and send a connection request.
> 
> PMCs, read carefully please.
> 
> We request that each mentor is acknowledged by a PMC member. This is to 
> ensure the mentor is in good
> standing with the community. When you receive a request for acknowledgement, 
> please ACK it and cc
> ment...@community.apache.org
> 
> Lastly, it is not yet too late to record your ideas in Jira (see my previous 
> emails for details). Students will now begin to explore ideas so if you 
> haven’t already done so, record your ideas immediately!
> 
> Cheers,
> 
> Uli
> 
> mentor request email template:
> 
> to: private@.apache.org
> cc: ment...@community.apache.org
> subject: GSoC 2013 mentor request for 
> 
>  PMC,
> 
> please acknowledge my request to become a mentor for Google Summer of Code 
> 2013 projects for Apache
> .
> 
> My Melange username is .
> 
> 
> 
> 
> 
> [1] http://www.google-melange.com/gsoc/org/list/public/google/gsoc2014
> [2] http://www.google-melange.com/gsoc/org2/google/gsoc2014/apache
> [3] http://www.google-melange.com/gsoc/homepage/google/gsoc2014
> [4] https://svn.apache.org/repos/private/committers/GsocLinkId.txt
> [5] 
> http://www.google-melange.com/gsoc/connection/start/user/google/gsoc2014/apache

Re: FYI: 4.3 and 4.3-forward branches not building

[Sebastien Goasguen]

On Feb 26, 2014, at 1:31 PM, John Kinsella  wrote:

> Before we go to another vote - apidocs build is failing with:
> 
> Traceback (most recent call last):
>  File "/home/jlk/code/cloudstack/tools/apidoc/gen_toc.py", line 195, in 
> 
>category = choose_category(fn)
>  File "/home/jlk/code/cloudstack/tools/apidoc/gen_toc.py", line 175, in 
> choose_category
>(fn, __file__))
> Exception: Need to add a category for listOvsElements.xml to 
> /home/jlk/code/cloudstack/tools/apidoc/gen_toc.py:known_categories
> 
> It’s working on master, so I’ll presume something needs to be cherry picked…
> 

I staged the apidocs for 4.3 last week. Paul Angus built and sent me a patch 
(which was too big for review board).
You can see it here:

http://cloudstack.staging.apache.org/docs/api/

there is no listOvsElements it seems...

-sebastien

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Antonio Fornié Casarrubios]

Hi Alena,

I answer to your comments inline:


2014-02-26 19:08 GMT+01:00 Alena Prokharchyk :

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17888/
>
> Antonio, in general looks good to me. There are some minor fixes that need to 
> be done though.
>
> 1) ApiServer.java
>
> @Inject()
> 177
> protected DispatchChainFactory dispatchChainFactory = null;
>
>
> Why do you use @Inject with ()?
>
>
*I tried some parameters with the Inject annotation but finally I decided
to use it as it is here. Just a habit from using other types of DI
annotations. I just didn't didn't remove the () in this one, but as you
know it's exactly the same so it didn't even bring my attention. I can
change that or if you approved this patch, change it in the next patch.
Again, it's just the same.*



> 2) ApiServlet.java
>
>  domainIdArr = (String[])params.get(ApiConstants.DOMAIN__ID);
>
> * Why do we have DOMAIN__ID and DOMAIN_ID as separate parameters?
>
> public static final String DOMAIN_ID = "domainid";
> public static final String DOMAIN__ID = "domainId";
>
> The above doesn't look right to me. Why do we care about the case? the API 
> parameter is always transformed to all lowercase letters
>
> *Having these almost identical Strings is not my change, ApiServlet was
already using both with I and i (domainid and domainId) so I just kept it
as it is (I assume removing one of them may cause a problem when it comes
in the req. In order to create the constants for both values I just chose
these names: no names would make much more sense because having this two
Strings were already something strange. There are several strange things
like this, I just fixed a few and moved plenty from hardcoded values to
constants, but no more than that, my main focus was something else and the
patch is already very big.*

3)  CommandCreationWorker.java
>
>
>   throw new ServerApiException(ApiErrorCode.INTERNAL_ERROR,
> 50
> "Trying to invoke creation on a Command that is not  
> BaseAsyncCreateCmd");
>
>
> * Don't hardcode the class name; retrieve it from the .simpleName method 
> called on the class object
>
> *Retrieve it? This is a piece of code that was in
ApiDispatcher#dispatchCreateCmd just after calling processParameters, so it
had to be a next worker in the chain, but I kept the code as it was. And
this specific method was only invoked after checking the command was
BaseAsyncCreateCmd (or any class extending, of course), so I created the
same check in the worker. And then of course I keep also the reason to fail
in the error msg. If it fails the only thing I care is that it is not a
BaseAsyncCreateCmd as it should... so I don't understand what do you
propose there. For anybody who chages this code in the future, this error
will tell them they should not apply this worker when the dispatch chain is
not the expected type.*

> 4) DispatchChain
>
> for (final DispatchWorker worker : workers) {
> if (!worker.handle(task)) {
> break;
> }
> }
>
> * Why do we just break when workder can't handle the task? Aren't we supposed 
> to do something?
> * Can you please add more logging? At least log in trace that some worker 
> handled/coudln't handle the task
>
>
> *There are many ways to create a Chain of Responsibility, for this case I
decided to go for a one way chain (instead of a typical two way flow) in
which workers share a task where they apply  their work and pass their
changes. They also have the power to stop the chain if the programmer
decides so in her code. I'm not assuming the worker can't handle anything
or not not doing something, I am just making sure I provide a way to stop
the chain if one of the workers decides so. If there were something to log,
the worker would know what and if something requires so I guess they will
raise and exception instead of just returning false. We don't have anything
to log just because the behavior was to stop the chain. Just see it as JEE
filters where they can decide to do whatever even there is no error.*


>
> 4) I can see that you do a lot of initialization like that for private 
> variables:
>
> protected AccountManager _accountMgr = null;
>
> its not necessary step as private variables are being initialized to NULL by 
> default during declaration. Can you please clean it out?
>
>
>
*I know. In Java local variables are not initialized, but instance ones are
(booleans to false, numbers to cero, objects to null...). But I find it
more clear to put it this way, further people may ignore or forget it,
specially non Java people helping in cloudstack. It's also something I've
seen in many Java projects. Again, it's just the same. If you think this is
not clean and should be changed before the patch is accepted, I can change
that too.*

*Upon reception of your comments I will change and upload anything.*

- Alena Prokharchyk
>
> On February 26th, 2014, 9:12 a.m. UTC, Antonio Fornie wrote:
>   Review re

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Alena Prokharchyk]

Antonio, please see my 2 comments inline.

-Alena.

On 2/26/14, 1:17 PM, "Antonio Fornié Casarrubios"
 wrote:

>Hi Alena,
>
>I answer to your comments inline:
>
>
>2014-02-26 19:08 GMT+01:00 Alena Prokharchyk
>:
>
>>This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/17888/
>>
>> Antonio, in general looks good to me. There are some minor fixes that
>>need to be done though.
>>
>> 1) ApiServer.java
>>
>> @Inject()
>> 177
>> protected DispatchChainFactory dispatchChainFactory = null;
>>
>>
>> Why do you use @Inject with ()?
>>
>>
>*I tried some parameters with the Inject annotation but finally I decided
>to use it as it is here. Just a habit from using other types of DI
>annotations. I just didn't didn't remove the () in this one, but as you
>know it's exactly the same so it didn't even bring my attention. I can
>change that or if you approved this patch, change it in the next patch.
>Again, it's just the same.*
>
>
>
>> 2) ApiServlet.java
>>
>>  domainIdArr = (String[])params.get(ApiConstants.DOMAIN__ID);
>>
>> * Why do we have DOMAIN__ID and DOMAIN_ID as separate parameters?
>>
>> public static final String DOMAIN_ID = "domainid";
>> public static final String DOMAIN__ID = "domainId";
>>
>> The above doesn't look right to me. Why do we care about the case? the
>>API parameter is always transformed to all lowercase letters
>>
>> *Having these almost identical Strings is not my change, ApiServlet was
>already using both with I and i (domainid and domainId) so I just kept it
>as it is (I assume removing one of them may cause a problem when it comes
>in the req. In order to create the constants for both values I just chose
>these names: no names would make much more sense because having this two
>Strings were already something strange. There are several strange things
>like this, I just fixed a few and moved plenty from hardcoded values to
>constants, but no more than that, my main focus was something else and the
>patch is already very big.*
>
>3)  CommandCreationWorker.java
>>
>>
>>   throw new ServerApiException(ApiErrorCode.INTERNAL_ERROR,
>> 50
>> "Trying to invoke creation on a Command that is not
>> BaseAsyncCreateCmd");
>>
>>
>> * Don't hardcode the class name; retrieve it from the .simpleName
>>method called on the class object
>>
>> *Retrieve it? This is a piece of code that was in
>ApiDispatcher#dispatchCreateCmd just after calling processParameters, so
>it
>had to be a next worker in the chain, but I kept the code as it was. And
>this specific method was only invoked after checking the command was
>BaseAsyncCreateCmd (or any class extending, of course), so I created the
>same check in the worker. And then of course I keep also the reason to
>fail
>in the error msg. If it fails the only thing I care is that it is not a
>BaseAsyncCreateCmd as it should... so I don't understand what do you
>propose there. For anybody who chages this code in the future, this error
>will tell them they should not apply this worker when the dispatch chain
>is
>not the expected type.*


:) What I¹ve meant is, instead of "Trying to invoke creation on a Command
that is not  BaseAsyncCreateCmd², log it as "Trying to invoke creation on
a Command that is not ³ + BaseAsyncCreateCmd.class.getSimpleName(). So in
case someone changes the class name in the future, you don¹t have to dig
in into hardcoded stuff in order to change it, as it will change
dynamically


>
>> 4) DispatchChain
>>
>> for (final DispatchWorker worker : workers) {
>> if (!worker.handle(task)) {
>> break;
>> }
>> }
>>
>> * Why do we just break when workder can't handle the task? Aren't we
>>supposed to do something?
>> * Can you please add more logging? At least log in trace that some
>>worker handled/coudln't handle the task
>>
>>
>> *There are many ways to create a Chain of Responsibility, for this case
>>I
>decided to go for a one way chain (instead of a typical two way flow) in
>which workers share a task where they apply  their work and pass their
>changes. They also have the power to stop the chain if the programmer
>decides so in her code. I'm not assuming the worker can't handle anything
>or not not doing something, I am just making sure I provide a way to stop
>the chain if one of the workers decides so. If there were something to
>log,
>the worker would know what and if something requires so I guess they will
>raise and exception instead of just returning false. We don't have
>anything
>to log just because the behavior was to stop the chain. Just see it as JEE
>filters where they can decide to do whatever even there is no error.*



Stopping and doing nothing after all doesn¹t look right to me, as you
don¹t pass the result to the caller stack to process it further depending
on the return type. I would rather change work.handle() return type to
void. As as you said, worker would throw an exception anyway if something
goes wrong.

>
>
>>
>> 4) I can see t

RE: [DISCUSS] Policy blocker?

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chipchild...@apache.org]
> Sent: Wednesday, February 26, 2014 6:44 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Policy blocker?
> 
> On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi
>  wrote:
> >
> > Folks since the liability of Release manager has been called out explicitly
> for the release I want to call out that I cannot take personal liability for a
> release and I am not sure why would anyone else in Release Manager role
> will take up personal liability. I don't see anything called out in our bylaws
> that states Release Manager being liable.
> >
> > That being said I am seeking advice from ASF mentors and will discuss it in
> PMC. I  will proceed and build an RC after this issue is resolved.
> >
> > Thanks
> > Animesh
> 
> A couple of things:
> 
> First, we don't have any "mentors" anymore...  we're a TLP.
> 
> Second, although the question of "liability" has been clarified in the
> private@ thread, I'll summarize briefly here:
> 
> The reason that we follow the voting process (where the PMC votes are
> binding) and other ASF-wide policies, is so that any release is an "act of the
> foundation" and not an act of an individual.  The point is that if someone
> were to purposefully ignore policy, then they put themselves at risk.  The
> whole reason for the foundation to have it's policies is to protect all of the
> committers and contributors from personal liability!  So the only thing that
> really matters is that if we follow the policies of the foundation, there's
> nothing to worry about.
> 
> Being a release manager is nothing to worry about...  the whole PMC is
> helping to ensure that we follow policies.  As our current 4.3 issue has
> pointed out, sometimes this means we have to slow down to fix something.
> If something slipped through, it's still not a "liability"
> issue in practical terms.  It's just a mistake that we would then work to
> correct.
> 
> Make sense?
> 
> 
I am still not convinced or comfortable with release manager's liability for 
release content. It seems we are going with practical approach but since 
legality has been called out the legal instrument needs to be clearly defined. 
I will respond pack in private with more clarification

RE: 4.4 Feature Freeze

[Animesh Chaturvedi]

Mike I share your opinion most of us have been pretty much on 4.3 until now, 
and pushing out the release seems reasonable. As I called out in earlier mail 
the feature proposal date was not called out for 4.4 and as such giving little 
extra room seems reasonable.

Animesh

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, February 26, 2014 7:29 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
> 
> I think we're having this discussion after every release because we're
> beginning to realize that a four-month release cycle has not been very
> realistic for us yet.
> 
> The main issue I encounter is our month-long RC cycle where I spend a
> bunch of time validating the RC and (during that timeframe) less time
> developing for the next release as I had initially planned.
> 
> Perhaps instead of extending the cycle we could consider ways to actually
> meet the schedule on a consistent basis. That would be fine, as well.
> 
> 
> On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers 
> wrote:
> 
> > -1 on postponing the feature freeze. We are having this discussion
> > after every release, however we agreed to do a 4 month cycle so let's stick
> to it.
> >
> > If there are important features that are currently being developed but
> > might not make this cut-off date we should discuss that separately,
> > but as a point of principle lets stick to the release schedule as proposed.
> >
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 26 feb. 2014, at 15:23, Tracy Phillips
> > 
> > wrote:
> >
> > > +1 to Daan.
> > >
> > > Tracy Phillips
> > > Weberize, Inc.
> > >
> > >
> > > On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland
> > > > >wrote:
> > >
> > >> -1 for postponing the feature freeze. It will amount to more
> > >> features in the release. I'd rather shorten the cycle and do more
> > >> releases then to pack more bugs in a single go.
> > >>
> > >> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star 
> wrote:
> > >>> +1
> > >>>
> > >>>
> > >>> 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
> > >> abhinandan.prat...@citrix.com
> >  :
> > >>>
> >  +1 for 4.4 feature freeze on 3/28.
> > 
> >  On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
> >   wrote:
> > 
> > >> -Original Message-
> > >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > >> Sent: 26 February 2014 04:46
> > >> To: dev@cloudstack.apache.org
> > >> Subject: Re: 4.4 Feature Freeze
> > >>
> > >> I think this is a good idea, Animesh (to push out feature
> > >> freeze to 3/28).
> > >
> > > +1 to move 4.4 feature freeze date to 3/28.
> > >
> > > Regards,
> > > Sateesh
> > >
> > >> I also agree we should discuss 4+ month development cycles again.
> > >>
> > >>
> > >> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
> > >> animesh.chaturv...@citrix.com> wrote:
> > >>
> > >>> I will start a separate discussion on 4 month cycle or longer,
> > >>> but wanted to call out one more important date.
> > >>>
> > >>> We have a last day for feature proposal date which is
> > >>> typically a month before feature freeze date. If following 4.3
> > >>> schedule + 4
> > >> month
> > >>> it would have been 2/14 and we are already past that. Since it
> > >>> was
> > >> not
> > >>> announced for
> > >>> 4.4 release yet my suggestion would be to keep feature
> > >>> proposal
> > >> open
> > >>> for another week and push all  the dates out by 2 weeks to
> > >>> give
> > >> folks
> > >>> opportunity to finish up their features for new proposals that
> > >>> are
> > >> yet
> > >>> to come out.
> > >>>
> > >>> To be clear that would mean pushing out feature freeze to 3/28
> > >>> from
> > >>> 3/14 and all the other dates likewise.
> > >>>
> > >>>
> > >>> Thanks
> > >>> Animesh
> > >>>
> >  -Original Message-
> >  From: Animesh Chaturvedi
> >  [mailto:animesh.chaturv...@citrix.com]
> >  Sent: Tuesday, February 25, 2014 1:05 PM
> >  To: dev@cloudstack.apache.org
> >  Subject: RE: 4.4 Feature Freeze
> > 
> >  With the experience of 4.2 and 4.3 I think we should discuss
> >  if
> > >> we
> >  can realistically achieve 4 month cycle our RCs take 2
> >  months. I
> > >> was
> >  going to open up the discussion after 4.3 is shipped though.
> > 
> > > -Original Message-
> > > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> > > Trippaers
> > > Sent: Tuesday, February 25, 2014 8:50 AM
> > > To: 
> > > Subject: Re: 4.4 Feature Freeze
> > >
> > > Hey,
> > >
> > > If we stick to our 4 month release schedule the feature
> > > freeze
> > >> is
> > > four months after the feature freeze of 4.3.

Re: [DISCUSS] Policy blocker?

[Chip Childers]

On Wed, Feb 26, 2014 at 4:24 PM, Animesh Chaturvedi
 wrote:
> I am still not convinced or comfortable with release manager's liability for 
> release content. It seems
> we are going with practical approach but since legality has been called out 
> the legal instrument needs
> to be clearly defined. I will respond pack in private with more clarification

Think of it this way (but remember INAL):

If you do something for your $dayjob, if it's done as part of your job
and done following your company's policies, your corporation (I would
hope) protect you.  That's because you are doing something you are
authorized to do on behalf of your corporation.  Similarly, we follow
ASF policies and procedures so that things we do in our project are
something that the foundation considers "an act of the foundation".

Anyway, happy to discuss in private as well...

-chip

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Antonio Fornié Casarrubios]

Hi Alena,

Answer inline:



2014-02-26 22:24 GMT+01:00 Alena Prokharchyk :

> Antonio, please see my 2 comments inline.
>
> -Alena.
>
> On 2/26/14, 1:17 PM, "Antonio Fornié Casarrubios"
>  wrote:
>
> >Hi Alena,
> >
> >I answer to your comments inline:
> >
> >
> >2014-02-26 19:08 GMT+01:00 Alena Prokharchyk
> >:
> >
> >>This is an automatically generated e-mail. To reply, visit:
> >> https://reviews.apache.org/r/17888/
> >>
> >> Antonio, in general looks good to me. There are some minor fixes that
> >>need to be done though.
> >>
> >> 1) ApiServer.java
> >>
> >> @Inject()
> >> 177
> >> protected DispatchChainFactory dispatchChainFactory = null;
> >>
> >>
> >> Why do you use @Inject with ()?
> >>
> >>
> >*I tried some parameters with the Inject annotation but finally I decided
> >to use it as it is here. Just a habit from using other types of DI
> >annotations. I just didn't didn't remove the () in this one, but as you
> >know it's exactly the same so it didn't even bring my attention. I can
> >change that or if you approved this patch, change it in the next patch.
> >Again, it's just the same.*
> >
> >
> >
> >> 2) ApiServlet.java
> >>
> >>  domainIdArr = (String[])params.get(ApiConstants.DOMAIN__ID);
> >>
> >> * Why do we have DOMAIN__ID and DOMAIN_ID as separate parameters?
> >>
> >> public static final String DOMAIN_ID = "domainid";
> >> public static final String DOMAIN__ID = "domainId";
> >>
> >> The above doesn't look right to me. Why do we care about the case? the
> >>API parameter is always transformed to all lowercase letters
> >>
> >> *Having these almost identical Strings is not my change, ApiServlet was
> >already using both with I and i (domainid and domainId) so I just kept it
> >as it is (I assume removing one of them may cause a problem when it comes
> >in the req. In order to create the constants for both values I just chose
> >these names: no names would make much more sense because having this two
> >Strings were already something strange. There are several strange things
> >like this, I just fixed a few and moved plenty from hardcoded values to
> >constants, but no more than that, my main focus was something else and the
> >patch is already very big.*
> >
> >3)  CommandCreationWorker.java
> >>
> >>
> >>   throw new ServerApiException(ApiErrorCode.INTERNAL_ERROR,
> >> 50
> >> "Trying to invoke creation on a Command that is not
> >> BaseAsyncCreateCmd");
> >>
> >>
> >> * Don't hardcode the class name; retrieve it from the .simpleName
> >>method called on the class object
> >>
> >> *Retrieve it? This is a piece of code that was in
> >ApiDispatcher#dispatchCreateCmd just after calling processParameters, so
> >it
> >had to be a next worker in the chain, but I kept the code as it was. And
> >this specific method was only invoked after checking the command was
> >BaseAsyncCreateCmd (or any class extending, of course), so I created the
> >same check in the worker. And then of course I keep also the reason to
> >fail
> >in the error msg. If it fails the only thing I care is that it is not a
> >BaseAsyncCreateCmd as it should... so I don't understand what do you
> >propose there. For anybody who chages this code in the future, this error
> >will tell them they should not apply this worker when the dispatch chain
> >is
> >not the expected type.*
>
>
> :) What I¹ve meant is, instead of "Trying to invoke creation on a Command
> that is not  BaseAsyncCreateCmd², log it as "Trying to invoke creation on
> a Command that is not ³ + BaseAsyncCreateCmd.class.getSimpleName(). So in
> case someone changes the class name in the future, you don¹t have to dig
> in into hardcoded stuff in order to change it, as it will change
> dynamically
>
>
*** I see, sorry I dind't understand you meant that. I will sure change
that, good point.



>
> >
> >> 4) DispatchChain
> >>
> >> for (final DispatchWorker worker : workers) {
> >> if (!worker.handle(task)) {
> >> break;
> >> }
> >> }
> >>
> >> * Why do we just break when workder can't handle the task? Aren't we
> >>supposed to do something?
> >> * Can you please add more logging? At least log in trace that some
> >>worker handled/coudln't handle the task
> >>
> >>
> >> *There are many ways to create a Chain of Responsibility, for this case
> >>I
> >decided to go for a one way chain (instead of a typical two way flow) in
> >which workers share a task where they apply  their work and pass their
> >changes. They also have the power to stop the chain if the programmer
> >decides so in her code. I'm not assuming the worker can't handle anything
> >or not not doing something, I am just making sure I provide a way to stop
> >the chain if one of the workers decides so. If there were something to
> >log,
> >the worker would know what and if something requires so I guess they will
> >raise and exception instead of just returning false. We don't have
> >anything
> >to log just because the behavior was to stop the chain. Ju

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Alena Prokharchyk]

Antonio,

I still don’t quite see why false result returned from one of the workers, 
should silently stop other workers if those workers are a) independent b) have 
their own way of processing the failures in asynchronous manner later as you 
stated.

You also say "didn't want each worker to have a reference to the next.". But in 
your case you do obey the reference in indirect when failure of one worker 
execution affects the other? I'm confused.

As an example, we can look at couple of examples of something similar in 
CloudStack code.

1) SecurityChecker Adapters. All adapters are invoked on the resource, and if 
something fails, it throws an exception that clearly stops others checkers from 
execution.

2) UserAuthenticator Adapter. When user logs in, all adapters defined in the 
config file, get invoked in specific order. If one of them fails 
(RuntimeException is thrown), the login attempt fails as well, and other 
adapters are not invoked.


In other words, if you decide that each worker returns boolean variable, it 
means that you have to process that result in the caller stack, which the 
code-to-review doesn't do. You either:

* throw RuntimeException when one of the workers returns failure. It would 
eliminate your fear that developer writing the worker, will forget to do it in 
handle() method itself
* change the return type to void. I'm pretty sure the developers writing the 
workers, will take care of throwing an exception on validation failure

Whatever one you prefer from the above, I'm fine with.

Let me know what you think,
-Alena.

From: Antonio Fornié Casarrubios 
mailto:antonio.for...@gmail.com>>
Date: Wednesday, February 26, 2014 at 2:02 PM
To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, daan Hoogland 
mailto:daan.hoogl...@gmail.com>>, Hugo Trippaers 
mailto:htrippa...@schubergphilis.com>>
Subject: Re: Review Request 17888: Dispatcher corrections, refactoring and 
tests. Corrects problems from previous attempt

Hi Alena,

Answer inline:



2014-02-26 22:24 GMT+01:00 Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>:
Antonio, please see my 2 comments inline.

-Alena.

On 2/26/14, 1:17 PM, "Antonio Fornié Casarrubios"
mailto:antonio.for...@gmail.com>> wrote:

>Hi Alena,
>
>I answer to your comments inline:
>
>
>2014-02-26 19:08 GMT+01:00 Alena Prokharchyk
>mailto:alena.prokharc...@citrix.com>>:
>
>>This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/17888/
>>
>> Antonio, in general looks good to me. There are some minor fixes that
>>need to be done though.
>>
>> 1) ApiServer.java
>>
>> @Inject()
>> 177
>> protected DispatchChainFactory dispatchChainFactory = null;
>>
>>
>> Why do you use @Inject with ()?
>>
>>
>*I tried some parameters with the Inject annotation but finally I decided
>to use it as it is here. Just a habit from using other types of DI
>annotations. I just didn't didn't remove the () in this one, but as you
>know it's exactly the same so it didn't even bring my attention. I can
>change that or if you approved this patch, change it in the next patch.
>Again, it's just the same.*
>
>
>
>> 2) ApiServlet.java
>>
>>  domainIdArr = (String[])params.get(ApiConstants.DOMAIN__ID);
>>
>> * Why do we have DOMAIN__ID and DOMAIN_ID as separate parameters?
>>
>> public static final String DOMAIN_ID = "domainid";
>> public static final String DOMAIN__ID = "domainId";
>>
>> The above doesn't look right to me. Why do we care about the case? the
>>API parameter is always transformed to all lowercase letters
>>
>> *Having these almost identical Strings is not my change, ApiServlet was
>already using both with I and i (domainid and domainId) so I just kept it
>as it is (I assume removing one of them may cause a problem when it comes
>in the req. In order to create the constants for both values I just chose
>these names: no names would make much more sense because having this two
>Strings were already something strange. There are several strange things
>like this, I just fixed a few and moved plenty from hardcoded values to
>constants, but no more than that, my main focus was something else and the
>patch is already very big.*
>
>3)  CommandCreationWorker.java
>>
>>
>>   throw new ServerApiException(ApiErrorCode.INTERNAL_ERROR,
>> 50
>> "Trying to invoke creation on a Command that is not
>> BaseAsyncCreateCmd");
>>
>>
>> * Don't hardcode the class name; retrieve it from the .simpleName
>>method called on the class object
>>
>> *Retrieve it? This is a piece of code that was in
>ApiDispatcher#dispatchCreateCmd just after calling processParameters, so
>it
>had to be a next worker in the chain, but I kept the code as it was. And
>this specific method was only invoked after checking the command was
>BaseAsyncCreateCmd (or any class extending, of course), so I created the
>same check in the worker. And then of

RE: developers and mysql

[Alex Huang]

@Hugo

The mysql scripts is a legacy of we used to dump the mysql db to create the 
create-schema sql but it is at worst still a runtime dependency.  We should fix 
it but I don't think it's as high a priority as the compile time dependency 
that has been introduced.

@Damoder,

Can you take a look at StaticStrategy.java?  This is the only file that 
requires mysql but I couldn't find anywhere in the code that references this 
class.  I then looked at the bug and wiki and it also doesn't mentioned that 
dependency on mysql has been added.  It doesn't make sense for CloudStack to 
include this automatically.  There are many ways to provide DB HA and 
incorporate it into our code just limits the possibilities.  We can for example 
document this as a way to do it in on the wiki for example but I just don't see 
why we would use code to limit it.

Thanks.

--Alex

> -Original Message-
> From: Hugo Trippaers [mailto:trip...@gmail.com]
> Sent: Tuesday, February 25, 2014 2:02 PM
> To: dev@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: developers and mysql
> 
> We are already pretty much locked in as all our database scripts are MySQL
> specific. If we want to be neutral we should fix that.
> 
> Cheers,
> 
> Hugo
> 
> Sent from my iPhone
> 
> > On 25 feb. 2014, at 22:57, David Nalley  wrote:
> >
> > git blame showed that it came from the HA/replication work from Damoder.
> > I didn't speak up at the time, but I am really reluctant for
> > mysql-specific features to sneak in and lock us in.
> >
> >> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang 
> wrote:
> >> Who added the dependency on mysql for framework-db?  We actually
> worked hard to keep that depending on jdbc only.  It should not depend on
> mysql.  We need to fix that.
> >>
> >> --Alex
> >>
> >>> -Original Message-
> >>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> >>> Sent: Tuesday, February 25, 2014 3:34 AM
> >>> To: 
> >>> Subject: Re: developers and mysql
> >>>
> >>> Heya,
> >>>
> >>> Just pushed a change that will make the database work again. :-)
> >>>
> >>>
> >>> @Alex. The mysql jar used to be pulled in as a dependency from
> >>> framework- db. As the client target is responsible for building the
> >>> war file for the packages including this in the client pom would
> >>> also put it in the war file and in the packages.
> >>>
> >>> I think i have an elegant solution, its now included as a dependency
> >>> for both the database deploy and the jetty:run target. Which makes
> >>> it effectively a "provided" library for the purpose of our maven
> >>> build. See commit 8e6b86ae23dce802044388c5420ff61511d7115b and
> >>> e883877c7a6f9df04b572afd4ee5f10d265bcc3a.
> >>>
> >>> I can deploy a database and start the jetty:run target now without
> >>> any trouble (at least not more trouble than usual ;-) )
> >>>
> >>> My next step is to clean up some of the dependencies. I think that
> >>> only cloud-framework-db should have a provided dependency on mysql.
> >>> It's the only piece of source code that actually needs the mysql
> >>> driver to be present during compilation for the optional HA
> >>> configuration. There are some test classes that depend on database
> >>> functionally but those should be moved to an integration test
> >>> profile that could include the database driver, those tests are disabled
> anyway so they don't cause any trouble now.
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Hugo
> >>>
>  On 25 feb. 2014, at 06:39, Rajani Karuturi 
> wrote:
> 
>  Can we move the mysql-connector-java dependency to the parent
> >>> POM(SOURCE-ROOT/pom.xml) and define it different scopes for each
> profile?
> 
>  ie)
> 
> 
>  
>  developer
>    
>    
>  mysql
>  mysql-connector-java
>  compile
>    
>    
>  
>  
>    production
>    
>    
>  mysql
>  mysql-connector-java
>  provided
>    
>    
>  
> 
>  Thanks,
>  ~Rajani
> 
> 
> 
>  On 24-Feb-2014, at 11:41 pm, Hugo Trippaers
> >>> mailto:trip...@gmail.com>> wrote:
> 
>  Indeed,
> 
>  I've been fighting with maven all day to get the development
>  profile to include MySql. No luck yet, will give it another shot
>  tomorrow :-)
> 
>  Hugo
> 
>  Sent from my iPhone
> 
>  On 24 feb. 2014, at 18:21, David Nalley
> >>> mailto:da...@gnsa.us>> wrote:
> 
>  So it should be ok to include the jar in non-default builds.
>  developer and deploydb are not what we'd expect a normal user to
> consume.
>  (Anyone else's head spinning?)
> 
>  --David
> 
>  On Mon, Feb 24, 2014 at 11:44 AM, John Kinsella
> >>> mailto:j...@stratosec.co>> wrote:
>  I created CLOUDSTACK-6157 over the weekend to track this. Not sure
> >>> adding the jar after compile will help the deploydb target, but will
> >>

Re: [4.3] [Cherry-pick] CLOUDSTACK-6174, CLOUDSTACK-6175

[Min Chen]

Animesh,

Can you cherry pick the following commits from 4.3-forward to 4.3?

4c83f80c809674cb8ff9561d546a6ade25d983f8
CLOUDSTACK-6174: Provide separate option for Windows Server 2012 R2 as
an OS type when registering template.



94257c0fc85c7178e6ca3146662de08feee2c290
CLOUDSTACK-6175:s3.singleupload.max.size option not applicable for
backup snapshot on KVM.


Thanks
-min

CloudStack-setup-management

[María Noelia Gil]

Hi, I installed the CloudStack-setup-management package, after I installed the 
database and have made ​​the necessary settings, but I can not access 
http://localhost:8080/client. 

Any solution? 

thanks

Re: developers and mysql

[Mike Tutkowski]

Yeah, if we have a 4.3 workaround for this, that would be great. Thanks


On Wed, Feb 26, 2014 at 11:19 AM, Sonal Ojha  wrote:

> I am seeing the issue on 4.3 branch, can someone help me how can that be
> made to work ??
>
>
> On Wed, Feb 26, 2014 at 3:32 AM, Hugo Trippaers  wrote:
>
> > We are already pretty much locked in as all our database scripts are
> MySQL
> > specific. If we want to be neutral we should fix that.
> >
> > Cheers,
> >
> > Hugo
> >
> > Sent from my iPhone
> >
> > > On 25 feb. 2014, at 22:57, David Nalley  wrote:
> > >
> > > git blame showed that it came from the HA/replication work from
> Damoder.
> > > I didn't speak up at the time, but I am really reluctant for
> > > mysql-specific features to sneak in and lock us in.
> > >
> > >> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang 
> > wrote:
> > >> Who added the dependency on mysql for framework-db?  We actually
> worked
> > hard to keep that depending on jdbc only.  It should not depend on mysql.
> >  We need to fix that.
> > >>
> > >> --Alex
> > >>
> > >>> -Original Message-
> > >>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> > >>> Sent: Tuesday, February 25, 2014 3:34 AM
> > >>> To: 
> > >>> Subject: Re: developers and mysql
> > >>>
> > >>> Heya,
> > >>>
> > >>> Just pushed a change that will make the database work again. :-)
> > >>>
> > >>>
> > >>> @Alex. The mysql jar used to be pulled in as a dependency from
> > framework-
> > >>> db. As the client target is responsible for building the war file for
> > the
> > >>> packages including this in the client pom would also put it in the
> war
> > file and
> > >>> in the packages.
> > >>>
> > >>> I think i have an elegant solution, its now included as a dependency
> > for both
> > >>> the database deploy and the jetty:run target. Which makes it
> > effectively a
> > >>> "provided" library for the purpose of our maven build. See commit
> > >>> 8e6b86ae23dce802044388c5420ff61511d7115b and
> > >>> e883877c7a6f9df04b572afd4ee5f10d265bcc3a.
> > >>>
> > >>> I can deploy a database and start the jetty:run target now without
> any
> > >>> trouble (at least not more trouble than usual ;-) )
> > >>>
> > >>> My next step is to clean up some of the dependencies. I think that
> only
> > >>> cloud-framework-db should have a provided dependency on mysql. It's
> the
> > >>> only piece of source code that actually needs the mysql driver to be
> > present
> > >>> during compilation for the optional HA configuration. There are some
> > test
> > >>> classes that depend on database functionally but those should be
> moved
> > to
> > >>> an integration test profile that could include the database driver,
> > those tests
> > >>> are disabled anyway so they don't cause any trouble now.
> > >>>
> > >>>
> > >>> Cheers,
> > >>>
> > >>> Hugo
> > >>>
> >  On 25 feb. 2014, at 06:39, Rajani Karuturi <
> > rajani.karut...@citrix.com> wrote:
> > 
> >  Can we move the mysql-connector-java dependency to the parent
> > >>> POM(SOURCE-ROOT/pom.xml) and define it different scopes for each
> > profile?
> > 
> >  ie)
> > 
> > 
> >  
> >  developer
> >    
> >    
> >  mysql
> >  mysql-connector-java
> >  compile
> >    
> >    
> >  
> >  
> >    production
> >    
> >    
> >  mysql
> >  mysql-connector-java
> >  provided
> >    
> >    
> >  
> > 
> >  Thanks,
> >  ~Rajani
> > 
> > 
> > 
> >  On 24-Feb-2014, at 11:41 pm, Hugo Trippaers
> > >>> mailto:trip...@gmail.com>> wrote:
> > 
> >  Indeed,
> > 
> >  I've been fighting with maven all day to get the development profile
> >  to include MySql. No luck yet, will give it another shot tomorrow
> :-)
> > 
> >  Hugo
> > 
> >  Sent from my iPhone
> > 
> >  On 24 feb. 2014, at 18:21, David Nalley
> > >>> mailto:da...@gnsa.us>> wrote:
> > 
> >  So it should be ok to include the jar in non-default builds.
> developer
> >  and deploydb are not what we'd expect a normal user to consume.
> >  (Anyone else's head spinning?)
> > 
> >  --David
> > 
> >  On Mon, Feb 24, 2014 at 11:44 AM, John Kinsella
> > >>> mailto:j...@stratosec.co>> wrote:
> >  I created CLOUDSTACK-6157 over the weekend to track this. Not sure
> > >>> adding the jar after compile will help the deploydb target, but will
> > give it a try
> > >>> this morning.
> > 
> >  Could we set up the pom.xmls to use the jar for execution if it's
> > found in
> > >>> the user/system classpaths while respecting the legal requirements?
> > 
> >  Rayees' suggestion for cloud.spec makes sense for the RPM builds,
> but
> > >>> doesn't affect the developer issues.
> > 
> >  -He who needs more maven experience
> > 
> >  On Feb 24, 2014, at 7:36 AM, Hugo Trippaers
> > >>> mailto:h...@trippaers.nl>> wrot

Re: [PROPOSAL] Windowsfication Of ACS

[Todd Pigram]

Just wondering if it would be easier to just make the management server
into a virtual appliance then recoding everything to run on Windows (not to
mention all the patches every month). The enterprises that I come in
contact with don't seem to have an issue with vCD. I don't know how the
foundation looks at virtual appliances, but maybe that is more of a Citrix
thing on their supported version.

Just a thought.

Todd




On Wed, Feb 26, 2014 at 3:08 AM, Paul Angus wrote:

> I don't know if you guys already know this, but the mounting of sec
> storage on the management server to pass the systemvm.iso is also done when
> using hyper-v as well. So for hyper-v, samba support is required on the
> management server.
>
> Regards
>
> Paul Angus
> Cloud Architect
> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> paul.an...@shapeblue.com
>
> -Original Message-
> From: Kelven Yang [mailto:kelven.y...@citrix.com]
> Sent: 25 February 2014 23:07
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Windowsfication Of ACS
>
> Current way of mounting NFS into management server is the legacy of the
> rushing old days when VMware support was originally built. To get rid of
> NFS mount in management server, we should file it as a feature request
> along with the Windowsfication effort
>
> Kelven
>
> On 2/25/14, 1:54 PM, "Alex Huang"  wrote:
>
> >Damodar,
> >
> >I think you'll find that earlier in the thread I have said that these
> >should not be part of the management server startup but rather the
> >install.  The install scripts for Linux is probably python or shell
> >script based.  The install for windows is an app that can do this work.
> >
> >Other than these, the main problem for you will be the VmWare code that
> >mounts secondary storage to the management server machine.  That's a
> >design flaw in VmWare code that we should rectify.  You can speak to
> >Kelven about how to fix that.
> >
> >--Alex
> >
> >> -Original Message-
> >> From: Damoder Reddy [mailto:damoder.re...@citrix.com]
> >> Sent: Monday, February 24, 2014 9:48 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: [PROPOSAL] Windowsfication Of ACS
> >>
> >> Hi Alex,
> >>
> >>  Apart from agent scripts, there are couple of scripts those gets
> >>executed for  during the management server startup like injecting ssh
> >>keys into  systemvm.iso etc.. Still I am in search of any other
> >>scripts will get called in  management server, though I could not find
> >>any as of now.
> >>
> >> Thanks & Regards
> >> Damodar/
> >>
> >> -Original Message-
> >> From: Alex Huang [mailto:alex.hu...@citrix.com]
> >> Sent: Tuesday, February 25, 2014 10:10 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: [PROPOSAL] Windowsfication Of ACS
> >>
> >> Abhi,
> >>
> >> I think you misunderstood.  I meant that it should not depend on
> >>things later  releases like .net framework.  See the following wiki
> >>page.
> >>
> >> http://en.wikipedia.org/wiki/.NET_Framework#Versions
> >>
> >> I would imagine .net framework 3 or 3.5 would be ideal.  If you use
> >> .net framework 4, then libraries need to be installed and they
> >> sometimes have conflicts with existing apps.
> >>
> >>
> >> As for python or shell scripts, I don't see why we should need any
> >>python  scripts on management server, regardless if it's windows or
> >>Linux.
> >>Python
> >> scripts can be included and executed by agents on Linux systems but I
> >>don't  see a place for them on the management server.  For windows,
> >>specifically,  asking a windows admin to install python is not unlike
> >>asking them to install  Cygwin.
> >>
> >> --Alex
> >>
> >> > -Original Message-
> >> > From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> >> > Sent: Monday, February 24, 2014 8:31 PM
> >> > To: dev@cloudstack.apache.org
> >> > Subject: Re: [PROPOSAL] Windowsfication Of ACS
> >> >
> >> > Yes, that is one of the objective to make MS not dependant on
> >> > cygwin or any other windows tools and utilities. The bash scripts
> >> > are all
> >>converted
> >> to Python.
> >> >
> >> > -abhi
> >> >
> >> >
> >> > On 25/02/14 12:06 am, "Alex Huang"  wrote:
> >> >
> >> > >One additional requirement I have would be don't use any windows
> >> > >components that don't come with the default systems targeted.  I
> >> > >know it sounds great to use the latest and greatest but actually
> >> > >the end users will have to install that and it may mess with their
> >> > >existing setup.  In this proposal, the purely windows parts are
> >> > >fairly basic parts of windows.  Don't bind it to libraries that
> >> > >require installation of additional libraries.
> >> > >
> >> > >--Alex
> >> > >
> >> > >> -Original Message-
> >> > >> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> >> > >> Sent: Friday, February 21, 2014 1:00 AM
> >> > >> To: dev@cloudstack.apache.org
> >> > >> Subject: RE: [PROPOSAL] Windowsfication Of ACS
> >> > >>
> >> > >> I prefer the focus on s

Review Request 18552: Internal LB support for Juniper contrail VPC implementation

[Suresh Balineni]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

Internal LB support for Juniper contrail VPC implementation.

- This implementation just extends the existing implementation of internal lb.
- New element  uses juniper contrail network offering so that nics are 
impelemented by contrail element. 
- LB VM deployment functionality is reused (new element is extended from 
existing Internal LB element implementation).


Diffs
-

  api/src/com/cloud/network/Network.java 6dc6752 
  api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
  plugins/network-elements/juniper-contrail/pom.xml 8c6877d 
  
plugins/network-elements/juniper-contrail/resources/META-INF/cloudstack/contrail/spring-contrail-context.xml
 99ab02e 
  
plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailManagerImpl.java
 01be7db 
  server/src/com/cloud/network/vpc/VpcManagerImpl.java 2157eac 

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


Testing
---

Tested LB VM deployment. Traffic tests are done.


Thanks,

Suresh Balineni

Re: Review Request 18552: Internal LB support for Juniper contrail VPC implementation

[Suresh Balineni]

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

(Updated Feb. 27, 2014, 12:56 a.m.)


Review request for cloudstack.


Changes
---

added a new file (ContrailInternalLbElementImpl).


Repository: cloudstack-git


Description
---

Internal LB support for Juniper contrail VPC implementation.

- This implementation just extends the existing implementation of internal lb.
- New element  uses juniper contrail network offering so that nics are 
impelemented by contrail element. 
- LB VM deployment functionality is reused (new element is extended from 
existing Internal LB element implementation).


Diffs (updated)
-

  api/src/com/cloud/network/Network.java 6dc6752 
  api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
  plugins/network-elements/juniper-contrail/pom.xml 8c6877d 
  
plugins/network-elements/juniper-contrail/resources/META-INF/cloudstack/contrail/spring-contrail-context.xml
 99ab02e 
  
plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailInternalLbElementImpl.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailManagerImpl.java
 01be7db 
  server/src/com/cloud/network/vpc/VpcManagerImpl.java 2157eac 

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


Testing
---

Tested LB VM deployment. Traffic tests are done.


Thanks,

Suresh Balineni

Re: developers and mysql

[John Kinsella]

I’ve merged one of the commits, will get the other two in this evening

On Feb 26, 2014, at 3:59 PM, Mike Tutkowski 
mailto:mike.tutkow...@solidfire.com>> wrote:

Yeah, if we have a 4.3 workaround for this, that would be great. Thanks


On Wed, Feb 26, 2014 at 11:19 AM, Sonal Ojha 
mailto:sonal.o...@sungard.com>> wrote:

I am seeing the issue on 4.3 branch, can someone help me how can that be
made to work ??


On Wed, Feb 26, 2014 at 3:32 AM, Hugo Trippaers 
mailto:trip...@gmail.com>> wrote:

We are already pretty much locked in as all our database scripts are
MySQL
specific. If we want to be neutral we should fix that.

Cheers,

Hugo

Sent from my iPhone

On 25 feb. 2014, at 22:57, David Nalley mailto:da...@gnsa.us>> 
wrote:

git blame showed that it came from the HA/replication work from
Damoder.
I didn't speak up at the time, but I am really reluctant for
mysql-specific features to sneak in and lock us in.

On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang 
mailto:alex.hu...@citrix.com>>
wrote:
Who added the dependency on mysql for framework-db?  We actually
worked
hard to keep that depending on jdbc only.  It should not depend on mysql.
We need to fix that.

--Alex

-Original Message-
From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Tuesday, February 25, 2014 3:34 AM
To: mailto:dev@cloudstack.apache.org>>
Subject: Re: developers and mysql

Heya,

Just pushed a change that will make the database work again. :-)


@Alex. The mysql jar used to be pulled in as a dependency from
framework-
db. As the client target is responsible for building the war file for
the
packages including this in the client pom would also put it in the
war
file and
in the packages.

I think i have an elegant solution, its now included as a dependency
for both
the database deploy and the jetty:run target. Which makes it
effectively a
"provided" library for the purpose of our maven build. See commit
8e6b86ae23dce802044388c5420ff61511d7115b and
e883877c7a6f9df04b572afd4ee5f10d265bcc3a.

I can deploy a database and start the jetty:run target now without
any
trouble (at least not more trouble than usual ;-) )

My next step is to clean up some of the dependencies. I think that
only
cloud-framework-db should have a provided dependency on mysql. It's
the
only piece of source code that actually needs the mysql driver to be
present
during compilation for the optional HA configuration. There are some
test
classes that depend on database functionally but those should be
moved
to
an integration test profile that could include the database driver,
those tests
are disabled anyway so they don't cause any trouble now.


Cheers,

Hugo

On 25 feb. 2014, at 06:39, Rajani Karuturi <
rajani.karut...@citrix.com> wrote:

Can we move the mysql-connector-java dependency to the parent
POM(SOURCE-ROOT/pom.xml) and define it different scopes for each
profile?

ie)



developer
 
 
   mysql
   mysql-connector-java
   compile
 
 


 production
 
 
   mysql
   mysql-connector-java
   provided
 
 


Thanks,
~Rajani



On 24-Feb-2014, at 11:41 pm, Hugo Trippaers
mailto:trip...@gmail.com>> wrote:

Indeed,

I've been fighting with maven all day to get the development profile
to include MySql. No luck yet, will give it another shot tomorrow
:-)

Hugo

Sent from my iPhone

On 24 feb. 2014, at 18:21, David Nalley
mailto:da...@gnsa.us>> wrote:

So it should be ok to include the jar in non-default builds.
developer
and deploydb are not what we'd expect a normal user to consume.
(Anyone else's head spinning?)

--David

On Mon, Feb 24, 2014 at 11:44 AM, John Kinsella
mailto:j...@stratosec.co>> wrote:
I created CLOUDSTACK-6157 over the weekend to track this. Not sure
adding the jar after compile will help the deploydb target, but will
give it a try
this morning.

Could we set up the pom.xmls to use the jar for execution if it's
found in
the user/system classpaths while respecting the legal requirements?

Rayees' suggestion for cloud.spec makes sense for the RPM builds,
but
doesn't affect the developer issues.

-He who needs more maven experience

On Feb 24, 2014, at 7:36 AM, Hugo Trippaers
mailto:h...@trippaers.nl>> wrote:

Heya,

as the mysql dependency is now set to provided in all the poms to
fix
our
license compliancy the jetty target and the deployed targets are not
working.

I'm trying to configure an optional profile to enable those targets
to include
the mysql dependency while executing, but so far no luck. If anyone
has
some bright ideas on how to do this i'm all ears. In the meantime the
best
solutions i've found to continue working is to copy the mysql jar
file
into the
directory client/target/cloud-client-ui-4.4.0-SNAPSHOT/WEB-INF/lib/
by
hand after running mvm install and before running the jetty target
(just don't
run mvn clean).

Hopefully a better solution in 

Re: developers and mysql

[Mike Tutkowski]

Awesome! Thanks, John!


On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella  wrote:

> I've merged one of the commits, will get the other two in this evening
>
> On Feb 26, 2014, at 3:59 PM, Mike Tutkowski  > wrote:
>
> Yeah, if we have a 4.3 workaround for this, that would be great. Thanks
>
>
> On Wed, Feb 26, 2014 at 11:19 AM, Sonal Ojha  > wrote:
>
> I am seeing the issue on 4.3 branch, can someone help me how can that be
> made to work ??
>
>
> On Wed, Feb 26, 2014 at 3:32 AM, Hugo Trippaers  trip...@gmail.com>> wrote:
>
> We are already pretty much locked in as all our database scripts are
> MySQL
> specific. If we want to be neutral we should fix that.
>
> Cheers,
>
> Hugo
>
> Sent from my iPhone
>
> On 25 feb. 2014, at 22:57, David Nalley  da...@gnsa.us>> wrote:
>
> git blame showed that it came from the HA/replication work from
> Damoder.
> I didn't speak up at the time, but I am really reluctant for
> mysql-specific features to sneak in and lock us in.
>
> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang  alex.hu...@citrix.com>>
> wrote:
> Who added the dependency on mysql for framework-db?  We actually
> worked
> hard to keep that depending on jdbc only.  It should not depend on mysql.
> We need to fix that.
>
> --Alex
>
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Tuesday, February 25, 2014 3:34 AM
> To: mailto:dev@cloudstack.apache.org>>
> Subject: Re: developers and mysql
>
> Heya,
>
> Just pushed a change that will make the database work again. :-)
>
>
> @Alex. The mysql jar used to be pulled in as a dependency from
> framework-
> db. As the client target is responsible for building the war file for
> the
> packages including this in the client pom would also put it in the
> war
> file and
> in the packages.
>
> I think i have an elegant solution, its now included as a dependency
> for both
> the database deploy and the jetty:run target. Which makes it
> effectively a
> "provided" library for the purpose of our maven build. See commit
> 8e6b86ae23dce802044388c5420ff61511d7115b and
> e883877c7a6f9df04b572afd4ee5f10d265bcc3a.
>
> I can deploy a database and start the jetty:run target now without
> any
> trouble (at least not more trouble than usual ;-) )
>
> My next step is to clean up some of the dependencies. I think that
> only
> cloud-framework-db should have a provided dependency on mysql. It's
> the
> only piece of source code that actually needs the mysql driver to be
> present
> during compilation for the optional HA configuration. There are some
> test
> classes that depend on database functionally but those should be
> moved
> to
> an integration test profile that could include the database driver,
> those tests
> are disabled anyway so they don't cause any trouble now.
>
>
> Cheers,
>
> Hugo
>
> On 25 feb. 2014, at 06:39, Rajani Karuturi <
> rajani.karut...@citrix.com> wrote:
>
> Can we move the mysql-connector-java dependency to the parent
> POM(SOURCE-ROOT/pom.xml) and define it different scopes for each
> profile?
>
> ie)
>
>
> 
> developer
>  
>  
>mysql
>mysql-connector-java
>compile
>  
>  
> 
> 
>  production
>  
>  
>mysql
>mysql-connector-java
>provided
>  
>  
> 
>
> Thanks,
> ~Rajani
>
>
>
> On 24-Feb-2014, at 11:41 pm, Hugo Trippaers
> mailto:trip...@gmail.com>>
> wrote:
>
> Indeed,
>
> I've been fighting with maven all day to get the development profile
> to include MySql. No luck yet, will give it another shot tomorrow
> :-)
>
> Hugo
>
> Sent from my iPhone
>
> On 24 feb. 2014, at 18:21, David Nalley
> mailto:da...@gnsa.us>> wrote:
>
> So it should be ok to include the jar in non-default builds.
> developer
> and deploydb are not what we'd expect a normal user to consume.
> (Anyone else's head spinning?)
>
> --David
>
> On Mon, Feb 24, 2014 at 11:44 AM, John Kinsella
> mailto:j...@stratosec.co>>
> wrote:
> I created CLOUDSTACK-6157 over the weekend to track this. Not sure
> adding the jar after compile will help the deploydb target, but will
> give it a try
> this morning.
>
> Could we set up the pom.xmls to use the jar for execution if it's
> found in
> the user/system classpaths while respecting the legal requirements?
>
> Rayees' suggestion for cloud.spec makes sense for the RPM builds,
> but
> doesn't affect the developer issues.
>
> -He who needs more maven experience
>
> On Feb 24, 2014, at 7:36 AM, Hugo Trippaers
> mailto:h...@trippaers.nl>>
> wrote:
>
> Heya,
>
> as the mysql dependency is now set to provided in all the poms to
> fix
> our
> license compliancy the jetty target and the deployed targets are not
> working.
>
> I'm trying to configure an optional profile to enable those targets
> to include
> the mysql dependency while executing, but

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Antonio Fornié Casarrubios]

Hi Alena,


2014-02-26 23:19 GMT+01:00 Alena Prokharchyk :

>  Antonio,
>
>  I still don't quite see why false result returned from one of the
> workers, should silently stop other workers if those workers are a)
> independent b) have their own way of processing the failures in
> asynchronous manner later as you stated.
>

If you don't see why to stop the chain then you can just return true. On
the other hand, the Chain of Responsibility Pattern from GoF always has
been implemented in a way the each worker can invoke the next OR NOT. And
again, this is very common in JEE filters, I'm sure you already found
similar examples with JEE filters, right?

Yes, workers are independent. And one worker can be designed to stop the
chain under certain conditions even if this worker doesn't have a clue what
workers come later. Then you decide to put this worker in the chain before,
after or not to put it at all. Just like in CoR pattern from GoF.

On the other hand, removing this flexibility has any benefit? You keep
saying "silently", but not invoking a method that should not be executed is
not something silent. That's because you still see false as "error" and not
as "mission complete".

In general I prefer to choose non restricting choices. Just like I USUALLY
prefer protected members over private ones, because in general I assume if
another developer in the future decides to extend a method she will do it
for reasons... even if I don't see the reasons in advance. I can also make
the method private, but that only causes the developer will change the
method to protected and then extend it when needed, speaking about this...

... I really don't see is this conversation changing our points of view. I
prefer to just return void, if anybody need to change this in the future
they can always do it.



>  You also say "didn't want each worker to have a reference to the next.".
> But in your case you do obey the reference in indirect when failure of one
> worker execution affects the other? I'm confused.
>

Didn't want each worker to have a reference to the next, but not because of
decoupling, just because if WorkerA -> WorkerB then I cannot have a chain
WorkerA -> AnotherWorker unless I create another instance of WorkerA
(because a worker object only has one next). So my point was, better to
create only one instance of each worker given that there will be not
benefit on having each worker referencing the next. I never meant it was
because of encapsulation...

...because of encapsulation we do other things, but not that. We deal with
workers by interface, but this is something you have whether you use list
or wrappers, whether you return void or boolean. Having workers in a chain
make it flexible and modular, but doesn't make imperative that the workers
cannot affect each other or assume anything about others. Your assumptions
in a worker should be documented so it's easy to know how to create the
chain. something like: "This worker stops the chain if we decide to put the
cmd in a queue due to X". You have to keep in mind how they affect each
other in order to decide how to create the chains: that knowledge is the
role of the factory.

And actually the previous code (and many others) are like that: in a
certain block of code sometimes you do something considering the code that
may come later. And actually we do it in the workers: one of the workers
(ParamUnpackWorker) changes the parameter format assuming that next workers
will need the new format instead of the old one. Then it's up to you to
keep workers in order: if you don't put this worker in the first place in
the list then the other workers will fail because the params are not
formatted. Thus this worker knows that the next workers will never get to
the old format params... and that also happened before with the
unpackParams method, although the method itself doesn't know all details
about what will happen with the new format params later.




>
>  As an example, we can look at couple of examples of something similar in
> CloudStack code.
>
>  1) SecurityChecker Adapters. All adapters are invoked on the resource,
> and if something fails, it throws an exception that clearly stops others
> checkers from execution.
>

In Spring Security you can configure several "agents" to decide to
authorize access or not, and you can configure it to work if all the agents
say YES or if AT LEAST ONE says yes. In the latter case, the moment one
gives the YES it does stop the others from doing a check. You can find 20
examples in which you don't need to stop, but if you find a single example
in which you do need it that should be enough. Why to remove the
possibility just because you don't come across a good example? Why to keep
it more restricted instead of more flexible?



>  2) UserAuthenticator Adapter. When user logs in, all adapters defined in
> the config file, get invoked in specific order. If one of them fails
> (RuntimeException is thrown), the login attempt fails as well, an

Re: developers and mysql

[John Kinsella]

I’ve cherry-picked these into 4.3-forward…will ask RM in a separate email to 
pick them into 4.3.

John

On Feb 26, 2014, at 5:26 PM, Mike Tutkowski 
mailto:mike.tutkow...@solidfire.com>> wrote:

Awesome! Thanks, John!


On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella 
mailto:j...@stratosec.co>> wrote:

I've merged one of the commits, will get the other two in this evening

On Feb 26, 2014, at 3:59 PM, Mike Tutkowski 
mailto:mike.tutkow...@solidfire.com>
> wrote:

Yeah, if we have a 4.3 workaround for this, that would be great. Thanks


On Wed, Feb 26, 2014 at 11:19 AM, Sonal Ojha 
mailto:sonal.o...@sungard.com>
> wrote:

I am seeing the issue on 4.3 branch, can someone help me how can that be
made to work ??


On Wed, Feb 26, 2014 at 3:32 AM, Hugo Trippaers 
mailto:trip...@gmail.com>mailto:trip...@gmail.com>>> wrote:

We are already pretty much locked in as all our database scripts are
MySQL
specific. If we want to be neutral we should fix that.

Cheers,

Hugo

Sent from my iPhone

On 25 feb. 2014, at 22:57, David Nalley 
mailto:da...@gnsa.us>mailto:da...@gnsa.us>>> wrote:

git blame showed that it came from the HA/replication work from
Damoder.
I didn't speak up at the time, but I am really reluctant for
mysql-specific features to sneak in and lock us in.

On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang 
mailto:alex.hu...@citrix.com>mailto:alex.hu...@citrix.com>>>
wrote:
Who added the dependency on mysql for framework-db?  We actually
worked
hard to keep that depending on jdbc only.  It should not depend on mysql.
We need to fix that.

--Alex

-Original Message-
From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Tuesday, February 25, 2014 3:34 AM
To: 
mailto:dev@cloudstack.apache.org>>
Subject: Re: developers and mysql

Heya,

Just pushed a change that will make the database work again. :-)


@Alex. The mysql jar used to be pulled in as a dependency from
framework-
db. As the client target is responsible for building the war file for
the
packages including this in the client pom would also put it in the
war
file and
in the packages.

I think i have an elegant solution, its now included as a dependency
for both
the database deploy and the jetty:run target. Which makes it
effectively a
"provided" library for the purpose of our maven build. See commit
8e6b86ae23dce802044388c5420ff61511d7115b and
e883877c7a6f9df04b572afd4ee5f10d265bcc3a.

I can deploy a database and start the jetty:run target now without
any
trouble (at least not more trouble than usual ;-) )

My next step is to clean up some of the dependencies. I think that
only
cloud-framework-db should have a provided dependency on mysql. It's
the
only piece of source code that actually needs the mysql driver to be
present
during compilation for the optional HA configuration. There are some
test
classes that depend on database functionally but those should be
moved
to
an integration test profile that could include the database driver,
those tests
are disabled anyway so they don't cause any trouble now.


Cheers,

Hugo

On 25 feb. 2014, at 06:39, Rajani Karuturi <
rajani.karut...@citrix.com>
 wrote:

Can we move the mysql-connector-java dependency to the parent
POM(SOURCE-ROOT/pom.xml) and define it different scopes for each
profile?

ie)



developer


  mysql
  mysql-connector-java
  compile




production


  mysql
  mysql-connector-java
  provided




Thanks,
~Rajani



On 24-Feb-2014, at 11:41 pm, Hugo Trippaers
mailto:trip...@gmail.com>>
wrote:

Indeed,

I've been fighting with maven all day to get the development profile
to include MySql. No luck yet, will give it another shot tomorrow
:-)

Hugo

Sent from my iPhone

On 24 feb. 2014, at 18:21, David Nalley
mailto:da...@gnsa.us>>
 wrote:

So it should be ok to include the jar in non-default builds.
developer
and deploydb are not what we'd expect a normal user to consume.
(Anyone else's head spinning?)

--David

On Mon, Feb 24, 2014 at 11:44 AM, John Kinsella
mailto:j...@stratosec.co>>
wrote:
I created CLOUDSTACK-6157 over the weekend to track this. Not sure
adding the jar after compile will help the deploydb target, but will
give it a try
this morning.

Could we set up the pom.xmls to use the jar for execution if it's
found in
the user/system classpaths while respecting the legal requirements?

Rayees' suggestion for cloud.spec makes sense for the RPM builds,
but
doesn't affect the developer issues.

-He who needs more maven experience

On Feb 24, 2014, at 7:36 AM, Hugo Trippaers
mailto:h...@trippaers.nl>>
wrote:

Heya,

as the mysql dependency is now set to provided i

[4.3] [Cherry-pick] developer mysql dependencies

[John Kinsella]

Dearest RM - would like the following commits from 4.3-forward picked into 4.3.

To the best of my knowledge they comply with ASF third-party licensing policy 
for build scripts [1].

24dcf2948c2d4cdd98fcda0f766d82f40eee8be1
2c3cd90b5604cde8123968b15ef6c53bad43b5e2
f5aeac845df8b73b1525442461a8a811e61439d0
54db315214f8dd518eaf1f1615d423d9f4129d31

John
1: https://www.apache.org/legal/3party.html#options-build

RE: 4.4 Feature Freeze

[Ram Ganesh]

I share it too. Many developers in the community went out of their way to get a 
cleaner RC and thereby impacting their feature development efforts. We 
shouldn't be penalizing them with this 2 week's feature freeze schedule

Thanks,
RamG

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: 27 February 2014 03:00
> To: dev@cloudstack.apache.org
> Subject: RE: 4.4 Feature Freeze
> 
> Mike I share your opinion most of us have been pretty much on 4.3 until
> now, and pushing out the release seems reasonable. As I called out in earlier
> mail the feature proposal date was not called out for 4.4 and as such giving
> little extra room seems reasonable.
> 
> Animesh
> 
> > -Original Message-
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Wednesday, February 26, 2014 7:29 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: 4.4 Feature Freeze
> >
> > I think we're having this discussion after every release because we're
> > beginning to realize that a four-month release cycle has not been very
> > realistic for us yet.
> >
> > The main issue I encounter is our month-long RC cycle where I spend a
> > bunch of time validating the RC and (during that timeframe) less time
> > developing for the next release as I had initially planned.
> >
> > Perhaps instead of extending the cycle we could consider ways to
> > actually meet the schedule on a consistent basis. That would be fine, as
> well.
> >
> >
> > On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers 
> > wrote:
> >
> > > -1 on postponing the feature freeze. We are having this discussion
> > > after every release, however we agreed to do a 4 month cycle so
> > > let's stick
> > to it.
> > >
> > > If there are important features that are currently being developed
> > > but might not make this cut-off date we should discuss that
> > > separately, but as a point of principle lets stick to the release 
> > > schedule as
> proposed.
> > >
> > >
> > > Cheers,
> > >
> > > Hugo
> > >
> > >
> > > On 26 feb. 2014, at 15:23, Tracy Phillips
> > > 
> > > wrote:
> > >
> > > > +1 to Daan.
> > > >
> > > > Tracy Phillips
> > > > Weberize, Inc.
> > > >
> > > >
> > > > On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland
> > > > > > >wrote:
> > > >
> > > >> -1 for postponing the feature freeze. It will amount to more
> > > >> features in the release. I'd rather shorten the cycle and do more
> > > >> releases then to pack more bugs in a single go.
> > > >>
> > > >> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star 
> > wrote:
> > > >>> +1
> > > >>>
> > > >>>
> > > >>> 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
> > > >> abhinandan.prat...@citrix.com
> > >  :
> > > >>>
> > >  +1 for 4.4 feature freeze on 3/28.
> > > 
> > >  On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
> > >   wrote:
> > > 
> > > >> -Original Message-
> > > >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > >> Sent: 26 February 2014 04:46
> > > >> To: dev@cloudstack.apache.org
> > > >> Subject: Re: 4.4 Feature Freeze
> > > >>
> > > >> I think this is a good idea, Animesh (to push out feature
> > > >> freeze to 3/28).
> > > >
> > > > +1 to move 4.4 feature freeze date to 3/28.
> > > >
> > > > Regards,
> > > > Sateesh
> > > >
> > > >> I also agree we should discuss 4+ month development cycles
> again.
> > > >>
> > > >>
> > > >> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
> > > >> animesh.chaturv...@citrix.com> wrote:
> > > >>
> > > >>> I will start a separate discussion on 4 month cycle or
> > > >>> longer, but wanted to call out one more important date.
> > > >>>
> > > >>> We have a last day for feature proposal date which is
> > > >>> typically a month before feature freeze date. If following
> > > >>> 4.3 schedule + 4
> > > >> month
> > > >>> it would have been 2/14 and we are already past that. Since
> > > >>> it was
> > > >> not
> > > >>> announced for
> > > >>> 4.4 release yet my suggestion would be to keep feature
> > > >>> proposal
> > > >> open
> > > >>> for another week and push all  the dates out by 2 weeks to
> > > >>> give
> > > >> folks
> > > >>> opportunity to finish up their features for new proposals
> > > >>> that are
> > > >> yet
> > > >>> to come out.
> > > >>>
> > > >>> To be clear that would mean pushing out feature freeze to
> > > >>> 3/28 from
> > > >>> 3/14 and all the other dates likewise.
> > > >>>
> > > >>>
> > > >>> Thanks
> > > >>> Animesh
> > > >>>
> > >  -Original Message-
> > >  From: Animesh Chaturvedi
> > >  [mailto:animesh.chaturv...@citrix.com]
> > >  Sent: Tuesday, February 25, 2014 1:05 PM
> > >  To: dev@cloudstack.apache.org
> > >  Subject: RE: 4.4 Feature Freeze
> > > 
> > >  With the experience of 4.2 and 

Re: CloudStack-setup-management

[Yitao Jiang]

​Can you paste logs file here ?​

Thanks,

Yitao


2014-02-27 8:02 GMT+08:00 María Noelia Gil :

> Hi, I installed the CloudStack-setup-management package, after I installed
> the database and have made ​​the necessary settings, but I can not access
> http://localhost:8080/client.
>
> Any solution?
>
> thanks

Re: developers and mysql

[Mike Tutkowski]

Great, John - thanks again!


On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella  wrote:

> I've cherry-picked these into 4.3-forward...will ask RM in a separate email
> to pick them into 4.3.
>
> John
>
> On Feb 26, 2014, at 5:26 PM, Mike Tutkowski  > wrote:
>
> Awesome! Thanks, John!
>
>
> On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella  j...@stratosec.co>> wrote:
>
> I've merged one of the commits, will get the other two in this evening
>
> On Feb 26, 2014, at 3:59 PM, Mike Tutkowski  
> > wrote:
>
> Yeah, if we have a 4.3 workaround for this, that would be great. Thanks
>
>
> On Wed, Feb 26, 2014 at 11:19 AM, Sonal Ojha  
> > wrote:
>
> I am seeing the issue on 4.3 branch, can someone help me how can that be
> made to work ??
>
>
> On Wed, Feb 26, 2014 at 3:32 AM, Hugo Trippaers  trip...@gmail.com> trip...@gmail.com>> wrote:
>
> We are already pretty much locked in as all our database scripts are
> MySQL
> specific. If we want to be neutral we should fix that.
>
> Cheers,
>
> Hugo
>
> Sent from my iPhone
>
> On 25 feb. 2014, at 22:57, David Nalley  da...@gnsa.us> da...@gnsa.us>> wrote:
>
> git blame showed that it came from the HA/replication work from
> Damoder.
> I didn't speak up at the time, but I am really reluctant for
> mysql-specific features to sneak in and lock us in.
>
> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang  alex.hu...@citrix.com> alex.hu...@citrix.com>>
> wrote:
> Who added the dependency on mysql for framework-db?  We actually
> worked
> hard to keep that depending on jdbc only.  It should not depend on mysql.
> We need to fix that.
>
> --Alex
>
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Tuesday, February 25, 2014 3:34 AM
> To: mailto:dev@cloudstack.apache.org> dev@cloudstack.apache.org>>
> Subject: Re: developers and mysql
>
> Heya,
>
> Just pushed a change that will make the database work again. :-)
>
>
> @Alex. The mysql jar used to be pulled in as a dependency from
> framework-
> db. As the client target is responsible for building the war file for
> the
> packages including this in the client pom would also put it in the
> war
> file and
> in the packages.
>
> I think i have an elegant solution, its now included as a dependency
> for both
> the database deploy and the jetty:run target. Which makes it
> effectively a
> "provided" library for the purpose of our maven build. See commit
> 8e6b86ae23dce802044388c5420ff61511d7115b and
> e883877c7a6f9df04b572afd4ee5f10d265bcc3a.
>
> I can deploy a database and start the jetty:run target now without
> any
> trouble (at least not more trouble than usual ;-) )
>
> My next step is to clean up some of the dependencies. I think that
> only
> cloud-framework-db should have a provided dependency on mysql. It's
> the
> only piece of source code that actually needs the mysql driver to be
> present
> during compilation for the optional HA configuration. There are some
> test
> classes that depend on database functionally but those should be
> moved
> to
> an integration test profile that could include the database driver,
> those tests
> are disabled anyway so they don't cause any trouble now.
>
>
> Cheers,
>
> Hugo
>
> On 25 feb. 2014, at 06:39, Rajani Karuturi <
> rajani.karut...@citrix.com rajani.karut...@citrix.com>> wrote:
>
> Can we move the mysql-connector-java dependency to the parent
> POM(SOURCE-ROOT/pom.xml) and define it different scopes for each
> profile?
>
> ie)
>
>
> 
> developer
> 
> 
>   mysql
>   mysql-connector-java
>   compile
> 
> 
> 
> 
> production
> 
> 
>   mysql
>   mysql-connector-java
>   provided
> 
> 
> 
>
> Thanks,
> ~Rajani
>
>
>
> On 24-Feb-2014, at 11:41 pm, Hugo Trippaers
> mailto:trip...@gmail.com> >>
> wrote:
>
> Indeed,
>
> I've been fighting with maven all day to get the development profile
> to include MySql. No luck yet, will give it another shot tomorrow
> :-)
>
> Hugo
>
> Sent from my iPhone
>
> On 24 feb. 2014, at 18:21, David Nalley
> mailto:da...@gnsa.us> da...@gnsa.us>> wrote:
>
> So it should be ok to include the jar in non-default builds.
> developer
> and deploydb are not what we'd expect a normal user to consume.
> (Anyone else's head spinning?)
>
> --David
>
> On Mon, Feb 24, 2014 at 11:44 AM, John Kinsella
> mailto:j...@stratosec.co> >>
> wrote:
> I created CLOUDSTACK-6157 over the weekend to track this. Not sure
> adding the jar after compile will help the deploydb target, but will
> give it a try
> this morning.
>
> Could we set up the pom.xmls to use the jar for execution if it's
> foun

Re: 4.4 Feature Freeze

[John Kinsella]

I don’t see not moving the freeze date as a penalty.  If a feature doesn’t make 
the current deadline, it moves to the next release, which is still a few months 
away. For significant issues, it’s not uncommon for us to allow them in late.

What we have a stronger need for than shifting a date, by several orders of 
magnitude, is understanding why the RC process took so long and what we can do 
in the future to make that not so painful.

For the record I’m +0 on moving the feature freeze date.

John

On Feb 26, 2014, at 7:10 PM, Ram Ganesh  wrote:

> I share it too. Many developers in the community went out of their way to get 
> a cleaner RC and thereby impacting their feature development efforts. We 
> shouldn't be penalizing them with this 2 week's feature freeze schedule
> 
> Thanks,
> RamG
> 
>> -Original Message-
>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> Sent: 27 February 2014 03:00
>> To: dev@cloudstack.apache.org
>> Subject: RE: 4.4 Feature Freeze
>> 
>> Mike I share your opinion most of us have been pretty much on 4.3 until
>> now, and pushing out the release seems reasonable. As I called out in earlier
>> mail the feature proposal date was not called out for 4.4 and as such giving
>> little extra room seems reasonable.
>> 
>> Animesh
>> 
>>> -Original Message-
>>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>>> Sent: Wednesday, February 26, 2014 7:29 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: 4.4 Feature Freeze
>>> 
>>> I think we're having this discussion after every release because we're
>>> beginning to realize that a four-month release cycle has not been very
>>> realistic for us yet.
>>> 
>>> The main issue I encounter is our month-long RC cycle where I spend a
>>> bunch of time validating the RC and (during that timeframe) less time
>>> developing for the next release as I had initially planned.
>>> 
>>> Perhaps instead of extending the cycle we could consider ways to
>>> actually meet the schedule on a consistent basis. That would be fine, as
>> well.
>>> 
>>> 
>>> On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers 
>>> wrote:
>>> 
 -1 on postponing the feature freeze. We are having this discussion
 after every release, however we agreed to do a 4 month cycle so
 let's stick
>>> to it.
 
 If there are important features that are currently being developed
 but might not make this cut-off date we should discuss that
 separately, but as a point of principle lets stick to the release schedule 
 as
>> proposed.
 
 
 Cheers,
 
 Hugo
 
 
 On 26 feb. 2014, at 15:23, Tracy Phillips
 
 wrote:
 
> +1 to Daan.
> 
> Tracy Phillips
> Weberize, Inc.
> 
> 
> On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland
>  wrote:
> 
>> -1 for postponing the feature freeze. It will amount to more
>> features in the release. I'd rather shorten the cycle and do more
>> releases then to pack more bugs in a single go.
>> 
>> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star 
>>> wrote:
>>> +1
>>> 
>>> 
>>> 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
>> abhinandan.prat...@citrix.com
 :
>>> 
 +1 for 4.4 feature freeze on 3/28.
 
 On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
  wrote:
 
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: 26 February 2014 04:46
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>> 
>> I think this is a good idea, Animesh (to push out feature
>> freeze to 3/28).
> 
> +1 to move 4.4 feature freeze date to 3/28.
> 
> Regards,
> Sateesh
> 
>> I also agree we should discuss 4+ month development cycles
>> again.
>> 
>> 
>> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
>> animesh.chaturv...@citrix.com> wrote:
>> 
>>> I will start a separate discussion on 4 month cycle or
>>> longer, but wanted to call out one more important date.
>>> 
>>> We have a last day for feature proposal date which is
>>> typically a month before feature freeze date. If following
>>> 4.3 schedule + 4
>> month
>>> it would have been 2/14 and we are already past that. Since
>>> it was
>> not
>>> announced for
>>> 4.4 release yet my suggestion would be to keep feature
>>> proposal
>> open
>>> for another week and push all  the dates out by 2 weeks to
>>> give
>> folks
>>> opportunity to finish up their features for new proposals
>>> that are
>> yet
>>> to come out.
>>> 
>>> To be clear that would mean pushing out feature freeze to
>>> 3/28 from
>>> 3/14 and all 

RE: 4.4 Feature Freeze

[Sudha Ponnaganti]

+1 to move feature freeze date in this case as 4.3 closure has impact on the 
next release cycle.  There are 14 features targeted  for 4.4 and all of them 
are in open state as of now.  There are only 2 weeks left to close on coding 
and developers would rush to check in the code.   This only results in poor 
quality code. 

Thanks
/sudha

-Original Message-
From: John Kinsella [mailto:j...@stratosec.co] 
Sent: Wednesday, February 26, 2014 7:22 PM
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze

I don't see not moving the freeze date as a penalty.  If a feature doesn't make 
the current deadline, it moves to the next release, which is still a few months 
away. For significant issues, it's not uncommon for us to allow them in late.

What we have a stronger need for than shifting a date, by several orders of 
magnitude, is understanding why the RC process took so long and what we can do 
in the future to make that not so painful.

For the record I'm +0 on moving the feature freeze date.

John

On Feb 26, 2014, at 7:10 PM, Ram Ganesh  wrote:

> I share it too. Many developers in the community went out of their way 
> to get a cleaner RC and thereby impacting their feature development 
> efforts. We shouldn't be penalizing them with this 2 week's feature 
> freeze schedule
> 
> Thanks,
> RamG
> 
>> -Original Message-
>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> Sent: 27 February 2014 03:00
>> To: dev@cloudstack.apache.org
>> Subject: RE: 4.4 Feature Freeze
>> 
>> Mike I share your opinion most of us have been pretty much on 4.3 
>> until now, and pushing out the release seems reasonable. As I called 
>> out in earlier mail the feature proposal date was not called out for 
>> 4.4 and as such giving little extra room seems reasonable.
>> 
>> Animesh
>> 
>>> -Original Message-
>>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>>> Sent: Wednesday, February 26, 2014 7:29 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: 4.4 Feature Freeze
>>> 
>>> I think we're having this discussion after every release because 
>>> we're beginning to realize that a four-month release cycle has not 
>>> been very realistic for us yet.
>>> 
>>> The main issue I encounter is our month-long RC cycle where I spend 
>>> a bunch of time validating the RC and (during that timeframe) less 
>>> time developing for the next release as I had initially planned.
>>> 
>>> Perhaps instead of extending the cycle we could consider ways to 
>>> actually meet the schedule on a consistent basis. That would be 
>>> fine, as
>> well.
>>> 
>>> 
>>> On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers 
>>> wrote:
>>> 
 -1 on postponing the feature freeze. We are having this discussion 
 after every release, however we agreed to do a 4 month cycle so 
 let's stick
>>> to it.
 
 If there are important features that are currently being developed 
 but might not make this cut-off date we should discuss that 
 separately, but as a point of principle lets stick to the release 
 schedule as
>> proposed.
 
 
 Cheers,
 
 Hugo
 
 
 On 26 feb. 2014, at 15:23, Tracy Phillips 
 
 wrote:
 
> +1 to Daan.
> 
> Tracy Phillips
> Weberize, Inc.
> 
> 
> On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland 
>  wrote:
> 
>> -1 for postponing the feature freeze. It will amount to more 
>> features in the release. I'd rather shorten the cycle and do more 
>> releases then to pack more bugs in a single go.
>> 
>> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star 
>>> wrote:
>>> +1
>>> 
>>> 
>>> 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
>> abhinandan.prat...@citrix.com
 :
>>> 
 +1 for 4.4 feature freeze on 3/28.
 
 On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
  wrote:
 
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: 26 February 2014 04:46
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>> 
>> I think this is a good idea, Animesh (to push out feature 
>> freeze to 3/28).
> 
> +1 to move 4.4 feature freeze date to 3/28.
> 
> Regards,
> Sateesh
> 
>> I also agree we should discuss 4+ month development cycles
>> again.
>> 
>> 
>> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi < 
>> animesh.chaturv...@citrix.com> wrote:
>> 
>>> I will start a separate discussion on 4 month cycle or 
>>> longer, but wanted to call out one more important date.
>>> 
>>> We have a last day for feature proposal date which is 
>>> typically a month before feature freeze date. If following
>>> 4.3 schedule + 4
>> month
>>> it would have been 2/14

devcloud - new version (0.4) ready for testing

[chris snow]

There is a new version of devcloud (version 0.4) ready for testing.

See here for more information:
https://github.com/snowch/devcloud/releases/tag/v0.4

It would be great if this release could be tested and any defects
raised on the github project.

The ultimate goal is that this project will replace devcloud2 and that
this project will be committed back into Cloudstack.

RE: 4.4 Feature Freeze

[Ram Ganesh]

I agree on the RC process! Few thoughts from my end

- I see a rush of "request to cherry pick 4.3" requests from 
committers. This may be a burden for an RM. We can simplify it by RM responding 
to the email with "OK to commit" or "Not ok to commit" email response. This 
should free up some time for RM to concentrate on other critical issues
- Between 2 RC cycles we need to have enough time so that other blocker 
bugs are identified and we finalize only these need to be fixed in the next RC 
cycle. What we found is new blocker issues are raised during every RC cycle. 
Also we need to take a hard look at the bug raised during these RC cycle and do 
a reality check if these are actually blocker bugs or can be fixed in one of 
our maintenance builds\cycles 

If my memory serves better during 4.1 release we had an opposite problem 
wherein we though developers moved on with 4.2 release and thereby impacting 
the quality of 4.1 release. I would say we should be flexible with our dates 
but definitely not way off the radar

Thanks,
RamG

> -Original Message-
> From: John Kinsella [mailto:j...@stratosec.co]
> Sent: 27 February 2014 08:52
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
> 
> I don't see not moving the freeze date as a penalty.  If a feature doesn't
> make the current deadline, it moves to the next release, which is still a few
> months away. For significant issues, it's not uncommon for us to allow them
> in late.
> 
> What we have a stronger need for than shifting a date, by several orders of
> magnitude, is understanding why the RC process took so long and what we
> can do in the future to make that not so painful.
> 
> For the record I'm +0 on moving the feature freeze date.
> 
> John
> 
> On Feb 26, 2014, at 7:10 PM, Ram Ganesh  wrote:
> 
> > I share it too. Many developers in the community went out of their way
> > to get a cleaner RC and thereby impacting their feature development
> > efforts. We shouldn't be penalizing them with this 2 week's feature
> > freeze schedule
> >
> > Thanks,
> > RamG
> >
> >> -Original Message-
> >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> >> Sent: 27 February 2014 03:00
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: 4.4 Feature Freeze
> >>
> >> Mike I share your opinion most of us have been pretty much on 4.3
> >> until now, and pushing out the release seems reasonable. As I called
> >> out in earlier mail the feature proposal date was not called out for
> >> 4.4 and as such giving little extra room seems reasonable.
> >>
> >> Animesh
> >>
> >>> -Original Message-
> >>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >>> Sent: Wednesday, February 26, 2014 7:29 AM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: 4.4 Feature Freeze
> >>>
> >>> I think we're having this discussion after every release because
> >>> we're beginning to realize that a four-month release cycle has not
> >>> been very realistic for us yet.
> >>>
> >>> The main issue I encounter is our month-long RC cycle where I spend
> >>> a bunch of time validating the RC and (during that timeframe) less
> >>> time developing for the next release as I had initially planned.
> >>>
> >>> Perhaps instead of extending the cycle we could consider ways to
> >>> actually meet the schedule on a consistent basis. That would be
> >>> fine, as
> >> well.
> >>>
> >>>
> >>> On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers 
> >>> wrote:
> >>>
>  -1 on postponing the feature freeze. We are having this discussion
>  after every release, however we agreed to do a 4 month cycle so
>  let's stick
> >>> to it.
> 
>  If there are important features that are currently being developed
>  but might not make this cut-off date we should discuss that
>  separately, but as a point of principle lets stick to the release
>  schedule as
> >> proposed.
> 
> 
>  Cheers,
> 
>  Hugo
> 
> 
>  On 26 feb. 2014, at 15:23, Tracy Phillips
>  
>  wrote:
> 
> > +1 to Daan.
> >
> > Tracy Phillips
> > Weberize, Inc.
> >
> >
> > On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland
> >  > wrote:
> >
> >> -1 for postponing the feature freeze. It will amount to more
> >> features in the release. I'd rather shorten the cycle and do more
> >> releases then to pack more bugs in a single go.
> >>
> >> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star 
> >>> wrote:
> >>> +1
> >>>
> >>>
> >>> 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
> >> abhinandan.prat...@citrix.com
>  :
> >>>
>  +1 for 4.4 feature freeze on 3/28.
> 
>  On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
>   wrote:
> 
> >> -Original Message-
> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> Sent: 26 February 2014 04:46
> >> To: dev@clo

RE: developers and mysql

[Damoder Reddy]

Hi Alex,

The mysql dependency is on for only " StaticStrategy.java" as mentioned 
by you. And this is not used anywhere in the code base as a compile time 
dependency rather used as a run time dependency in db.properties. this will be 
passed to mysql driver as part of mysql Database URL construction. 

This StaticStrategy.java will become mute if we move out of mysql driver as it 
has only runtime dependency.

Thanks & Regards
Damodar/

-Original Message-
From: Alex Huang 
Sent: Thursday, February 27, 2014 4:13 AM
To: dev@cloudstack.apache.org
Cc: Damoder Reddy
Subject: RE: developers and mysql

@Hugo

The mysql scripts is a legacy of we used to dump the mysql db to create the 
create-schema sql but it is at worst still a runtime dependency.  We should fix 
it but I don't think it's as high a priority as the compile time dependency 
that has been introduced.

@Damoder,

Can you take a look at StaticStrategy.java?  This is the only file that 
requires mysql but I couldn't find anywhere in the code that references this 
class.  I then looked at the bug and wiki and it also doesn't mentioned that 
dependency on mysql has been added.  It doesn't make sense for CloudStack to 
include this automatically.  There are many ways to provide DB HA and 
incorporate it into our code just limits the possibilities.  We can for example 
document this as a way to do it in on the wiki for example but I just don't see 
why we would use code to limit it.

Thanks.

--Alex

> -Original Message-
> From: Hugo Trippaers [mailto:trip...@gmail.com]
> Sent: Tuesday, February 25, 2014 2:02 PM
> To: dev@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: developers and mysql
> 
> We are already pretty much locked in as all our database scripts are 
> MySQL specific. If we want to be neutral we should fix that.
> 
> Cheers,
> 
> Hugo
> 
> Sent from my iPhone
> 
> > On 25 feb. 2014, at 22:57, David Nalley  wrote:
> >
> > git blame showed that it came from the HA/replication work from Damoder.
> > I didn't speak up at the time, but I am really reluctant for 
> > mysql-specific features to sneak in and lock us in.
> >
> >> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang 
> wrote:
> >> Who added the dependency on mysql for framework-db?  We actually
> worked hard to keep that depending on jdbc only.  It should not depend 
> on mysql.  We need to fix that.
> >>
> >> --Alex
> >>
> >>> -Original Message-
> >>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo 
> >>> Trippaers
> >>> Sent: Tuesday, February 25, 2014 3:34 AM
> >>> To: 
> >>> Subject: Re: developers and mysql
> >>>
> >>> Heya,
> >>>
> >>> Just pushed a change that will make the database work again. :-)
> >>>
> >>>
> >>> @Alex. The mysql jar used to be pulled in as a dependency from
> >>> framework- db. As the client target is responsible for building 
> >>> the war file for the packages including this in the client pom 
> >>> would also put it in the war file and in the packages.
> >>>
> >>> I think i have an elegant solution, its now included as a 
> >>> dependency for both the database deploy and the jetty:run target. 
> >>> Which makes it effectively a "provided" library for the purpose of 
> >>> our maven build. See commit 
> >>> 8e6b86ae23dce802044388c5420ff61511d7115b and 
> >>> e883877c7a6f9df04b572afd4ee5f10d265bcc3a.
> >>>
> >>> I can deploy a database and start the jetty:run target now without 
> >>> any trouble (at least not more trouble than usual ;-) )
> >>>
> >>> My next step is to clean up some of the dependencies. I think that 
> >>> only cloud-framework-db should have a provided dependency on mysql.
> >>> It's the only piece of source code that actually needs the mysql 
> >>> driver to be present during compilation for the optional HA 
> >>> configuration. There are some test classes that depend on database 
> >>> functionally but those should be moved to an integration test 
> >>> profile that could include the database driver, those tests are 
> >>> disabled
> anyway so they don't cause any trouble now.
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Hugo
> >>>
>  On 25 feb. 2014, at 06:39, Rajani Karuturi 
>  
> wrote:
> 
>  Can we move the mysql-connector-java dependency to the parent
> >>> POM(SOURCE-ROOT/pom.xml) and define it different scopes for each
> profile?
> 
>  ie)
> 
> 
>  
>  developer
>    
>    
>  mysql
>  mysql-connector-java
>  compile
>    
>    
>  
>  
>    production
>    
>    
>  mysql
>  mysql-connector-java
>  provided
>    
>    
>  
> 
>  Thanks,
>  ~Rajani
> 
> 
> 
>  On 24-Feb-2014, at 11:41 pm, Hugo Trippaers
> >>> mailto:trip...@gmail.com>> wrote:
> 
>  Indeed,
> 
>  I've been fighting with maven all day to get the development 
>  profile to include MySql. No luck y

RE: developers and mysql

[Alex Huang]

Hi Damoder,

I don't think I follow.  There's clearly compile dependency on mysql in 
StaticStrategy. 

To me, when I look at StaticStartegy, it makes sense to move that into separate 
project in github and reference people to it if they want to use the specific 
setup outlined in the DB HA wiki.  That to me would make it a runtime 
dependency only.

--Alex 

> -Original Message-
> From: Damoder Reddy
> Sent: Wednesday, February 26, 2014 9:20 PM
> To: Alex Huang; dev@cloudstack.apache.org
> Subject: RE: developers and mysql
> 
> Hi Alex,
> 
>   The mysql dependency is on for only " StaticStrategy.java" as
> mentioned by you. And this is not used anywhere in the code base as a
> compile time dependency rather used as a run time dependency in
> db.properties. this will be passed to mysql driver as part of mysql Database
> URL construction.
> 
> This StaticStrategy.java will become mute if we move out of mysql driver as it
> has only runtime dependency.
> 
> Thanks & Regards
> Damodar/
> 
> -Original Message-
> From: Alex Huang
> Sent: Thursday, February 27, 2014 4:13 AM
> To: dev@cloudstack.apache.org
> Cc: Damoder Reddy
> Subject: RE: developers and mysql
> 
> @Hugo
> 
> The mysql scripts is a legacy of we used to dump the mysql db to create the
> create-schema sql but it is at worst still a runtime dependency.  We should 
> fix
> it but I don't think it's as high a priority as the compile time dependency 
> that
> has been introduced.
> 
> @Damoder,
> 
> Can you take a look at StaticStrategy.java?  This is the only file that 
> requires
> mysql but I couldn't find anywhere in the code that references this class.  I
> then looked at the bug and wiki and it also doesn't mentioned that
> dependency on mysql has been added.  It doesn't make sense for
> CloudStack to include this automatically.  There are many ways to provide DB
> HA and incorporate it into our code just limits the possibilities.  We can for
> example document this as a way to do it in on the wiki for example but I just
> don't see why we would use code to limit it.
> 
> Thanks.
> 
> --Alex
> 
> > -Original Message-
> > From: Hugo Trippaers [mailto:trip...@gmail.com]
> > Sent: Tuesday, February 25, 2014 2:02 PM
> > To: dev@cloudstack.apache.org
> > Cc: dev@cloudstack.apache.org
> > Subject: Re: developers and mysql
> >
> > We are already pretty much locked in as all our database scripts are
> > MySQL specific. If we want to be neutral we should fix that.
> >
> > Cheers,
> >
> > Hugo
> >
> > Sent from my iPhone
> >
> > > On 25 feb. 2014, at 22:57, David Nalley  wrote:
> > >
> > > git blame showed that it came from the HA/replication work from
> Damoder.
> > > I didn't speak up at the time, but I am really reluctant for
> > > mysql-specific features to sneak in and lock us in.
> > >
> > >> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang 
> > wrote:
> > >> Who added the dependency on mysql for framework-db?  We actually
> > worked hard to keep that depending on jdbc only.  It should not depend
> > on mysql.  We need to fix that.
> > >>
> > >> --Alex
> > >>
> > >>> -Original Message-
> > >>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> > >>> Trippaers
> > >>> Sent: Tuesday, February 25, 2014 3:34 AM
> > >>> To: 
> > >>> Subject: Re: developers and mysql
> > >>>
> > >>> Heya,
> > >>>
> > >>> Just pushed a change that will make the database work again. :-)
> > >>>
> > >>>
> > >>> @Alex. The mysql jar used to be pulled in as a dependency from
> > >>> framework- db. As the client target is responsible for building
> > >>> the war file for the packages including this in the client pom
> > >>> would also put it in the war file and in the packages.
> > >>>
> > >>> I think i have an elegant solution, its now included as a
> > >>> dependency for both the database deploy and the jetty:run target.
> > >>> Which makes it effectively a "provided" library for the purpose of
> > >>> our maven build. See commit
> > >>> 8e6b86ae23dce802044388c5420ff61511d7115b and
> e883877c7a6f9df04b572afd4ee5f10d265bcc3a.
> > >>>
> > >>> I can deploy a database and start the jetty:run target now without
> > >>> any trouble (at least not more trouble than usual ;-) )
> > >>>
> > >>> My next step is to clean up some of the dependencies. I think that
> > >>> only cloud-framework-db should have a provided dependency on
> mysql.
> > >>> It's the only piece of source code that actually needs the mysql
> > >>> driver to be present during compilation for the optional HA
> > >>> configuration. There are some test classes that depend on database
> > >>> functionally but those should be moved to an integration test
> > >>> profile that could include the database driver, those tests are
> > >>> disabled
> > anyway so they don't cause any trouble now.
> > >>>
> > >>>
> > >>> Cheers,
> > >>>
> > >>> Hugo
> > >>>
> >  On 25 feb. 2014, at 06:39, Rajani Karuturi
> >  
> > wrote:
> > 
> >  Can we move the mysql-connector-java dependen

Re: 4.4 Feature Freeze

[Marcus]

Perhaps we just need to reduce overlap. Most people work on 4.3 until
it's out the door, I think. Personally, I have a hard time straddling
the two during this phase.

On Wed, Feb 26, 2014 at 9:08 PM, Ram Ganesh  wrote:
> I agree on the RC process! Few thoughts from my end
>
> - I see a rush of "request to cherry pick 4.3" requests from 
> committers. This may be a burden for an RM. We can simplify it by RM 
> responding to the email with "OK to commit" or "Not ok to commit" email 
> response. This should free up some time for RM to concentrate on other 
> critical issues
> - Between 2 RC cycles we need to have enough time so that other 
> blocker bugs are identified and we finalize only these need to be fixed in 
> the next RC cycle. What we found is new blocker issues are raised during 
> every RC cycle. Also we need to take a hard look at the bug raised during 
> these RC cycle and do a reality check if these are actually blocker bugs or 
> can be fixed in one of our maintenance builds\cycles
>
> If my memory serves better during 4.1 release we had an opposite problem 
> wherein we though developers moved on with 4.2 release and thereby impacting 
> the quality of 4.1 release. I would say we should be flexible with our dates 
> but definitely not way off the radar
>
> Thanks,
> RamG
>
>> -Original Message-
>> From: John Kinsella [mailto:j...@stratosec.co]
>> Sent: 27 February 2014 08:52
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>>
>> I don't see not moving the freeze date as a penalty.  If a feature doesn't
>> make the current deadline, it moves to the next release, which is still a few
>> months away. For significant issues, it's not uncommon for us to allow them
>> in late.
>>
>> What we have a stronger need for than shifting a date, by several orders of
>> magnitude, is understanding why the RC process took so long and what we
>> can do in the future to make that not so painful.
>>
>> For the record I'm +0 on moving the feature freeze date.
>>
>> John
>>
>> On Feb 26, 2014, at 7:10 PM, Ram Ganesh  wrote:
>>
>> > I share it too. Many developers in the community went out of their way
>> > to get a cleaner RC and thereby impacting their feature development
>> > efforts. We shouldn't be penalizing them with this 2 week's feature
>> > freeze schedule
>> >
>> > Thanks,
>> > RamG
>> >
>> >> -Original Message-
>> >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> >> Sent: 27 February 2014 03:00
>> >> To: dev@cloudstack.apache.org
>> >> Subject: RE: 4.4 Feature Freeze
>> >>
>> >> Mike I share your opinion most of us have been pretty much on 4.3
>> >> until now, and pushing out the release seems reasonable. As I called
>> >> out in earlier mail the feature proposal date was not called out for
>> >> 4.4 and as such giving little extra room seems reasonable.
>> >>
>> >> Animesh
>> >>
>> >>> -Original Message-
>> >>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> >>> Sent: Wednesday, February 26, 2014 7:29 AM
>> >>> To: dev@cloudstack.apache.org
>> >>> Subject: Re: 4.4 Feature Freeze
>> >>>
>> >>> I think we're having this discussion after every release because
>> >>> we're beginning to realize that a four-month release cycle has not
>> >>> been very realistic for us yet.
>> >>>
>> >>> The main issue I encounter is our month-long RC cycle where I spend
>> >>> a bunch of time validating the RC and (during that timeframe) less
>> >>> time developing for the next release as I had initially planned.
>> >>>
>> >>> Perhaps instead of extending the cycle we could consider ways to
>> >>> actually meet the schedule on a consistent basis. That would be
>> >>> fine, as
>> >> well.
>> >>>
>> >>>
>> >>> On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers 
>> >>> wrote:
>> >>>
>>  -1 on postponing the feature freeze. We are having this discussion
>>  after every release, however we agreed to do a 4 month cycle so
>>  let's stick
>> >>> to it.
>> 
>>  If there are important features that are currently being developed
>>  but might not make this cut-off date we should discuss that
>>  separately, but as a point of principle lets stick to the release
>>  schedule as
>> >> proposed.
>> 
>> 
>>  Cheers,
>> 
>>  Hugo
>> 
>> 
>>  On 26 feb. 2014, at 15:23, Tracy Phillips
>>  
>>  wrote:
>> 
>> > +1 to Daan.
>> >
>> > Tracy Phillips
>> > Weberize, Inc.
>> >
>> >
>> > On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland
>> > > > wrote:
>> >
>> >> -1 for postponing the feature freeze. It will amount to more
>> >> features in the release. I'd rather shorten the cycle and do more
>> >> releases then to pack more bugs in a single go.
>> >>
>> >> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star 
>> >>> wrote:
>> >>> +1
>> >>>
>> >>>
>> >>> 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
>> >> abhinandan.pr

Re: developers and mysql

[Abhinandan Prateek]

StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part
of the mysql jdbc driver providing a specific strategy that works as per
the documented HA procedure.

I think moving it to a separate github project that generates the
additional mysql connector jar should be ok (any licensing issues).
We can then document that anyone configuring DB-HA as per the suggested
procedure should download this and add it to the classpath.

-abhi


On 27/02/14 10:54 am, "Alex Huang"  wrote:

>Hi Damoder,
>
>I don't think I follow.  There's clearly compile dependency on mysql in
>StaticStrategy. 
>
>To me, when I look at StaticStartegy, it makes sense to move that into
>separate project in github and reference people to it if they want to use
>the specific setup outlined in the DB HA wiki.  That to me would make it
>a runtime dependency only.
>
>--Alex 
>
>> -Original Message-
>> From: Damoder Reddy
>> Sent: Wednesday, February 26, 2014 9:20 PM
>> To: Alex Huang; dev@cloudstack.apache.org
>> Subject: RE: developers and mysql
>> 
>> Hi Alex,
>> 
>>  The mysql dependency is on for only " StaticStrategy.java" as
>> mentioned by you. And this is not used anywhere in the code base as a
>> compile time dependency rather used as a run time dependency in
>> db.properties. this will be passed to mysql driver as part of mysql
>>Database
>> URL construction.
>> 
>> This StaticStrategy.java will become mute if we move out of mysql
>>driver as it
>> has only runtime dependency.
>> 
>> Thanks & Regards
>> Damodar/
>> 
>> -Original Message-
>> From: Alex Huang
>> Sent: Thursday, February 27, 2014 4:13 AM
>> To: dev@cloudstack.apache.org
>> Cc: Damoder Reddy
>> Subject: RE: developers and mysql
>> 
>> @Hugo
>> 
>> The mysql scripts is a legacy of we used to dump the mysql db to create
>>the
>> create-schema sql but it is at worst still a runtime dependency.  We
>>should fix
>> it but I don't think it's as high a priority as the compile time
>>dependency that
>> has been introduced.
>> 
>> @Damoder,
>> 
>> Can you take a look at StaticStrategy.java?  This is the only file that
>>requires
>> mysql but I couldn't find anywhere in the code that references this
>>class.  I
>> then looked at the bug and wiki and it also doesn't mentioned that
>> dependency on mysql has been added.  It doesn't make sense for
>> CloudStack to include this automatically.  There are many ways to
>>provide DB
>> HA and incorporate it into our code just limits the possibilities.  We
>>can for
>> example document this as a way to do it in on the wiki for example but
>>I just
>> don't see why we would use code to limit it.
>> 
>> Thanks.
>> 
>> --Alex
>> 
>> > -Original Message-
>> > From: Hugo Trippaers [mailto:trip...@gmail.com]
>> > Sent: Tuesday, February 25, 2014 2:02 PM
>> > To: dev@cloudstack.apache.org
>> > Cc: dev@cloudstack.apache.org
>> > Subject: Re: developers and mysql
>> >
>> > We are already pretty much locked in as all our database scripts are
>> > MySQL specific. If we want to be neutral we should fix that.
>> >
>> > Cheers,
>> >
>> > Hugo
>> >
>> > Sent from my iPhone
>> >
>> > > On 25 feb. 2014, at 22:57, David Nalley  wrote:
>> > >
>> > > git blame showed that it came from the HA/replication work from
>> Damoder.
>> > > I didn't speak up at the time, but I am really reluctant for
>> > > mysql-specific features to sneak in and lock us in.
>> > >
>> > >> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang 
>> > wrote:
>> > >> Who added the dependency on mysql for framework-db?  We actually
>> > worked hard to keep that depending on jdbc only.  It should not depend
>> > on mysql.  We need to fix that.
>> > >>
>> > >> --Alex
>> > >>
>> > >>> -Original Message-
>> > >>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
>> > >>> Trippaers
>> > >>> Sent: Tuesday, February 25, 2014 3:34 AM
>> > >>> To: 
>> > >>> Subject: Re: developers and mysql
>> > >>>
>> > >>> Heya,
>> > >>>
>> > >>> Just pushed a change that will make the database work again. :-)
>> > >>>
>> > >>>
>> > >>> @Alex. The mysql jar used to be pulled in as a dependency from
>> > >>> framework- db. As the client target is responsible for building
>> > >>> the war file for the packages including this in the client pom
>> > >>> would also put it in the war file and in the packages.
>> > >>>
>> > >>> I think i have an elegant solution, its now included as a
>> > >>> dependency for both the database deploy and the jetty:run target.
>> > >>> Which makes it effectively a "provided" library for the purpose of
>> > >>> our maven build. See commit
>> > >>> 8e6b86ae23dce802044388c5420ff61511d7115b and
>> e883877c7a6f9df04b572afd4ee5f10d265bcc3a.
>> > >>>
>> > >>> I can deploy a database and start the jetty:run target now without
>> > >>> any trouble (at least not more trouble than usual ;-) )
>> > >>>
>> > >>> My next step is to clean up some of the dependencies. I think that
>> > >>> only cloud-framework-db should have a provided dependency on
>> my

RE: 4.4 Feature Freeze

[Raja Pullela]

+1 for the 3/28 Feature Freeze.
If we try to close on the Feature Freeze sooner than when we are ready, we will 
end up finding more blockers/criticals and end up spending more time on bug 
fixing.  This could potentially result in moving the RC?
So, bottom line - it is like we pay now or pay later!

-Original Message-
From: Marcus [mailto:shadow...@gmail.com] 
Sent: Thursday, February 27, 2014 10:54 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze

Perhaps we just need to reduce overlap. Most people work on 4.3 until it's out 
the door, I think. Personally, I have a hard time straddling the two during 
this phase.

On Wed, Feb 26, 2014 at 9:08 PM, Ram Ganesh  wrote:
> I agree on the RC process! Few thoughts from my end
>
> - I see a rush of "request to cherry pick 4.3" requests from 
> committers. This may be a burden for an RM. We can simplify it by RM 
> responding to the email with "OK to commit" or "Not ok to commit" email 
> response. This should free up some time for RM to concentrate on other 
> critical issues
> - Between 2 RC cycles we need to have enough time so that 
> other blocker bugs are identified and we finalize only these need to 
> be fixed in the next RC cycle. What we found is new blocker issues are 
> raised during every RC cycle. Also we need to take a hard look at the 
> bug raised during these RC cycle and do a reality check if these are 
> actually blocker bugs or can be fixed in one of our maintenance 
> builds\cycles
>
> If my memory serves better during 4.1 release we had an opposite 
> problem wherein we though developers moved on with 4.2 release and 
> thereby impacting the quality of 4.1 release. I would say we should be 
> flexible with our dates but definitely not way off the radar
>
> Thanks,
> RamG
>
>> -Original Message-
>> From: John Kinsella [mailto:j...@stratosec.co]
>> Sent: 27 February 2014 08:52
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>>
>> I don't see not moving the freeze date as a penalty.  If a feature 
>> doesn't make the current deadline, it moves to the next release, 
>> which is still a few months away. For significant issues, it's not 
>> uncommon for us to allow them in late.
>>
>> What we have a stronger need for than shifting a date, by several 
>> orders of magnitude, is understanding why the RC process took so long 
>> and what we can do in the future to make that not so painful.
>>
>> For the record I'm +0 on moving the feature freeze date.
>>
>> John
>>
>> On Feb 26, 2014, at 7:10 PM, Ram Ganesh  wrote:
>>
>> > I share it too. Many developers in the community went out of their 
>> > way to get a cleaner RC and thereby impacting their feature 
>> > development efforts. We shouldn't be penalizing them with this 2 
>> > week's feature freeze schedule
>> >
>> > Thanks,
>> > RamG
>> >
>> >> -Original Message-
>> >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> >> Sent: 27 February 2014 03:00
>> >> To: dev@cloudstack.apache.org
>> >> Subject: RE: 4.4 Feature Freeze
>> >>
>> >> Mike I share your opinion most of us have been pretty much on 4.3 
>> >> until now, and pushing out the release seems reasonable. As I 
>> >> called out in earlier mail the feature proposal date was not 
>> >> called out for
>> >> 4.4 and as such giving little extra room seems reasonable.
>> >>
>> >> Animesh
>> >>
>> >>> -Original Message-
>> >>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> >>> Sent: Wednesday, February 26, 2014 7:29 AM
>> >>> To: dev@cloudstack.apache.org
>> >>> Subject: Re: 4.4 Feature Freeze
>> >>>
>> >>> I think we're having this discussion after every release because 
>> >>> we're beginning to realize that a four-month release cycle has 
>> >>> not been very realistic for us yet.
>> >>>
>> >>> The main issue I encounter is our month-long RC cycle where I 
>> >>> spend a bunch of time validating the RC and (during that 
>> >>> timeframe) less time developing for the next release as I had initially 
>> >>> planned.
>> >>>
>> >>> Perhaps instead of extending the cycle we could consider ways to 
>> >>> actually meet the schedule on a consistent basis. That would be 
>> >>> fine, as
>> >> well.
>> >>>
>> >>>
>> >>> On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers 
>> >>> 
>> >>> wrote:
>> >>>
>>  -1 on postponing the feature freeze. We are having this 
>>  discussion after every release, however we agreed to do a 4 
>>  month cycle so let's stick
>> >>> to it.
>> 
>>  If there are important features that are currently being 
>>  developed but might not make this cut-off date we should discuss 
>>  that separately, but as a point of principle lets stick to the 
>>  release schedule as
>> >> proposed.
>> 
>> 
>>  Cheers,
>> 
>>  Hugo
>> 
>> 
>>  On 26 feb. 2014, at 15:23, Tracy Phillips 
>>  
>>  wrote:
>> 
>> > +1 to Daan.
>> >
>> > Tracy Phillips
>> 

Re: developers and mysql

[Abhinandan Prateek]

Immediately if there are no specific licensing issues we should maintain
the status-quo.
The fact is that some other HA solutions will not work as all the schema
related scripts are mysql engine specific.

When we decide to move the mysql dependency out of cloudstack we should do
it for all such dependencies.
If there is an agreement here we can file a ticket to track this.

-abhi


On 27/02/14 11:16 am, "Abhinandan Prateek" 
wrote:

>StaticStrategy is overriding the Mysql¹s HA Strategy. So it is more a part
>of the mysql jdbc driver providing a specific strategy that works as per
>the documented HA procedure.
>
>I think moving it to a separate github project that generates the
>additional mysql connector jar should be ok (any licensing issues).
>We can then document that anyone configuring DB-HA as per the suggested
>procedure should download this and add it to the classpath.
>
>-abhi
>
>
>On 27/02/14 10:54 am, "Alex Huang"  wrote:
>
>>Hi Damoder,
>>
>>I don't think I follow.  There's clearly compile dependency on mysql in
>>StaticStrategy. 
>>
>>To me, when I look at StaticStartegy, it makes sense to move that into
>>separate project in github and reference people to it if they want to use
>>the specific setup outlined in the DB HA wiki.  That to me would make it
>>a runtime dependency only.
>>
>>--Alex 
>>
>>> -Original Message-
>>> From: Damoder Reddy
>>> Sent: Wednesday, February 26, 2014 9:20 PM
>>> To: Alex Huang; dev@cloudstack.apache.org
>>> Subject: RE: developers and mysql
>>> 
>>> Hi Alex,
>>> 
>>> The mysql dependency is on for only " StaticStrategy.java" as
>>> mentioned by you. And this is not used anywhere in the code base as a
>>> compile time dependency rather used as a run time dependency in
>>> db.properties. this will be passed to mysql driver as part of mysql
>>>Database
>>> URL construction.
>>> 
>>> This StaticStrategy.java will become mute if we move out of mysql
>>>driver as it
>>> has only runtime dependency.
>>> 
>>> Thanks & Regards
>>> Damodar/
>>> 
>>> -Original Message-
>>> From: Alex Huang
>>> Sent: Thursday, February 27, 2014 4:13 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Damoder Reddy
>>> Subject: RE: developers and mysql
>>> 
>>> @Hugo
>>> 
>>> The mysql scripts is a legacy of we used to dump the mysql db to create
>>>the
>>> create-schema sql but it is at worst still a runtime dependency.  We
>>>should fix
>>> it but I don't think it's as high a priority as the compile time
>>>dependency that
>>> has been introduced.
>>> 
>>> @Damoder,
>>> 
>>> Can you take a look at StaticStrategy.java?  This is the only file that
>>>requires
>>> mysql but I couldn't find anywhere in the code that references this
>>>class.  I
>>> then looked at the bug and wiki and it also doesn't mentioned that
>>> dependency on mysql has been added.  It doesn't make sense for
>>> CloudStack to include this automatically.  There are many ways to
>>>provide DB
>>> HA and incorporate it into our code just limits the possibilities.  We
>>>can for
>>> example document this as a way to do it in on the wiki for example but
>>>I just
>>> don't see why we would use code to limit it.
>>> 
>>> Thanks.
>>> 
>>> --Alex
>>> 
>>> > -Original Message-
>>> > From: Hugo Trippaers [mailto:trip...@gmail.com]
>>> > Sent: Tuesday, February 25, 2014 2:02 PM
>>> > To: dev@cloudstack.apache.org
>>> > Cc: dev@cloudstack.apache.org
>>> > Subject: Re: developers and mysql
>>> >
>>> > We are already pretty much locked in as all our database scripts are
>>> > MySQL specific. If we want to be neutral we should fix that.
>>> >
>>> > Cheers,
>>> >
>>> > Hugo
>>> >
>>> > Sent from my iPhone
>>> >
>>> > > On 25 feb. 2014, at 22:57, David Nalley  wrote:
>>> > >
>>> > > git blame showed that it came from the HA/replication work from
>>> Damoder.
>>> > > I didn't speak up at the time, but I am really reluctant for
>>> > > mysql-specific features to sneak in and lock us in.
>>> > >
>>> > >> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang
>>>
>>> > wrote:
>>> > >> Who added the dependency on mysql for framework-db?  We actually
>>> > worked hard to keep that depending on jdbc only.  It should not
>>>depend
>>> > on mysql.  We need to fix that.
>>> > >>
>>> > >> --Alex
>>> > >>
>>> > >>> -Original Message-
>>> > >>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
>>> > >>> Trippaers
>>> > >>> Sent: Tuesday, February 25, 2014 3:34 AM
>>> > >>> To: 
>>> > >>> Subject: Re: developers and mysql
>>> > >>>
>>> > >>> Heya,
>>> > >>>
>>> > >>> Just pushed a change that will make the database work again. :-)
>>> > >>>
>>> > >>>
>>> > >>> @Alex. The mysql jar used to be pulled in as a dependency from
>>> > >>> framework- db. As the client target is responsible for building
>>> > >>> the war file for the packages including this in the client pom
>>> > >>> would also put it in the war file and in the packages.
>>> > >>>
>>> > >>> I think i have an elegant solution, its now included as a
>>> > >>> dependency

Looking for test folks on the community!

[Raja Pullela]

Hi,

Can you please respond if you are actively involved or looking get involved in 
testing 4.4 Release?

Thanks,
Raja

Re: developers and mysql

[Mike Tutkowski]

Hey John,

I'm just getting around now to trying to rebuild my CS environment using
the new changes in 4.3-forward.

When I run the following:

mvn -P developer -pl developer -Ddeploydb

I receive the following error:

> Running query: drop database if exists `cloud`

SQL exception in trying initDB:
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications
link failure

I ran mvn -P deps before deploying the DB just to be sure.

To build the system in the first place, I ran the following after fetching
the latest:

mvn -P developer,systemvm clean install

Any thoughts on this?

Thanks!


On Wed, Feb 26, 2014 at 8:22 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Great, John - thanks again!
>
>
> On Wed, Feb 26, 2014 at 7:10 PM, John Kinsella  wrote:
>
>> I've cherry-picked these into 4.3-forward...will ask RM in a separate email
>> to pick them into 4.3.
>>
>> John
>>
>> On Feb 26, 2014, at 5:26 PM, Mike Tutkowski > > wrote:
>>
>> Awesome! Thanks, John!
>>
>>
>> On Wed, Feb 26, 2014 at 6:12 PM, John Kinsella > j...@stratosec.co>> wrote:
>>
>> I've merged one of the commits, will get the other two in this evening
>>
>> On Feb 26, 2014, at 3:59 PM, Mike Tutkowski > 
>> > wrote:
>>
>> Yeah, if we have a 4.3 workaround for this, that would be great. Thanks
>>
>>
>> On Wed, Feb 26, 2014 at 11:19 AM, Sonal Ojha > 
>> > wrote:
>>
>> I am seeing the issue on 4.3 branch, can someone help me how can that be
>> made to work ??
>>
>>
>> On Wed, Feb 26, 2014 at 3:32 AM, Hugo Trippaers > > trip...@gmail.com>> wrote:
>>
>> We are already pretty much locked in as all our database scripts are
>> MySQL
>> specific. If we want to be neutral we should fix that.
>>
>> Cheers,
>>
>> Hugo
>>
>> Sent from my iPhone
>>
>> On 25 feb. 2014, at 22:57, David Nalley > da...@gnsa.us>> da...@gnsa.us>> wrote:
>>
>> git blame showed that it came from the HA/replication work from
>> Damoder.
>> I didn't speak up at the time, but I am really reluctant for
>> mysql-specific features to sneak in and lock us in.
>>
>> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang > > alex.hu...@citrix.com>>
>> wrote:
>> Who added the dependency on mysql for framework-db?  We actually
>> worked
>> hard to keep that depending on jdbc only.  It should not depend on mysql.
>> We need to fix that.
>>
>> --Alex
>>
>> -Original Message-
>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
>> Sent: Tuesday, February 25, 2014 3:34 AM
>> To: mailto:dev@cloudstack.apache.org>> dev@cloudstack.apache.org>>
>> Subject: Re: developers and mysql
>>
>> Heya,
>>
>> Just pushed a change that will make the database work again. :-)
>>
>>
>> @Alex. The mysql jar used to be pulled in as a dependency from
>> framework-
>> db. As the client target is responsible for building the war file for
>> the
>> packages including this in the client pom would also put it in the
>> war
>> file and
>> in the packages.
>>
>> I think i have an elegant solution, its now included as a dependency
>> for both
>> the database deploy and the jetty:run target. Which makes it
>> effectively a
>> "provided" library for the purpose of our maven build. See commit
>> 8e6b86ae23dce802044388c5420ff61511d7115b and
>> e883877c7a6f9df04b572afd4ee5f10d265bcc3a.
>>
>> I can deploy a database and start the jetty:run target now without
>> any
>> trouble (at least not more trouble than usual ;-) )
>>
>> My next step is to clean up some of the dependencies. I think that
>> only
>> cloud-framework-db should have a provided dependency on mysql. It's
>> the
>> only piece of source code that actually needs the mysql driver to be
>> present
>> during compilation for the optional HA configuration. There are some
>> test
>> classes that depend on database functionally but those should be
>> moved
>> to
>> an integration test profile that could include the database driver,
>> those tests
>> are disabled anyway so they don't cause any trouble now.
>>
>>
>> Cheers,
>>
>> Hugo
>>
>> On 25 feb. 2014, at 06:39, Rajani Karuturi <
>> rajani.karut...@citrix.com> rajani.karut...@citrix.com>> wrote:
>>
>> Can we move the mysql-connector-java dependency to the parent
>> POM(SOURCE-ROOT/pom.xml) and define it different scopes for each
>> profile?
>>
>> ie)
>>
>>
>> 
>> developer
>> 
>> 
>>   mysql
>>   mysql-connector-java
>>   compile
>> 
>> 
>> 
>> 
>> production
>> 
>> 
>>   mysql
>>   mysql-connector-java
>>   provided
>> 
>> 
>> 
>>
>> Thanks,
>> ~Rajani
>>
>>
>>
>> On 24-Feb-2014, at 11:41 pm, Hugo Trippaers
>> mailto:trip...@gmail.com>> >>
>> wr

RE: Looking for test folks on the community!

[Wilder Rodrigues]

I'm in!

Cheers,
Wilder

-Original Message-
From: Raja Pullela [mailto:raja.pull...@citrix.com] 
Sent: Thursday, February 27, 2014 7:01 AM
To: CloudStack Dev (dev@cloudstack.apache.org)
Subject: Looking for test folks on the community!

Hi,

Can you please respond if you are actively involved or looking get involved in 
testing 4.4 Release?

Thanks,
Raja

Fwd: Unable to deploy vm

[Tejas Gadaria]

Hi,
thanks for replay,

Is there any workaround for this ?
OR
how can I update 4.0.2 to 4.1.0 ?

Regards,
Tejas


On Wed, Feb 26, 2014 at 2:55 PM, Sailaja Mada wrote:

> Hi,
>
> Error log seems to be same as the bug @
> https://issues.apache.org/jira/browse/CLOUDSTACK-1403 - This got fixed in
> 4.1.0 .
>
> Thanks,
> Sailaja.M
>
>
> -Original Message-
> From: Tejas Gadaria [mailto:refond.g...@gmail.com]
> Sent: 26 February 2014 13:21
> To: us...@cloudstack.apache.org
> Subject: Unable to deploy vm
>
> Hi,
>
> I am using CS 4.0.3 with vmware hypervisor.
>
> SSVM and CPVM is running both public and private IP are pinging from
> management server.
>
> while trying to deploy vm from template, it.s giving ,
>
> 2014-02-26 12:50:18,182 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-418:10.129.150.22) Unable to find template base snapshot,
> invalid template
> 2014-02-26 12:50:18,182 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-418:10.129.150.22) CreateCommand failed due to Exception:
> java.lang.Exception
> Message: Unable to find template base snapshot, invalid template
>
> java.lang.Exception: Unable to find template base snapshot, invalid
> template
> at
>
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3756)
> at
>
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:335)
> at
>
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:191)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2014-02-26 12:50:18,183 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-486:null) Seq 28-1947012159: Response Received:
> 2014-02-26 12:50:18,183 DEBUG [agent.transport.Request]
> (StatsCollector-1:null) Seq 28-1947012159: Received:  { Ans: , MgmtId:
> 345051457089, via: 28, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
> 2014-02-26 12:50:18,183 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-418:null) Seq 28-1947012160: Response Received:
> 2014-02-26 12:50:18,183 DEBUG [agent.transport.Request]
> (DirectAgent-418:null) Seq 28-1947012160: Processing:  { Ans: , MgmtId:
> 345051457089, via: 28, Ver: v1, Flags: 110,
>
> [{"storage.CreateAnswer":{"requestTemplateReload":false,"result":false,"details":"Exception:
> java.lang.Exception\nMessage: java.lang.Exception: Unable to find template
> base snapshot, invalid template\nStack: java.lang.Exception:
> java.lang.Exception: Unable to find template base snapshot, invalid
> template\n\tat
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3833)\n\tat
>
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:335)\n\tat
>
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:191)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)\n\tat
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:166)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat
> java.lang.Thread.run(Thread.java:679)\nCaused by: java.lang.Exception:
> Unable to find template base snapshot, invalid template\n\tat
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3756)\n\t...
> 10 more\n","wait":0}}] }
> 2014-02-26 12:50:18,183 DEBUG [agent.manager.AgentAttache]
> (DirectAgent-418:null) Seq 28-1947012160: No more commands found
> 2014-02-26 12:50:18,183 DEBUG [agent.transport.Request]
> (Job-Executor-5:job-97) Seq 28-1947012160: Received:  { Ans: , MgmtId:
> 345051457089, via: 28, Ver: v1, Flags: 110, { CreateAnswer } }
> 2014-02-26 12:50:18,183 DEBUG [cloud.storage.StorageManagerImpl]
> (Job-Executor-5:job-97) Unable to create volume Vol[628|vm=531|ROOT]
> 2014-02-26 12:50:18,222 INFO  [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-5:job-97) Unable to contact resource.
> com.cloud.exception.StorageUnavailableException: Reso

RE: Unable to deploy vm

[Sanjeev Neelarapu]

Please follow the instructions given at : [1] to upgrade from 4.0.x to 4.1.0:

[1]: 
http://svn.apache.org/repos/asf/cloudstack/docsite/html/docs/en-US/Apache_CloudStack/4.1.0/html/Release_Notes/upgrade-instructions.html#upgrade-from-4.0-to-4.1

Thanks,
Sanjeev
-Original Message-
From: Tejas Gadaria [mailto:refond.g...@gmail.com] 
Sent: Thursday, February 27, 2014 11:48 AM
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: Fwd: Unable to deploy vm

Hi,
thanks for replay,

Is there any workaround for this ?
OR
how can I update 4.0.2 to 4.1.0 ?

Regards,
Tejas


On Wed, Feb 26, 2014 at 2:55 PM, Sailaja Mada wrote:

> Hi,
>
> Error log seems to be same as the bug @
> https://issues.apache.org/jira/browse/CLOUDSTACK-1403 - This got fixed 
> in
> 4.1.0 .
>
> Thanks,
> Sailaja.M
>
>
> -Original Message-
> From: Tejas Gadaria [mailto:refond.g...@gmail.com]
> Sent: 26 February 2014 13:21
> To: us...@cloudstack.apache.org
> Subject: Unable to deploy vm
>
> Hi,
>
> I am using CS 4.0.3 with vmware hypervisor.
>
> SSVM and CPVM is running both public and private IP are pinging from 
> management server.
>
> while trying to deploy vm from template, it.s giving ,
>
> 2014-02-26 12:50:18,182 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-418:10.129.150.22) Unable to find template base snapshot, 
> invalid template
> 2014-02-26 12:50:18,182 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-418:10.129.150.22) CreateCommand failed due to Exception:
> java.lang.Exception
> Message: Unable to find template base snapshot, invalid template
>
> java.lang.Exception: Unable to find template base snapshot, invalid 
> template
> at
>
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3756)
> at
>
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:335)
> at
>
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:191)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2014-02-26 12:50:18,183 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-486:null) Seq 28-1947012159: Response Received:
> 2014-02-26 12:50:18,183 DEBUG [agent.transport.Request]
> (StatsCollector-1:null) Seq 28-1947012159: Received:  { Ans: , MgmtId:
> 345051457089, via: 28, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
> 2014-02-26 12:50:18,183 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-418:null) Seq 28-1947012160: Response Received:
> 2014-02-26 12:50:18,183 DEBUG [agent.transport.Request]
> (DirectAgent-418:null) Seq 28-1947012160: Processing:  { Ans: , MgmtId:
> 345051457089, via: 28, Ver: v1, Flags: 110,
>
> [{"storage.CreateAnswer":{"requestTemplateReload":false,"result":false,"details":"Exception:
> java.lang.Exception\nMessage: java.lang.Exception: Unable to find 
> template base snapshot, invalid template\nStack: java.lang.Exception:
> java.lang.Exception: Unable to find template base snapshot, invalid 
> template\n\tat 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareReso
> urce.java:3833)\n\tat
>
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(Vmw
> areResource.java:335)\n\tat
>
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache
> .java:191)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471
> )\n\tat 
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n\t
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.a
> ccess$101(ScheduledThreadPoolExecutor.java:165)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.r
> un(ScheduledThreadPoolExecutor.java:266)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1110)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:603)\n\tat java.lang.Thread.run(Thread.java:679)\nCaused by: 
> java.lang.Exception:
> Unable to find template base snapshot, invalid template\n\tat 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3756)\n\t...
> 10 more\n","wait":0}}] }
> 2014-02-26 12:50:18,183 DEBUG [agent.manager.AgentAttache]
> (DirectAgent-418:null) Seq 28-1947012160: No more commands fou

Not able to ping to outside network from system VMs

[Jitendra Shelar]

Hi All,

I am setting up a 2-node cloudstack environment.

Management Server :10.44.189.125
Host Server :  10.44.65.143

I am able to see the system VMs in running state.
But not able ping to outside network from system VMs.

I am not able to ping to corporate DNS or Google DNS from system VMs.
Also not able to ping gateway from system VMs.

Health Check :
root@s-20-VM:/usr/local/cloud/systemvm# ./ssvm-check.sh

First DNS server is  8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 10.44.188.14: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst Data
4  5  00 5400    0 0040  40  01 5f64 10.44.188.14  8.8.8.8
64 bytes from 10.44.188.14: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst Data
4  5  00 5400    0 0040  40  01 5f64 10.44.188.14  8.8.8.8
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
WARNING: cannot ping DNS server
route follows
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
8.8.8.8 10.44.188.3 255.255.255.255 UGH   0  00 eth1
10.44.188.0 0.0.0.0 255.255.254.0   U 0  00 eth1
10.44.188.0 0.0.0.0 255.255.254.0   U 0  00 eth2
10.44.188.0 0.0.0.0 255.255.254.0   U 0  00 eth3
169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
0.0.0.0 10.44.188.3 0.0.0.0 UG0  00 eth2

ERROR: DNS not resolving download.cloud.com
resolv.conf follows
nameserver 8.8.8.8
nameserver 8.8.8.8
root@s-20-VM:/usr/local/cloud/systemvm#


Route information on system VM :

root@s-20-VM:/usr/local/cloud/systemvm# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
8.8.8.8 10.44.188.3 255.255.255.255 UGH   0  00 eth1
10.44.188.0 0.0.0.0 255.255.254.0   U 0  00 eth1
10.44.188.0 0.0.0.0 255.255.254.0   U 0  00 eth2
10.44.188.0 0.0.0.0 255.255.254.0   U 0  00 eth3
169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
0.0.0.0 10.44.188.3 0.0.0.0 UG0  00 eth2
root@s-20-VM:/usr/local/cloud/systemvm#


Please help me in getting out of this issue.

Thanks,
Jitendra






DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Persistent Systems Ltd. It is intended only for the use of the 
individual or entity to which it is addressed. If you are not the intended 
recipient, you are not authorized to read, retain, copy, print, distribute or 
use this message. If you have received this communication in error, please 
notify the sender and delete all copies of this message. Persistent Systems 
Ltd. does not accept any liability for virus infected mails.

Re: Looking for test folks on the community!

[Hugo Trippaers]

Certainly :-)


On 27 feb. 2014, at 07:00, Raja Pullela  wrote:

> Hi,
> 
> Can you please respond if you are actively involved or looking get involved 
> in testing 4.4 Release?
> 
> Thanks,
> Raja
> 

Re: developers and mysql

[Hugo Trippaers]

Hey,

StaticStrategy is an optional component, so it should be perfectly OK to 
include it at compile time in our source code. If i understand the apache rules 
correctly we can keep it in the code base without problems as long as it is 
optional. We should however move it to a separate project inside cloudstack 
source and build it using a separate profile (or the noredist).

Can Apache projects rely on components whose licensing affects the Apache 
product?
Apache projects cannot distribute any such components. However, if the 
component is only needed for optional features, a project can provide the user 
with instructions on how to obtain and install the non-included work. Optional 
means that the component is not required for standard use of the product or for 
the product to achieve a desirable level of quality. The question to ask 
yourself in this situation is:

• "Will the majority of users want to use my product without adding the 
optional components?"

— source http://www.apache.org/legal/resolved.html


Cheers,

Hugo



On 27 feb. 2014, at 06:24, Alex Huang  wrote:

> Hi Damoder,
> 
> I don't think I follow.  There's clearly compile dependency on mysql in 
> StaticStrategy. 
> 
> To me, when I look at StaticStartegy, it makes sense to move that into 
> separate project in github and reference people to it if they want to use the 
> specific setup outlined in the DB HA wiki.  That to me would make it a 
> runtime dependency only.
> 
> --Alex 
> 
>> -Original Message-
>> From: Damoder Reddy
>> Sent: Wednesday, February 26, 2014 9:20 PM
>> To: Alex Huang; dev@cloudstack.apache.org
>> Subject: RE: developers and mysql
>> 
>> Hi Alex,
>> 
>>  The mysql dependency is on for only " StaticStrategy.java" as
>> mentioned by you. And this is not used anywhere in the code base as a
>> compile time dependency rather used as a run time dependency in
>> db.properties. this will be passed to mysql driver as part of mysql Database
>> URL construction.
>> 
>> This StaticStrategy.java will become mute if we move out of mysql driver as 
>> it
>> has only runtime dependency.
>> 
>> Thanks & Regards
>> Damodar/
>> 
>> -Original Message-
>> From: Alex Huang
>> Sent: Thursday, February 27, 2014 4:13 AM
>> To: dev@cloudstack.apache.org
>> Cc: Damoder Reddy
>> Subject: RE: developers and mysql
>> 
>> @Hugo
>> 
>> The mysql scripts is a legacy of we used to dump the mysql db to create the
>> create-schema sql but it is at worst still a runtime dependency.  We should 
>> fix
>> it but I don't think it's as high a priority as the compile time dependency 
>> that
>> has been introduced.
>> 
>> @Damoder,
>> 
>> Can you take a look at StaticStrategy.java?  This is the only file that 
>> requires
>> mysql but I couldn't find anywhere in the code that references this class.  I
>> then looked at the bug and wiki and it also doesn't mentioned that
>> dependency on mysql has been added.  It doesn't make sense for
>> CloudStack to include this automatically.  There are many ways to provide DB
>> HA and incorporate it into our code just limits the possibilities.  We can 
>> for
>> example document this as a way to do it in on the wiki for example but I just
>> don't see why we would use code to limit it.
>> 
>> Thanks.
>> 
>> --Alex
>> 
>>> -Original Message-
>>> From: Hugo Trippaers [mailto:trip...@gmail.com]
>>> Sent: Tuesday, February 25, 2014 2:02 PM
>>> To: dev@cloudstack.apache.org
>>> Cc: dev@cloudstack.apache.org
>>> Subject: Re: developers and mysql
>>> 
>>> We are already pretty much locked in as all our database scripts are
>>> MySQL specific. If we want to be neutral we should fix that.
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> Sent from my iPhone
>>> 
 On 25 feb. 2014, at 22:57, David Nalley  wrote:
 
 git blame showed that it came from the HA/replication work from
>> Damoder.
 I didn't speak up at the time, but I am really reluctant for
 mysql-specific features to sneak in and lock us in.
 
> On Tue, Feb 25, 2014 at 4:44 PM, Alex Huang 
>>> wrote:
> Who added the dependency on mysql for framework-db?  We actually
>>> worked hard to keep that depending on jdbc only.  It should not depend
>>> on mysql.  We need to fix that.
> 
> --Alex
> 
>> -Original Message-
>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
>> Trippaers
>> Sent: Tuesday, February 25, 2014 3:34 AM
>> To: 
>> Subject: Re: developers and mysql
>> 
>> Heya,
>> 
>> Just pushed a change that will make the database work again. :-)
>> 
>> 
>> @Alex. The mysql jar used to be pulled in as a dependency from
>> framework- db. As the client target is responsible for building
>> the war file for the packages including this in the client pom
>> would also put it in the war file and in the packages.
>> 
>> I think i have an elegant solution, its now included as a
>> dependency for both the databa

[DISCUSS] Top & Sampling Rates (kvm.resource.LibvirtComputingResource)

[Marty Sweet]

Hi Guys,

Does anyone have any ideas about this?
My main concern is the KVM resource collector and I assume the other
hypervisor setups are receiving the wrong values.

The CSAgent periodically runs the following command:
 [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-2:null) Executing: /bin/bash -c idle=$(top -b -n
1|grep Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle

===
When running top manually I get the same results (2 secs after each command):
==
root@aurora:/var/log/cloudstack/agent# top -b -n1 | grep Cpu
Cpu(s):  6.3%us,  1.0%sy,  0.0%ni, 92.4%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
root@aurora:/var/log/cloudstack/agent# top -b -n1 | grep Cpu
Cpu(s):  6.3%us,  1.0%sy,  0.0%ni, 92.4%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
root@aurora:/var/log/cloudstack/agent# top -b -n1 | grep Cpu
Cpu(s):  6.3%us,  1.0%sy,  0.0%ni, 92.4%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
root@aurora:/var/log/cloudstack/agent# top -b -n2 | grep Cpu
Cpu(s):  6.3%us,  1.0%sy,  0.0%ni, 92.4%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu(s): 29.2%us,  1.1%sy,  0.0%ni, 69.1%id,  0.5%wa,  0.0%hi,  0.1%si,  0.0%st
===
Apparently this is because:
"This is because top, vmstat, iostat all in their first run collect
data since the last reboot time of the system.
And the successive iterations run on the sampling period that you
specify. So, in the first run of top, you will see the %idle time
because from the time of reboot to the time of running top, it was
that much % idle. But in next iterations, since it is busy it doesn't
show any %idle.
Exclude the first iteration and try sampling over the interval you want."
http://serverfault.com/questions/436446/top-showing-64-idle-on-first-screen-or-batch-run-while-there-is-no-idle-time-a


Wouldn't this result in Cloudstack-Agent getting the wrong idle value
for the system?

This hasn't been fixed in 4.3.0, so I will create a patch along the
following lines (if others agree):
/bin/bash -c idle=$(top -d0.10 -b -n 2|grep Cpu\(s\):|tail -n1|cut -d%
-f4|cut -d, -f2;echo $idle
-> Where top -d0.10, changes the refresh interval so the command is
faster to complete.
-> tail -n1, get's the last line of the output (the latest idle value)
===


Let me know what you think,
Regards,
Marty


-- Forwarded message --
From: Marty Sweet 
Date: Sun, Feb 23, 2014 at 1:20 PM
Subject: Segfault: Top & Sampling Rates (kvm.resource.LibvirtComputingResource)
To: "dev@cloudstack.apache.org" 
Cc: "us...@cloudstack.apache.org" 


Hi,

I have just noticed the occasional following error messages in kern.log.
This is happening on all but 1 of my nodes. Is anyone else
experiencing this issue?
=
Feb 23 06:53:24 aurora kernel: [10185338.400091] top[27631]: segfault
at 0 ip 7f025eba3315 sp 7fff3f9ed308 error 4 in
libc-2.15.so[7f025ea6f000+1b5000]
=

I happened to have one of the nodes in trace mode, showing
cloudstack-agent is starting it:

/var/log/cloudstack/agent/agent.log
==
2014-02-23 06:53:23,654 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-1:null) Executing: /bin/bash -c idle=$(top -b -n
1|grep Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
2014-02-23 06:53:23,661 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-2:null) Executing: /bin/bash -c idle=$(top -b -n
1|grep Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
==

## This lead me on to find the following (potential) bug:

When running this manually I get the same result (2 secs before each command):
==
root@aurora:/var/log/cloudstack/agent# top -b -n1 | grep Cpu
Cpu(s):  6.3%us,  1.0%sy,  0.0%ni, 92.4%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
root@aurora:/var/log/cloudstack/agent# top -b -n1 | grep Cpu
Cpu(s):  6.3%us,  1.0%sy,  0.0%ni, 92.4%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
root@aurora:/var/log/cloudstack/agent# top -b -n1 | grep Cpu
Cpu(s):  6.3%us,  1.0%sy,  0.0%ni, 92.4%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
root@aurora:/var/log/cloudstack/agent# top -b -n2 | grep Cpu
Cpu(s):  6.3%us,  1.0%sy,  0.0%ni, 92.4%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu(s): 29.2%us,  1.1%sy,  0.0%ni, 69.1%id,  0.5%wa,  0.0%hi,  0.1%si,  0.0%st
===
Apparently this is because:
"This is because top, vmstat, iostat all in their first run collect
data since the last reboot time of the system.
And the successive iterations run on the sampling period that you
specify. So, in the first run of top, you will see the %idle time
because from the time of reboot to the time of running top, it was
that much % idle. But in next iterations, since it is busy it doesn't
show any %idle.
Exclude the first iteration and try sampling over the interval you want."
http://serverfault.com/questions/436446/top-showing-64-idle-on-first-screen-or-batch-run-while-there-is-no-idle-time-a


Wouldn't this result in Cloudstack-Agent getting the wrong idle value
for the system?

If this hasn't been fixed in 4.3.0, I will create a patch along the
following lines (if others agree):
/bin/bash -c idle=$(to