RE: Review Request 27017: CLOUDSTACK-6282: Added newly automated tests and also modified some existing tests to remove dependency

2014-11-27 Thread Vinay Vegesna
Hi Santhosh,

Alex has reviewed below review request and marked it as “Ship it”, so can you 
please assign it to appropriate person to get it committed.

Thanks,
Vinay

From: Alex Brett [mailto:nore...@reviews.apache.org] On Behalf Of Alex Brett
Sent: Monday, November 24, 2014 9:45 PM
To: Alex Brett; Santhosh Edukulla
Cc: Vinay Vegesna; cloudstack
Subject: Re: Review Request 27017: CLOUDSTACK-6282: Added newly automated tests 
and also modified some existing tests to remove dependency

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



Ship it!

Ship It!


- Alex Brett


On November 3rd, 2014, 6:19 a.m. UTC, Vinay Varma wrote:
Review request for cloudstack, Alex Brett and Santhosh Edukulla.
By Vinay Varma.

Updated Nov. 3, 2014, 6:19 a.m.
Bugs: CLOUDSTACK-6282
Repository: cloudstack-git
Description

CLOUDSTACK-6282: Added newly automated tests and also modified some existing 
tests to remove dependency


Testing

Attached are the results files for each of the file modified and the results 
shows everything is fine


Diffs

  *   test/integration/component/test_escalations_instances.py (1aaa688)
  *   test/integration/component/test_escalations_snapshots.py (4b6b7f5)
  *   test/integration/component/test_escalations_templates.py (78028bc)
  *   test/integration/component/test_escalations_volumes.py (7290325)
  *   test/integration/component/test_escalations_vpncustomergateways.py 
(b09930a)
  *   tools/marvin/marvin/cloudstackTestClient.py (ce7ffc9)
  *   tools/marvin/marvin/lib/base.py (77faeeb)
  *   tools/marvin/marvin/lib/utils.py (b58b59d)

View Diff

File Attachments
•  
Instancesresults.txt
•  
Snapshotsresults.txt
•  
Templatesresults.txt
•  
Voumesresults.txt
•  
VPNCustomerGatewaysresults.txt




Re: [DISCUSS] LTS Releases

2014-11-27 Thread Andrija Panic
my 2 cents again:

Whether we have this LTS release or not - is not just about having release
- we need a WAY to focus here on FIXING, POLISHING product and more
important to stimulate/make developers interested in doing so.
If this was company owned product, it would be very easy to set goals, and
then speak to devs, fix this, fix that.

Since this is ofcourse comunity based product - we need some way of
focusing on fixing the stuff, and really stop adding features (maybe not
completely quit adding features, but...)

One important note, and possible scenario - just by having LTS release, but
still having majority of developer working on non-LTS release (ading new
features) is a big probability, and then we are back to zero with our
progress, so I guess this is also an option/problem that we need to
consider.

I have a very nice experience with CloudStack so far (in general, except
being frustrated by some childish problems) - if this was all polished, and
documentation complete - I'm 100% sure there will be no better cloud
project on the market any time soon, and I really mean it !

It is my wish (and I hope of others) to see CloudStack migrate from
#CloudstackWorks to #CloudStackRocks for the next CCC and I think this is
VERY much possible.



On 26 November 2014 at 22:40, Pierre-Luc Dion  wrote:

> I'm not really in favor of LTS support, it's a good idea, but not sure it
> can be backed by the community?[open question here ;)]. I don't think it
> fit in our current model for few reasons:
>
> - Upgrade path might become impossible as patches become part of multiple
> versions. We could end up with problem at database schema with the current
> db upgrade model.
>
> - Enforcing user to stay on a legacy ACS release disallow usage of future
> hypervisor version, Guest OSes and new hardware used by hypervisors. As
> hypervisors will become out of date, they won't be able to support new
> Guest OSes and new hardware.
>
> - I think the initiative would dilute the effort on the upgrade path and
> making sure the upgrade path is easy and always work. Since 4.3.1 as been
> released after 4.4.0, do we know if a 4.3.1 can be upgrade to 4.4.1 or
> event 4.5?
>
> - Contribution to ACS and bugfixing become nightmare  as bugfix might end
> up in 4 branches (4.3, 4.4, 4.5, master,...)
>
> Why not as community (let's face it, not very a big one) we all focus on
> the next 4.5 version, make sure it's properly tested, make sure upgrade
> "just work"  and have ACS 4 as the LTS ? ;-)
>
> I know a production system is not likely to run the latest version of ACS
> and upgrade of such a prod tool can occur maybe one or two time a year.
>
> That's just my opinion on the subject, nothing against anyone or to block
> the idea.
>
>
>
> On Tue, Nov 25, 2014 at 11:35 AM, Hugo Trippaers 
> wrote:
>
> > Top posting here as my remarks are mainly on the original topic.
> >
> > I’m not in favor of supporting LTS releases as a community. The reasoning
> > here is that there is a huge chance that we will fragment the community
> in
> > people that just want to work on the latest and greatest and some other
> > folks who are trying to keep older releases from being updated with newer
> > fixes. It requires a lot of dedicated commitment to keep an LTS release
> > going. Particularly if you yourself are already working with a newer
> > release in your environment. So from a personal standpoint i can almost
> > guarantee that i will probably not spend the time and effort of back
> > porting any fixes i do to older versions of CloudStack.
> >
> > That doesn’t mean that it can’t happen. If people are willing to take
> > charge of an LTS branch and are willing to do the work to back port fixes
> > where appropriate i would happily support them and even try to test the
> > releases so we can have an official release.
> >
> > New developers might also be scared by the fact that a fix they make has
> > to be supported on multiple branches and might decide not to commit such
> a
> > fix because of the work involved. With the rate of change in the code at
> > the moment this is also very hard for seasoned developers, so much
> little,
> > but important stuff changes all the time that back porting is very
> > difficult. It is an open source project and generally people will want to
> > focus on the latest and greatest and just get their features in. I’m
> > already regularly having some trouble back porting between master and
> 4.5.
> > Consider back porting to master, 4.5 and 4.3 as well and having to test
> > each branch.
> >
> > Basically my point is, everyone who wants to LTS support a certain branch
> > is free to do so. Whether or not other contributors or committers will
> want
> > to do that is their choice. As a community we should not make any
> promises
> > about LTS support for a certain branch.
> >
> > Cheers,
> >
> > Hugo
> >
> >
> >
> >
> >
> > > On 25 nov. 2014, at 16:16, Rohit Yadav 
> > wrote:
> > >
> > > Hey Daan,
> > >
> > >> On 25-No

RE: CloudStack Job offering @exoscale

2014-11-27 Thread Giles Sirett

But being such a small community right now, I think its great to see Exoscale 
creating developer roles around Cloudstack and agree, right now, that this is 
the most sensible place to post them  - really good news Antoine.
At the same time its worth mentioning that ShapeBlue have a number of 
Cloudstack dev & Engineering positions open
Shapeblue.com/careers
And, yes, Interoute are also hiring Cloudstack people

As the jobs market around Cloudstack is clearly developing (what a fantastic 
sign),  long-term, nobody wants to see our dev list getting spammed by  
recruiters, etc - but I also do think it is useful for people in our community 
to see that, if they want, they can develop their careers around ACS
May I suggest that we encourage people going forward to use the various 
Cloudstack linkedin groups for these sort of subjects - that would keep these 
out of the dev list

Thoughts ?


Kind Regards
Giles

D: +44 20 3603 0541 | M: +44 796 111 2055
giles.sir...@shapeblue.com




-Original Message-
From: sebgoa [mailto:run...@gmail.com]
Sent: 27 November 2014 07:58
To: dev@cloudstack.apache.org
Subject: Fwd: CloudStack Job offering @exoscale

I think this is legitimate on dev@

Note that there are also jobs available at interoute.

Begin forwarded message:

> From: "Coetsier, Antoine" 
> Subject: CloudStack Job offering @exoscale
> Date: November 26, 2014 5:20:57 PM GMT+01:00
> To: "us...@cloudstack.apache.org" 
> Reply-To: us...@cloudstack.apache.org
>
> Hello All,
>
> We are looking for a developer that already has some knowledge of CloudStack 
> to join our team at Exoscale. Trendy topics about network 
> functions/distributed LB in CS for this full time job.
>
> This is based in Switzerland of course. The job description is here:
> https://www.exoscale.ch/jobs/ Get in touch with us at: hr -AT-
> exoscale.ch
>
> Thank you,
> --
> Antoine COETSIER – EXOSCALE CEO

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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 SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.


Re: [DISCUSS] LTS Releases

2014-11-27 Thread sebgoa

On Nov 27, 2014, at 9:01 AM, Andrija Panic  wrote:

> my 2 cents again:
> 
> Whether we have this LTS release or not - is not just about having release
> - we need a WAY to focus here on FIXING, POLISHING product and more
> important to stimulate/make developers interested in doing so.
> If this was company owned product, it would be very easy to set goals, and
> then speak to devs, fix this, fix that.
> 
> Since this is ofcourse comunity based product - we need some way of
> focusing on fixing the stuff, and really stop adding features (maybe not
> completely quit adding features, but...)
> 
> One important note, and possible scenario - just by having LTS release, but
> still having majority of developer working on non-LTS release (ading new
> features) is a big probability, and then we are back to zero with our
> progress, so I guess this is also an option/problem that we need to
> consider.
> 
> I have a very nice experience with CloudStack so far (in general, except
> being frustrated by some childish problems) - if this was all polished, and
> documentation complete - I'm 100% sure there will be no better cloud
> project on the market any time soon, and I really mean it !
> 
> It is my wish (and I hope of others) to see CloudStack migrate from
> #CloudstackWorks to #CloudStackRocks for the next CCC and I think this is
> VERY much possible.
> 

Thanks for this Andrija, it made my morning :)

I am of the opinion that if/when we improve our committing habits, we will have 
high confidence that every bug fixed in a release branch will also be fixed in 
the next release.

Little process changing that we are making, like using github PR, merging back 
to master etc, will help us get into somewhat of a rolling release. 

If we take great care with our upgrade paths and avoid regressions then LTS 
becomes less important. We have had some challenges with 4.4 and the fact that 
4.3 is solid makes it natural to want to keep 4.3 alive and patched.

I don't use cloudstack in production so I will differ to those who do on this.

What we do need is higher involvement of users in testing and voting on the 
releases early.

-Sebastien

> 
> 
> On 26 November 2014 at 22:40, Pierre-Luc Dion  wrote:
> 
>> I'm not really in favor of LTS support, it's a good idea, but not sure it
>> can be backed by the community?[open question here ;)]. I don't think it
>> fit in our current model for few reasons:
>> 
>> - Upgrade path might become impossible as patches become part of multiple
>> versions. We could end up with problem at database schema with the current
>> db upgrade model.
>> 
>> - Enforcing user to stay on a legacy ACS release disallow usage of future
>> hypervisor version, Guest OSes and new hardware used by hypervisors. As
>> hypervisors will become out of date, they won't be able to support new
>> Guest OSes and new hardware.
>> 
>> - I think the initiative would dilute the effort on the upgrade path and
>> making sure the upgrade path is easy and always work. Since 4.3.1 as been
>> released after 4.4.0, do we know if a 4.3.1 can be upgrade to 4.4.1 or
>> event 4.5?
>> 
>> - Contribution to ACS and bugfixing become nightmare  as bugfix might end
>> up in 4 branches (4.3, 4.4, 4.5, master,...)
>> 
>> Why not as community (let's face it, not very a big one) we all focus on
>> the next 4.5 version, make sure it's properly tested, make sure upgrade
>> "just work"  and have ACS 4 as the LTS ? ;-)
>> 
>> I know a production system is not likely to run the latest version of ACS
>> and upgrade of such a prod tool can occur maybe one or two time a year.
>> 
>> That's just my opinion on the subject, nothing against anyone or to block
>> the idea.
>> 
>> 
>> 
>> On Tue, Nov 25, 2014 at 11:35 AM, Hugo Trippaers 
>> wrote:
>> 
>>> Top posting here as my remarks are mainly on the original topic.
>>> 
>>> I’m not in favor of supporting LTS releases as a community. The reasoning
>>> here is that there is a huge chance that we will fragment the community
>> in
>>> people that just want to work on the latest and greatest and some other
>>> folks who are trying to keep older releases from being updated with newer
>>> fixes. It requires a lot of dedicated commitment to keep an LTS release
>>> going. Particularly if you yourself are already working with a newer
>>> release in your environment. So from a personal standpoint i can almost
>>> guarantee that i will probably not spend the time and effort of back
>>> porting any fixes i do to older versions of CloudStack.
>>> 
>>> That doesn’t mean that it can’t happen. If people are willing to take
>>> charge of an LTS branch and are willing to do the work to back port fixes
>>> where appropriate i would happily support them and even try to test the
>>> releases so we can have an official release.
>>> 
>>> New developers might also be scared by the fact that a fix they make has
>>> to be supported on multiple branches and might decide not to commit such
>> a
>>> fix because of the work invol

Re: CloudStack Job offering @exoscale

2014-11-27 Thread Nux!
I don't mind seeing job offers from "good guy" companies like Exoscale who are 
active in the community and contribute back, especially at this moment in time 
when this kind of thing is a rarity so to say. 

If the volume of postings increases it will become annoying and linkedin or 
some other places may be better suited, but that'd still be a nice problem to 
have.

A very good sign indeed, as Giles say! And also quite interesting to see such 
interest for ACS in Europe.

Let's not forget Wido is also looking for Cloudstack people at PCExtreme.

Seems like a good time to be an ACS developer! 

It's time to learn Java! :-)


My 2 pence,

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Giles Sirett" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, 27 November, 2014 08:46:07
> Subject: RE: CloudStack Job offering @exoscale

> But being such a small community right now, I think its great to see Exoscale
> creating developer roles around Cloudstack and agree, right now, that this is
> the most sensible place to post them  - really good news Antoine.
> At the same time its worth mentioning that ShapeBlue have a number of 
> Cloudstack
> dev & Engineering positions open
> Shapeblue.com/careers
> And, yes, Interoute are also hiring Cloudstack people
> 
> As the jobs market around Cloudstack is clearly developing (what a fantastic
> sign),  long-term, nobody wants to see our dev list getting spammed by
> recruiters, etc - but I also do think it is useful for people in our community
> to see that, if they want, they can develop their careers around ACS
> May I suggest that we encourage people going forward to use the various
> Cloudstack linkedin groups for these sort of subjects - that would keep these
> out of the dev list
> 
> Thoughts ?
> 
> 
> Kind Regards
> Giles
> 
> D: +44 20 3603 0541 | M: +44 796 111 2055
> giles.sir...@shapeblue.com
> 
> 
> 
> 
> -Original Message-
> From: sebgoa [mailto:run...@gmail.com]
> Sent: 27 November 2014 07:58
> To: dev@cloudstack.apache.org
> Subject: Fwd: CloudStack Job offering @exoscale
> 
> I think this is legitimate on dev@
> 
> Note that there are also jobs available at interoute.
> 
> Begin forwarded message:
> 
>> From: "Coetsier, Antoine" 
>> Subject: CloudStack Job offering @exoscale
>> Date: November 26, 2014 5:20:57 PM GMT+01:00
>> To: "us...@cloudstack.apache.org" 
>> Reply-To: us...@cloudstack.apache.org
>>
>> Hello All,
>>
>> We are looking for a developer that already has some knowledge of CloudStack 
>> to
>> join our team at Exoscale. Trendy topics about network functions/distributed 
>> LB
>> in CS for this full time job.
>>
>> This is based in Switzerland of course. The job description is here:
>> https://www.exoscale.ch/jobs/ Get in touch with us at: hr -AT-
>> exoscale.ch
>>
>> Thank you,
>> --
>> Antoine COETSIER – EXOSCALE CEO
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software
> Engineering
> CloudStack Infrastructure
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> 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 SA Pty Ltd is a company registered by
> The Republic of South Africa and is traded under license from Shape Blue Ltd.
> ShapeBlue is a registered trademark.


Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Harikrishna Patnala

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

(Updated Nov. 27, 2014, 9:22 a.m.)


Review request for cloudstack, Jayapal Reddy, Kishan Kavala, and Rajani 
Karuturi.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-6075: Increase the ram size for router service offering 
Increased the ram size of Internal load balancer vm service offering also


Diffs (updated)
-

  engine/schema/src/com/cloud/upgrade/dao/Upgrade442to450.java dc1057f 
  
plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java
 803d3a5 
  server/src/com/cloud/configuration/Config.java cd0824e 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 
9fb47fd 
  setup/db/db/schema-442to450.sql 107f10c 

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


Testing
---

tested locally


Thanks,

Harikrishna Patnala



Differences in schema-442to450.sql between 4.5 and master

2014-11-27 Thread Hugo Trippaers
See this diff:
Hugos-MacBook-Pro-7:cloudstack hugo (master)$ git diff master 4.5 
setup/db/db/schema-442to450.sql
diff --git a/setup/db/db/schema-442to450.sql b/setup/db/db/schema-442to450.sql
index f84bca6..083943b 100644
--- a/setup/db/db/schema-442to450.sql
+++ b/setup/db/db/schema-442to450.sql
@@ -753,8 +753,6 @@ INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, 
category_id, display_name, crea
 INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
created) VALUES (247, UUID(), 3, 'Oracle Linux 7', utc_timestamp());
 INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
created) VALUES (248, UUID(), 1, 'CentOS 6 (32-bit)', utc_timestamp());
 INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
created) VALUES (249, UUID(), 1, 'CentOS 6 (64-bit)', utc_timestamp());
-INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
created) VALUES (250, UUID(), 3, 'Oracle Enterprise Linux 6.5 (32-bit)', 
utc_timestamp());
-INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
created) VALUES (251, UUID(), 3, 'Oracle Enterprise Linux 6.5 (64-bit)', 
utc_timestamp());
 
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
@@ -837,8 +835,6 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
(uuid,hypervisor_type, hypervis
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
-INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
-INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0
@@ -935,16 +931,6 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
(uuid,hypervisor_type, hypervis
 
 INSERT IGNORE INTO `cloud`.`hypervisor_capabilities`(uuid, hypervisor_type, 
hypervisor_version, max_guests_limit, security_group_enabled, 
max_data_volumes_limit, storage_motion_sup
 
-update vlan set vlan_id=concat('vlan://', vlan_id) where vlan_type = 
"VirtualNetwork" and vlan_id not like "vlan://%";
-
-CREATE TABLE `cloud`.`baremetal_rct` (
-  `id` bigint unsigned UNIQUE AUTO_INCREMENT,
-  `uuid` varchar(40) UNIQUE NOT NULL,
-  `url` varchar(2048) NOT NULL,
-  `rct` text NOT NULL,
-   PRIMARY KEY (`id`)
-) ENGINE = InnoDB DEFAULT CHARSET=utf8;
-
 --Remove duplicates from guest_os_hypervisor table
 DELETE t1 FROM guest_os_hypervisor t1, guest_os_hypervisor t2 WHERE 
(t1.hypervisor_type = t2.hypervisor_type AND t1.hypervisor_version = 
t2.hypervisor_version AND t1.guest_os_id = 
 
@@ -958,9 +944,6 @@ ALTER TABLE `cloud`.`user_vm_details` MODIFY `value` 
VARCHAR(5120);
 
 UPDATE `cloud`.`host` SET resource = REPLACE(resource, 
'com.cloud.hypervisor.xen.resource', 'com.cloud.hypervisor.xenserver.resource') 
WHERE hypervisor_type='XenServer' AND REMOVED
 
-INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public, 
created, type, hvm, bits, account_id, url, checksum, enable_password, 
display_text,  format, guest_os_id, fe
-VALUES (11, UUID(), 'centos7-x86_64-lxc', 'CentOS 7(64-bit) no GUI (LXC)', 
1, now(), 'BUILTIN', 0, 64, 1, 
'http://download.cloud.com/templates/builtin/centos-7-x86_64.tar.gz', 
-
 --Support for RHEL 6.5 in relevant hypervisor versions
 INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
created) VALUES (252, UUID(), 4, 'Red Hat Enterprise Linux 6.5 (32-bit)', 
utc_timestamp());
 INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
created) VALUE

Re: CloudStack Job offering @exoscale

2014-11-27 Thread Daan Hoogland
Lucian, i'll be enjoying your dedication as it shifts to dev work;)

On Thu, Nov 27, 2014 at 10:16 AM, Nux!  wrote:
> I don't mind seeing job offers from "good guy" companies like Exoscale who 
> are active in the community and contribute back, especially at this moment in 
> time when this kind of thing is a rarity so to say.
>
> If the volume of postings increases it will become annoying and linkedin or 
> some other places may be better suited, but that'd still be a nice problem to 
> have.
>
> A very good sign indeed, as Giles say! And also quite interesting to see such 
> interest for ACS in Europe.
>
> Let's not forget Wido is also looking for Cloudstack people at PCExtreme.
>
> Seems like a good time to be an ACS developer!
>
> It's time to learn Java! :-)
>
>
> My 2 pence,
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Giles Sirett" 
>> To: dev@cloudstack.apache.org
>> Sent: Thursday, 27 November, 2014 08:46:07
>> Subject: RE: CloudStack Job offering @exoscale
>
>> But being such a small community right now, I think its great to see Exoscale
>> creating developer roles around Cloudstack and agree, right now, that this is
>> the most sensible place to post them  - really good news Antoine.
>> At the same time its worth mentioning that ShapeBlue have a number of 
>> Cloudstack
>> dev & Engineering positions open
>> Shapeblue.com/careers
>> And, yes, Interoute are also hiring Cloudstack people
>>
>> As the jobs market around Cloudstack is clearly developing (what a fantastic
>> sign),  long-term, nobody wants to see our dev list getting spammed by
>> recruiters, etc - but I also do think it is useful for people in our 
>> community
>> to see that, if they want, they can develop their careers around ACS
>> May I suggest that we encourage people going forward to use the various
>> Cloudstack linkedin groups for these sort of subjects - that would keep these
>> out of the dev list
>>
>> Thoughts ?
>>
>>
>> Kind Regards
>> Giles
>>
>> D: +44 20 3603 0541 | M: +44 796 111 2055
>> giles.sir...@shapeblue.com
>>
>>
>>
>>
>> -Original Message-
>> From: sebgoa [mailto:run...@gmail.com]
>> Sent: 27 November 2014 07:58
>> To: dev@cloudstack.apache.org
>> Subject: Fwd: CloudStack Job offering @exoscale
>>
>> I think this is legitimate on dev@
>>
>> Note that there are also jobs available at interoute.
>>
>> Begin forwarded message:
>>
>>> From: "Coetsier, Antoine" 
>>> Subject: CloudStack Job offering @exoscale
>>> Date: November 26, 2014 5:20:57 PM GMT+01:00
>>> To: "us...@cloudstack.apache.org" 
>>> Reply-To: us...@cloudstack.apache.org
>>>
>>> Hello All,
>>>
>>> We are looking for a developer that already has some knowledge of 
>>> CloudStack to
>>> join our team at Exoscale. Trendy topics about network 
>>> functions/distributed LB
>>> in CS for this full time job.
>>>
>>> This is based in Switzerland of course. The job description is here:
>>> https://www.exoscale.ch/jobs/ Get in touch with us at: hr -AT-
>>> exoscale.ch
>>>
>>> Thank you,
>>> --
>>> Antoine COETSIER – EXOSCALE CEO
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build
>> CSForge – rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Software
>> Engineering
>> CloudStack Infrastructure
>> Support
>> CloudStack Bootcamp Training 
>> Courses
>>
>> 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 SA Pty Ltd is a company registered by
>> The Republic of South Africa and is traded under license from Shape Blue Ltd.
>> ShapeBlue is a registered trademark.



-- 
Daan


Re: Differences in schema-442to450.sql between 4.5 and master

2014-11-27 Thread Hugo Trippaers
List of commit that introduced the changes in master, hope this helps a bit in 
tracking down where to look. If i can help let me know.

057ba164 Sanjay Tripathi
e02c3824 Anthony Xu
6f413c22 Frank Zhang
1091d458 Kishan Kavala

Cheers,

Hugo




> On 27 nov. 2014, at 10:32, Hugo Trippaers  wrote:
> 
> See this diff:
> Hugos-MacBook-Pro-7:cloudstack hugo (master)$ git diff master 4.5 
> setup/db/db/schema-442to450.sql
> diff --git a/setup/db/db/schema-442to450.sql b/setup/db/db/schema-442to450.sql
> index f84bca6..083943b 100644
> --- a/setup/db/db/schema-442to450.sql
> +++ b/setup/db/db/schema-442to450.sql
> @@ -753,8 +753,6 @@ INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, 
> category_id, display_name, crea
>  INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (247, UUID(), 3, 'Oracle Linux 7', utc_timestamp());
>  INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (248, UUID(), 1, 'CentOS 6 (32-bit)', utc_timestamp());
>  INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (249, UUID(), 1, 'CentOS 6 (64-bit)', utc_timestamp());
> -INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (250, UUID(), 3, 'Oracle Enterprise Linux 6.5 (32-bit)', 
> utc_timestamp());
> -INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (251, UUID(), 3, 'Oracle Enterprise Linux 6.5 (64-bit)', 
> utc_timestamp());
>  
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
> @@ -837,8 +835,6 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
> (uuid,hypervisor_type, hypervis
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
> -INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
> -INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
> @@ -935,16 +931,6 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
> (uuid,hypervisor_type, hypervis
>  
>  INSERT IGNORE INTO `cloud`.`hypervisor_capabilities`(uuid, hypervisor_type, 
> hypervisor_version, max_guests_limit, security_group_enabled, 
> max_data_volumes_limit, storage_motion_sup
>  
> -update vlan set vlan_id=concat('vlan://' , vlan_id) where 
> vlan_type = "VirtualNetwork" and vlan_id not like "vlan://% ";
> -
> -CREATE TABLE `cloud`.`baremetal_rct` (
> -  `id` bigint unsigned UNIQUE AUTO_INCREMENT,
> -  `uuid` varchar(40) UNIQUE NOT NULL,
> -  `url` varchar(2048) NOT NULL,
> -  `rct` text NOT NULL,
> -   PRIMARY KEY (`id`)
> -) ENGINE = InnoDB DEFAULT CHARSET=utf8;
> -
>  --Remove duplicates from guest_os_hypervisor table
>  DELETE t1 FROM guest_os_hypervisor t1, guest_os_hypervisor t2 WHERE 
> (t1.hypervisor_type = t2.hypervisor_type AND t1.hypervisor_version = 
> t2.hypervisor_version AND t1.guest_os_id = 
>  
> @@ -958,9 +944,6 @@ ALTER TABLE `cloud`.`user_vm_details` MODIFY `value` 
> VARCHAR(5120);
>  
>  UPDATE `cloud`.`host` SET resource = REPLACE(resource, 
> 'com.cloud.hypervisor.xen.resource', 
> 'com.cloud.hypervisor.xenserver.resource') WHERE hypervisor_type='XenServer' 
> AND REMOVED
>  
> -INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public, 
> created, type, hvm, bits, account_id, url, checksum, enable_password, 
> display_text,  format, guest_os_id, fe
> -VALUES (11, UUID(),

Re: Differences in schema-442to450.sql between 4.5 and master

2014-11-27 Thread Daan Hoogland
Please take note that people that made the change probably made it to
schema-441to450.sql which I renamed.

On Thu, Nov 27, 2014 at 10:32 AM, Hugo Trippaers  wrote:
> See this diff:
> Hugos-MacBook-Pro-7:cloudstack hugo (master)$ git diff master 4.5 
> setup/db/db/schema-442to450.sql
> diff --git a/setup/db/db/schema-442to450.sql b/setup/db/db/schema-442to450.sql
> index f84bca6..083943b 100644
> --- a/setup/db/db/schema-442to450.sql
> +++ b/setup/db/db/schema-442to450.sql
> @@ -753,8 +753,6 @@ INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, 
> category_id, display_name, crea
>  INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (247, UUID(), 3, 'Oracle Linux 7', utc_timestamp());
>  INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (248, UUID(), 1, 'CentOS 6 (32-bit)', utc_timestamp());
>  INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (249, UUID(), 1, 'CentOS 6 (64-bit)', utc_timestamp());
> -INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (250, UUID(), 3, 'Oracle Enterprise Linux 6.5 (32-bit)', 
> utc_timestamp());
> -INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (251, UUID(), 3, 'Oracle Enterprise Linux 6.5 (64-bit)', 
> utc_timestamp());
>
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
> @@ -837,8 +835,6 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
> (uuid,hypervisor_type, hypervis
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
> -INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
> -INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
> VALUES (UUID(),'Xenserver', '6.5.0
> @@ -935,16 +931,6 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
> (uuid,hypervisor_type, hypervis
>
>  INSERT IGNORE INTO `cloud`.`hypervisor_capabilities`(uuid, hypervisor_type, 
> hypervisor_version, max_guests_limit, security_group_enabled, 
> max_data_volumes_limit, storage_motion_sup
>
> -update vlan set vlan_id=concat('vlan://', vlan_id) where vlan_type = 
> "VirtualNetwork" and vlan_id not like "vlan://%";
> -
> -CREATE TABLE `cloud`.`baremetal_rct` (
> -  `id` bigint unsigned UNIQUE AUTO_INCREMENT,
> -  `uuid` varchar(40) UNIQUE NOT NULL,
> -  `url` varchar(2048) NOT NULL,
> -  `rct` text NOT NULL,
> -   PRIMARY KEY (`id`)
> -) ENGINE = InnoDB DEFAULT CHARSET=utf8;
> -
>  --Remove duplicates from guest_os_hypervisor table
>  DELETE t1 FROM guest_os_hypervisor t1, guest_os_hypervisor t2 WHERE 
> (t1.hypervisor_type = t2.hypervisor_type AND t1.hypervisor_version = 
> t2.hypervisor_version AND t1.guest_os_id =
>
> @@ -958,9 +944,6 @@ ALTER TABLE `cloud`.`user_vm_details` MODIFY `value` 
> VARCHAR(5120);
>
>  UPDATE `cloud`.`host` SET resource = REPLACE(resource, 
> 'com.cloud.hypervisor.xen.resource', 
> 'com.cloud.hypervisor.xenserver.resource') WHERE hypervisor_type='XenServer' 
> AND REMOVED
>
> -INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public, 
> created, type, hvm, bits, account_id, url, checksum, enable_password, 
> display_text,  format, guest_os_id, fe
> -VALUES (11, UUID(), 'centos7-x86_64-lxc', 'CentOS 7(64-bit) no GUI 
> (LXC)', 1, now(), 'BUILTIN', 0, 64, 1, 
> 'http://download.cloud.com/templates/builtin/centos-7-x86

Re: CloudStack Job offering @exoscale

2014-11-27 Thread Coetsier, Antoine
Hello,

I clearly hesitated prior to posting it on the ML due to « commercial »
nature of this, but since almost everybody here is actively looking for
talents, it is best if we can make some noise about it.

Hopefully with all those jobs, that will be some great improvements for
the product. Mission 1 for our developer to be hired is to tackle on all
consistency problems in the VR prior to add new features.

@Schuberg Philis team: is the work you presented on the poster regarding
the VR public? If yes can you point to branch/repo where it is undertaken ?

-- 
Antoine COETSIER ­ EXOSCALE CEO




Le 27.11.14 10:16, « Nux! »  a écrit :

>I don't mind seeing job offers from "good guy" companies like Exoscale
>who are active in the community and contribute back, especially at this
>moment in time when this kind of thing is a rarity so to say.
>
>If the volume of postings increases it will become annoying and linkedin
>or some other places may be better suited, but that'd still be a nice
>problem to have.
>
>A very good sign indeed, as Giles say! And also quite interesting to see
>such interest for ACS in Europe.
>
>Let's not forget Wido is also looking for Cloudstack people at PCExtreme.
>
>Seems like a good time to be an ACS developer!
>
>It's time to learn Java! :-)
>
>
>My 2 pence,
>
>Lucian
>
>--
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
>www.nux.ro
>
>- Original Message -
>> From: "Giles Sirett" 
>> To: dev@cloudstack.apache.org
>> Sent: Thursday, 27 November, 2014 08:46:07
>> Subject: RE: CloudStack Job offering @exoscale
>
>> But being such a small community right now, I think its great to see
>>Exoscale
>> creating developer roles around Cloudstack and agree, right now, that
>>this is
>> the most sensible place to post them  - really good news Antoine.
>> At the same time its worth mentioning that ShapeBlue have a number of
>>Cloudstack
>> dev & Engineering positions open
>> Shapeblue.com/careers
>> And, yes, Interoute are also hiring Cloudstack people
>> 
>> As the jobs market around Cloudstack is clearly developing (what a
>>fantastic
>> sign),  long-term, nobody wants to see our dev list getting spammed by
>> recruiters, etc - but I also do think it is useful for people in our
>>community
>> to see that, if they want, they can develop their careers around ACS
>> May I suggest that we encourage people going forward to use the various
>> Cloudstack linkedin groups for these sort of subjects - that would keep
>>these
>> out of the dev list
>> 
>> Thoughts ?
>> 
>> 
>> Kind Regards
>> Giles
>> 
>> D: +44 20 3603 0541 | M: +44 796 111 2055
>> giles.sir...@shapeblue.com
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: sebgoa [mailto:run...@gmail.com]
>> Sent: 27 November 2014 07:58
>> To: dev@cloudstack.apache.org
>> Subject: Fwd: CloudStack Job offering @exoscale
>> 
>> I think this is legitimate on dev@
>> 
>> Note that there are also jobs available at interoute.
>> 
>> Begin forwarded message:
>> 
>>> From: "Coetsier, Antoine" 
>>> Subject: CloudStack Job offering @exoscale
>>> Date: November 26, 2014 5:20:57 PM GMT+01:00
>>> To: "us...@cloudstack.apache.org" 
>>> Reply-To: us...@cloudstack.apache.org
>>>
>>> Hello All,
>>>
>>> We are looking for a developer that already has some knowledge of
>>>CloudStack to
>>> join our team at Exoscale. Trendy topics about network
>>>functions/distributed LB
>>> in CS for this full time job.
>>>
>>> This is based in Switzerland of course. The job description is here:
>>> https://www.exoscale.ch/jobs/ Get in touch with us at: hr -AT-
>>> exoscale.ch
>>>
>>> Thank you,
>>> --
>>> Antoine COETSIER ­ EXOSCALE CEO
>> 
>> Find out more about ShapeBlue and our range of CloudStack related
>>services
>> 
>> IaaS Cloud Design &
>>Build
>> CSForge ­ rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Software
>> Engineering
>> CloudStack Infrastructure
>> Support
>> CloudStack Bootcamp Training
>>Courses
>> 
>> 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

Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Rohit Yadav

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

Ship it!


+1
LGTM, if any of the other designated reviewers don't object let's merge this on 
master/4.5; I've already picked/fixed this for 4.3 branch.

Hari - thanks for the patch, I encourage you to use Github Pull Requests in 
future which I find is less painful than using reviewboard.

- Rohit Yadav


On Nov. 27, 2014, 9:22 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17941/
> ---
> 
> (Updated Nov. 27, 2014, 9:22 a.m.)
> 
> 
> Review request for cloudstack, Jayapal Reddy, Kishan Kavala, and Rajani 
> Karuturi.
> 
> 
> Bugs: CLOUDSTACK-6075
> https://issues.apache.org/jira/browse/CLOUDSTACK-6075
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6075: Increase the ram size for router service offering 
> Increased the ram size of Internal load balancer vm service offering also
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade442to450.java dc1057f 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java
>  803d3a5 
>   server/src/com/cloud/configuration/Config.java cd0824e 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 
> 9fb47fd 
>   setup/db/db/schema-442to450.sql 107f10c 
> 
> Diff: https://reviews.apache.org/r/17941/diff/
> 
> 
> Testing
> ---
> 
> tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>



Re: Review Request 24991: CLOUDSTACK-6697: BigSwitchVns plugin update

2014-11-27 Thread Hugo Trippaers

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


Heya,

sorry for the late review. I promised to look at it earlier and forgot it.

It looks good to me, however it doesn't apply cleanly on current master. Also 
you are making some database changes in the file schema-442to450.sql, can you 
move those to schema-450to460.sql as that is the current schemafile for master.

Can you remove the one database change in create-schema.sql? We try to prevent 
that file from changing at all.

When it applies cleanly i'll run some checks (FindBugs, PMD) and commit if 
there are no issues that need adressing.

Cheers,

Hugo

- Hugo Trippaers


On Nov. 26, 2014, 10:52 p.m., Kuang-Ching Wang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24991/
> ---
> 
> (Updated Nov. 26, 2014, 10:52 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal, David Nalley, Sebastien 
> Goasguen, and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6697: Big Switch network plugin update
> 1. provide compatibility with the Big Cloud Fabric (BCF) controller
>L2 Connectivity Service in both VPC and non-VPC modes
> 2. virtual network terminology updates: VNS --> BCF_SEGMENT
> 3. uses HTTPS with trust-always certificate handling
> 4. topology sync support with BCF controller
> 5. support multiple (two) BCF controllers with HA
> 6. support VM migration
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/Network.java 
> c5a9bf286df8d502a6ca33661fb52ee717643566 
>   api/src/com/cloud/network/PhysicalNetwork.java 
> 7c9349d932771fdbecc4a0b1ae4cad28b3d67857 
>   client/WEB-INF/classes/resources/messages.properties 
> 3228578ce81a826f49166a72a6c67143fb12c95d 
>   client/WEB-INF/classes/resources/messages_fr_FR.properties 
> 54dc6215a8339b9f8c2bad9fe4c3ed18b4a702e7 
>   client/WEB-INF/classes/resources/messages_ja_JP.properties 
> 1962e92a4cf47978dae35a3d2b090b4c1765fecb 
>   client/WEB-INF/classes/resources/messages_ko_KR.properties 
> ced576cb23598e7d3e5005bc24c2adf20b66a826 
>   client/WEB-INF/classes/resources/messages_nl_NL.properties 
> 86653a5f5144c75e67b5a6f02c47d37bd5a71ef0 
>   client/WEB-INF/classes/resources/messages_pt_BR.properties 
> fa77633a650f1b37d8398a8936bbf84f5b4a40e3 
>   client/WEB-INF/classes/resources/messages_ru_RU.properties 
> 7f57daa58bef379ddb47acb88965d0defe32ad73 
>   client/WEB-INF/classes/resources/messages_zh_CN.properties 
> 217849582b41cb2c63a0e305e5613af6f659d11d 
>   client/pom.xml 6803f9a11fd2c80523ea16bdd35f2a4d163f953c 
>   client/tomcatconf/commands.properties.in 
> a87d1677f24657299ec24d4ce9df9a180a62bd0c 
>   engine/schema/src/com/cloud/user/dao/VmDiskStatisticsDaoImpl.java 
> e1136d3cf567b73fd1198181aea4d6995df6b78a 
>   plugins/network-elements/bigswitch-vns/pom.xml 
> afb267cdb5bc52aea23bc6739ea21d8f52e94ede 
>   
> plugins/network-elements/bigswitch-vns/resources/META-INF/cloudstack/vns/module.properties
>  5783d38e5cb78be0d418c80981246d721d18b62a 
>   
> plugins/network-elements/bigswitch-vns/resources/META-INF/cloudstack/vns/spring-vns-context.xml
>  d5bb92afe3d3051dbdd4b4d49698c313c77d255f 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/CreateVnsNetworkAnswer.java
>  e950abe3bed85b75a20be2b8c4537a2fbd6be39e 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/CreateVnsNetworkCommand.java
>  534bb7f9f9154a652a20310fe020bddc4249ef54 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/CreateVnsPortAnswer.java
>  82c2fe90d63e0148bca8de9ce8612e4dd53cf735 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/CreateVnsPortCommand.java
>  c3b9a9d6d9504e34cbe1294ac640f56aab101395 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/DeleteVnsNetworkAnswer.java
>  72ac98ac9e0a1ae4858019e3baccc160300e24bf 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/DeleteVnsNetworkCommand.java
>  6cf169bbfc97b57561af729aef297c76230fd118 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/DeleteVnsPortAnswer.java
>  076b187fdf48cf776902dc9a91dc26e00396158a 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/DeleteVnsPortCommand.java
>  0cae01d471dd9c5c504002c24f865ded59812d9e 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/StartupBigSwitchVnsCommand.java
>  8310b0763708c3f049ef4ce427d09f0c07cd05b3 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/UpdateVnsPortAnswer.java
>  39cd26649c9bb0c4993f55bef65edfc326c4ceda 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/UpdateVnsPortCommand.java
>  40f092076061

Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Rajani Karuturi


> On Nov. 27, 2014, 10:15 a.m., Rohit Yadav wrote:
> > +1
> > LGTM, if any of the other designated reviewers don't object let's merge 
> > this on master/4.5; I've already picked/fixed this for 4.3 branch.
> > 
> > Hari - thanks for the patch, I encourage you to use Github Pull Requests in 
> > future which I find is less painful than using reviewboard.

and also on 4.4 please. since its already on 4.3, it should goto all 4.3+ 
releases.


- Rajani


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


On Nov. 27, 2014, 9:22 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17941/
> ---
> 
> (Updated Nov. 27, 2014, 9:22 a.m.)
> 
> 
> Review request for cloudstack, Jayapal Reddy, Kishan Kavala, and Rajani 
> Karuturi.
> 
> 
> Bugs: CLOUDSTACK-6075
> https://issues.apache.org/jira/browse/CLOUDSTACK-6075
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6075: Increase the ram size for router service offering 
> Increased the ram size of Internal load balancer vm service offering also
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade442to450.java dc1057f 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java
>  803d3a5 
>   server/src/com/cloud/configuration/Config.java cd0824e 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 
> 9fb47fd 
>   setup/db/db/schema-442to450.sql 107f10c 
> 
> Diff: https://reviews.apache.org/r/17941/diff/
> 
> 
> Testing
> ---
> 
> tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>



Re: CloudStack Job offering @exoscale

2014-11-27 Thread Daan Hoogland
H Antoine,

It is a github repo. http://github.com/schubergphilis/cloudstack/
http://github.com/schubergphilis/cloudstack/tree/feature/systemvm-persistent-config
is the latest state of things.

regards,

On Thu, Nov 27, 2014 at 10:28 AM, Coetsier, Antoine
 wrote:
> Hello,
>
> I clearly hesitated prior to posting it on the ML due to « commercial »
> nature of this, but since almost everybody here is actively looking for
> talents, it is best if we can make some noise about it.
>
> Hopefully with all those jobs, that will be some great improvements for
> the product. Mission 1 for our developer to be hired is to tackle on all
> consistency problems in the VR prior to add new features.
>
> @Schuberg Philis team: is the work you presented on the poster regarding
> the VR public? If yes can you point to branch/repo where it is undertaken ?
>
> --
> Antoine COETSIER ­ EXOSCALE CEO
>
>
>
>
> Le 27.11.14 10:16, « Nux! »  a écrit :
>
>>I don't mind seeing job offers from "good guy" companies like Exoscale
>>who are active in the community and contribute back, especially at this
>>moment in time when this kind of thing is a rarity so to say.
>>
>>If the volume of postings increases it will become annoying and linkedin
>>or some other places may be better suited, but that'd still be a nice
>>problem to have.
>>
>>A very good sign indeed, as Giles say! And also quite interesting to see
>>such interest for ACS in Europe.
>>
>>Let's not forget Wido is also looking for Cloudstack people at PCExtreme.
>>
>>Seems like a good time to be an ACS developer!
>>
>>It's time to learn Java! :-)
>>
>>
>>My 2 pence,
>>
>>Lucian
>>
>>--
>>Sent from the Delta quadrant using Borg technology!
>>
>>Nux!
>>www.nux.ro
>>
>>- Original Message -
>>> From: "Giles Sirett" 
>>> To: dev@cloudstack.apache.org
>>> Sent: Thursday, 27 November, 2014 08:46:07
>>> Subject: RE: CloudStack Job offering @exoscale
>>
>>> But being such a small community right now, I think its great to see
>>>Exoscale
>>> creating developer roles around Cloudstack and agree, right now, that
>>>this is
>>> the most sensible place to post them  - really good news Antoine.
>>> At the same time its worth mentioning that ShapeBlue have a number of
>>>Cloudstack
>>> dev & Engineering positions open
>>> Shapeblue.com/careers
>>> And, yes, Interoute are also hiring Cloudstack people
>>>
>>> As the jobs market around Cloudstack is clearly developing (what a
>>>fantastic
>>> sign),  long-term, nobody wants to see our dev list getting spammed by
>>> recruiters, etc - but I also do think it is useful for people in our
>>>community
>>> to see that, if they want, they can develop their careers around ACS
>>> May I suggest that we encourage people going forward to use the various
>>> Cloudstack linkedin groups for these sort of subjects - that would keep
>>>these
>>> out of the dev list
>>>
>>> Thoughts ?
>>>
>>>
>>> Kind Regards
>>> Giles
>>>
>>> D: +44 20 3603 0541 | M: +44 796 111 2055
>>> giles.sir...@shapeblue.com
>>>
>>>
>>>
>>>
>>> -Original Message-
>>> From: sebgoa [mailto:run...@gmail.com]
>>> Sent: 27 November 2014 07:58
>>> To: dev@cloudstack.apache.org
>>> Subject: Fwd: CloudStack Job offering @exoscale
>>>
>>> I think this is legitimate on dev@
>>>
>>> Note that there are also jobs available at interoute.
>>>
>>> Begin forwarded message:
>>>
 From: "Coetsier, Antoine" 
 Subject: CloudStack Job offering @exoscale
 Date: November 26, 2014 5:20:57 PM GMT+01:00
 To: "us...@cloudstack.apache.org" 
 Reply-To: us...@cloudstack.apache.org

 Hello All,

 We are looking for a developer that already has some knowledge of
CloudStack to
 join our team at Exoscale. Trendy topics about network
functions/distributed LB
 in CS for this full time job.

 This is based in Switzerland of course. The job description is here:
 https://www.exoscale.ch/jobs/ Get in touch with us at: hr -AT-
 exoscale.ch

 Thank you,
 --
 Antoine COETSIER ­ EXOSCALE CEO
>>>
>>> Find out more about ShapeBlue and our range of CloudStack related
>>>services
>>>
>>> IaaS Cloud Design &
>>>Build
>>> CSForge ­ rapid IaaS deployment framework
>>> CloudStack Consulting
>>> CloudStack Software
>>> Engineering
>>> CloudStack Infrastructure
>>> Support
>>> CloudStack Bootcamp Training
>>>Courses
>>>
>>> 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 e

Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Rohit Yadav


> On Nov. 27, 2014, 10:15 a.m., Rohit Yadav wrote:
> > +1
> > LGTM, if any of the other designated reviewers don't object let's merge 
> > this on master/4.5; I've already picked/fixed this for 4.3 branch.
> > 
> > Hari - thanks for the patch, I encourage you to use Github Pull Requests in 
> > future which I find is less painful than using reviewboard.
> 
> Rajani Karuturi wrote:
> and also on 4.4 please. since its already on 4.3, it should goto all 4.3+ 
> releases.

Yes, Hari please send another patch (maybe via Github PR) for 4.4 branch as 
well? I'll help merging this on 4.5/master in the meanwhile.


- Rohit


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


On Nov. 27, 2014, 9:22 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17941/
> ---
> 
> (Updated Nov. 27, 2014, 9:22 a.m.)
> 
> 
> Review request for cloudstack, Jayapal Reddy, Kishan Kavala, and Rajani 
> Karuturi.
> 
> 
> Bugs: CLOUDSTACK-6075
> https://issues.apache.org/jira/browse/CLOUDSTACK-6075
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6075: Increase the ram size for router service offering 
> Increased the ram size of Internal load balancer vm service offering also
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade442to450.java dc1057f 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java
>  803d3a5 
>   server/src/com/cloud/configuration/Config.java cd0824e 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 
> 9fb47fd 
>   setup/db/db/schema-442to450.sql 107f10c 
> 
> Diff: https://reviews.apache.org/r/17941/diff/
> 
> 
> Testing
> ---
> 
> tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>



Re: [DISCUSS] LTS Releases

2014-11-27 Thread Andrei Mikhailovsky
+1 

Agree with everything that Andrija have said. 

The community needs to divert their attention and focus ever so slightly from 
producing new features to producing a more stable release. Having the LTS 
releases will capture this approach and will make the product more stable as 
fresh and less tested features will not be backported and only the fixes will 
be contributed. Only the dev team has the capability of actually debugging and 
fixing the issues. 

I am not a developer and can only contribute to the existing bugs or create new 
bug reports, which I have done in the past. It is very frustrating from a user 
perspective to see some of the bugs which are effecting their environments not 
being addressed in new releases. I will try for myself to find more time for 
testing new releases and report back the issues, but I will not do this on 
production anymore. I've already had to downgrade my environment 3 times 
because of the problems with the latest releases. From what I can see, 4.4.1 is 
no different from the last couple of unlucky releases, with many upgrade 
problem reports on the user list. 

>From what I can see, ShapeBlue team is doing a great job at backporting issues 
>already and I hope many developers will join this effort. 

Andrei 

- Original Message -

> From: "Andrija Panic" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, 27 November, 2014 8:01:41 AM
> Subject: Re: [DISCUSS] LTS Releases

> my 2 cents again:

> Whether we have this LTS release or not - is not just about having
> release
> - we need a WAY to focus here on FIXING, POLISHING product and more
> important to stimulate/make developers interested in doing so.
> If this was company owned product, it would be very easy to set
> goals, and
> then speak to devs, fix this, fix that.

> Since this is ofcourse comunity based product - we need some way of
> focusing on fixing the stuff, and really stop adding features (maybe
> not
> completely quit adding features, but...)

> One important note, and possible scenario - just by having LTS
> release, but
> still having majority of developer working on non-LTS release (ading
> new
> features) is a big probability, and then we are back to zero with our
> progress, so I guess this is also an option/problem that we need to
> consider.

> I have a very nice experience with CloudStack so far (in general,
> except
> being frustrated by some childish problems) - if this was all
> polished, and
> documentation complete - I'm 100% sure there will be no better cloud
> project on the market any time soon, and I really mean it !

> It is my wish (and I hope of others) to see CloudStack migrate from
> #CloudstackWorks to #CloudStackRocks for the next CCC and I think
> this is
> VERY much possible.

> On 26 November 2014 at 22:40, Pierre-Luc Dion 
> wrote:

> > I'm not really in favor of LTS support, it's a good idea, but not
> > sure it
> > can be backed by the community?[open question here ;)]. I don't
> > think it
> > fit in our current model for few reasons:
> >
> > - Upgrade path might become impossible as patches become part of
> > multiple
> > versions. We could end up with problem at database schema with the
> > current
> > db upgrade model.
> >
> > - Enforcing user to stay on a legacy ACS release disallow usage of
> > future
> > hypervisor version, Guest OSes and new hardware used by
> > hypervisors. As
> > hypervisors will become out of date, they won't be able to support
> > new
> > Guest OSes and new hardware.
> >
> > - I think the initiative would dilute the effort on the upgrade
> > path and
> > making sure the upgrade path is easy and always work. Since 4.3.1
> > as been
> > released after 4.4.0, do we know if a 4.3.1 can be upgrade to 4.4.1
> > or
> > event 4.5?
> >
> > - Contribution to ACS and bugfixing become nightmare as bugfix
> > might end
> > up in 4 branches (4.3, 4.4, 4.5, master,...)
> >
> > Why not as community (let's face it, not very a big one) we all
> > focus on
> > the next 4.5 version, make sure it's properly tested, make sure
> > upgrade
> > "just work" and have ACS 4 as the LTS ? ;-)
> >
> > I know a production system is not likely to run the latest version
> > of ACS
> > and upgrade of such a prod tool can occur maybe one or two time a
> > year.
> >
> > That's just my opinion on the subject, nothing against anyone or to
> > block
> > the idea.
> >
> >
> >
> > On Tue, Nov 25, 2014 at 11:35 AM, Hugo Trippaers
> > 
> > wrote:
> >
> > > Top posting here as my remarks are mainly on the original topic.
> > >
> > > I’m not in favor of supporting LTS releases as a community. The
> > > reasoning
> > > here is that there is a huge chance that we will fragment the
> > > community
> > in
> > > people that just want to work on the latest and greatest and some
> > > other
> > > folks who are trying to keep older releases from being updated
> > > with newer
> > > fixes. It requires a lot of dedicated commitment to keep an LTS
> > > release
> > > going. Particularl

Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Harikrishna Patnala


> On Nov. 27, 2014, 10:15 a.m., Rohit Yadav wrote:
> > +1
> > LGTM, if any of the other designated reviewers don't object let's merge 
> > this on master/4.5; I've already picked/fixed this for 4.3 branch.
> > 
> > Hari - thanks for the patch, I encourage you to use Github Pull Requests in 
> > future which I find is less painful than using reviewboard.
> 
> Rajani Karuturi wrote:
> and also on 4.4 please. since its already on 4.3, it should goto all 4.3+ 
> releases.
> 
> Rohit Yadav wrote:
> Yes, Hari please send another patch (maybe via Github PR) for 4.4 branch 
> as well? I'll help merging this on 4.5/master in the meanwhile.

Thanks Rohit, I'll put github PR for 4.4 branch


- Harikrishna


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


On Nov. 27, 2014, 9:22 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17941/
> ---
> 
> (Updated Nov. 27, 2014, 9:22 a.m.)
> 
> 
> Review request for cloudstack, Jayapal Reddy, Kishan Kavala, and Rajani 
> Karuturi.
> 
> 
> Bugs: CLOUDSTACK-6075
> https://issues.apache.org/jira/browse/CLOUDSTACK-6075
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6075: Increase the ram size for router service offering 
> Increased the ram size of Internal load balancer vm service offering also
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade442to450.java dc1057f 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java
>  803d3a5 
>   server/src/com/cloud/configuration/Config.java cd0824e 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 
> 9fb47fd 
>   setup/db/db/schema-442to450.sql 107f10c 
> 
> Diff: https://reviews.apache.org/r/17941/diff/
> 
> 
> Testing
> ---
> 
> tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>



Re: [DISCUSS] LTS Releases

2014-11-27 Thread ChunFeng
hi,


LTS means Long Term Support  , for ubuntu means 5 years support for both 
desktop and server distributions.  If we adopt to release cloudstack's LTS 
version , how many years should we support ?  5 years ? of course can not 
accept ! even 3 years may be too long to old for support as a IAAS management 
software .  2 or 1 years ?  this should not call LTS version .


Second ,the time span for ubuntu release next new LTS version is every 2 years 
. Then , consider the first question , what kind of years interval should we 
take?


Third, even if the above two issues is false positive , how should we name the 
LTS release version's  ? such as:  CloudStack-LTS-4.x-201401 ,  
CloudStack-LTS-4.X-201402  etc , this may cause a more confuse to end-users to 
make a right choice . 


IMO ,  if a software could  automatically upgrade to newer version  by just one 
or fews clickes , which kind software is suitable for  LTS release mechanism , 
otherwise the cost for end-user to  upgrade from the older one to newer which 
will be same as user to choice next release version, ie reinstall   . 


as Hugo, sebgoa and Andrija  said: " we need a WAY to focus here on FIXING, 
POLISHING ", "then LTS becomes less important"  and "  I’m not in favor of 
supporting LTS releases as a community. "


--



Regards,


ChunFeng




 

 
 
 
-- Original --
From:  "sebgoa";
Date:  Thu, Nov 27, 2014 05:14 PM
To:  "dev"; 

Subject:  Re: [DISCUSS] LTS Releases

 

On Nov 27, 2014, at 9:01 AM, Andrija Panic  wrote:

> my 2 cents again:
> 
> Whether we have this LTS release or not - is not just about having release
> - we need a WAY to focus here on FIXING, POLISHING product and more
> important to stimulate/make developers interested in doing so.
> If this was company owned product, it would be very easy to set goals, and
> then speak to devs, fix this, fix that.
> 
> Since this is ofcourse comunity based product - we need some way of
> focusing on fixing the stuff, and really stop adding features (maybe not
> completely quit adding features, but...)
> 
> One important note, and possible scenario - just by having LTS release, but
> still having majority of developer working on non-LTS release (ading new
> features) is a big probability, and then we are back to zero with our
> progress, so I guess this is also an option/problem that we need to
> consider.
> 
> I have a very nice experience with CloudStack so far (in general, except
> being frustrated by some childish problems) - if this was all polished, and
> documentation complete - I'm 100% sure there will be no better cloud
> project on the market any time soon, and I really mean it !
> 
> It is my wish (and I hope of others) to see CloudStack migrate from
> #CloudstackWorks to #CloudStackRocks for the next CCC and I think this is
> VERY much possible.
> 

Thanks for this Andrija, it made my morning :)

I am of the opinion that if/when we improve our committing habits, we will have 
high confidence that every bug fixed in a release branch will also be fixed in 
the next release.

Little process changing that we are making, like using github PR, merging back 
to master etc, will help us get into somewhat of a rolling release. 

If we take great care with our upgrade paths and avoid regressions then LTS 
becomes less important. We have had some challenges with 4.4 and the fact that 
4.3 is solid makes it natural to want to keep 4.3 alive and patched.

I don't use cloudstack in production so I will differ to those who do on this.

What we do need is higher involvement of users in testing and voting on the 
releases early.

-Sebastien

> 
> 
> On 26 November 2014 at 22:40, Pierre-Luc Dion  wrote:
> 
>> I'm not really in favor of LTS support, it's a good idea, but not sure it
>> can be backed by the community?[open question here ;)]. I don't think it
>> fit in our current model for few reasons:
>> 
>> - Upgrade path might become impossible as patches become part of multiple
>> versions. We could end up with problem at database schema with the current
>> db upgrade model.
>> 
>> - Enforcing user to stay on a legacy ACS release disallow usage of future
>> hypervisor version, Guest OSes and new hardware used by hypervisors. As
>> hypervisors will become out of date, they won't be able to support new
>> Guest OSes and new hardware.
>> 
>> - I think the initiative would dilute the effort on the upgrade path and
>> making sure the upgrade path is easy and always work. Since 4.3.1 as been
>> released after 4.4.0, do we know if a 4.3.1 can be upgrade to 4.4.1 or
>> event 4.5?
>> 
>> - Contribution to ACS and bugfixing become nightmare  as bugfix might end
>> up in 4 branches (4.3, 4.4, 4.5, master,...)
>> 
>> Why not as community (let's face it, not very a big one) we all focus on
>> the next 4.5 version, make sure it's properly tested, make sure upgrade
>> "just work"  and have ACS 4 as the LTS ? ;-)
>> 
>> I know a production system is not likel

Review Request 28511: CLOUDSTACK-7412: Can't create proper template from VM on S3 secondary storage environment

2014-11-27 Thread Hiroki Ohashi

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

Review request for cloudstack.


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


Repository: cloudstack-git


Description
---

[Abstract]

Root cause of this issue is a way to handle cache using S3 as
Secondary Storage.

When CloudStack uploads a disk image on Primary Storage(PS) to
Secondary Storage(SS), it caches the disk image on Secondary Staging
Store(SSS). This is a bug.

CloudStack uses disk image cache every time if the cache exists. For
this behavior, the old cache on SSS will be uploaded as a template
though a CloudStack user creates the template from a newer disk image
on PS than the cache.

So, we fixed this issue in a way that CloudStack deletes the cache on
SSS after CloudStack uploads disk image to SS.


[Details]

Process of handling cache is different between copy from SS to
PS(download) and copy from PS to SS(upload).

* Downloading a disk image from SS to PS

This is the case that a CloudStack user creates an instance from a
template. CloudStack caches the image on SSS.

* Uploading a disk image from PS to SS

This is the case that a CloudStack user creates a template from a disk
image of an instance. CloudStack shouldn't cache a disk image because
it usually happens that a cache image is older than a volume of an
instance.

However, there is a bug in branch condition about post process of
uploading a disk image. Then CloudStack doesn't delete the disk image
on SSS.

CloudStack uses a common method to copy a disk image between PS and SS
for upload and download. The method includes post process of disk
image cache.

As a part of post process, it is judged whether a disk image on SSS is
used as cache or not in this method:

  a. Delete a disk image as upload procedure

  b. Delete a disk image to handle errors

  c. Cache a disk image as download procedure

In case of uploading a disk image, branch-a should be selected. But
branch-c is always selected by the condition bug. As a result, a disk
image is left on SSS and used as cache next time a CloudStack user
creates a template from an instance.


Diffs
-

  
engine/storage/datamotion/src/org/apache/cloudstack/storage/motion/AncientDataMotionStrategy.java
 d6759cb 

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


Testing
---

Items below are confirmed.

- A template created from an instance reflects a volume of the instance.
- No cache file exists on NFS secondary staging store.
- No cache entry exists on template_store_ref.

We use this patch in our environment.


Thanks,

Hiroki Ohashi



Re: Review Request 25170: Summary:pre-add all RewriteRule entries to metadata htaccess file for system vm routers, removes dynamic generation and adds previous fix for bug 7405

2014-11-27 Thread Sebastien Goasguen


> On Sept. 4, 2014, 8:28 a.m., Sebastien Goasguen wrote:
> > applied to master with 355eb72c7d3a3bf29d6d1a2185a5973bc511ed77
> > and applied to hotfix/4.4-7405 
> > 
> > It did not apply cleanly on 4.3, so I will not apply it there and keep it 
> > at Erik's patch in vmdata.py
> > 
> > thanks for the patch, you can mark the review as submitted

Fred, can you mark the review as submitted. This was applied, thanks for the 
patch.


- Sebastien


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


On Aug. 28, 2014, 10:46 p.m., Fred Clift wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25170/
> ---
> 
> (Updated Aug. 28, 2014, 10:46 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: 7405
> https://issues.apache.org/jira/browse/7405
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> pre-add all RewriteRule entries to metadata htaccess file  for system vm 
> routers- makes automated router maintanince easier...  The set is static and 
> doesn't ever change after the initial provision - it is identical for every 
> router... 
> 
> Fix htaccess file, vmdata.py that used to modify it, and added comments to 
> producers of meta-data to note the new usage
> 
> Includes updated fix for bug 7405
> 
> We (betterservers.com) have some in-house router-fixing scripts that would 
> like to re-unpack the tarball and not loose the full .htaccess file... 
> 
> 
> Diffs
> -
> 
>   
> core/test/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResourceTest.java
>  aab1e72 
>   
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetalPxeManagerImpl.java
>  e133f7d 
>   server/src/com/cloud/network/element/CloudZonesNetworkElement.java 55cd5fa 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> 33d7cd7 
>   systemvm/patches/debian/config/opt/cloud/bin/vmdata.py a44c134 
>   systemvm/patches/debian/config/var/www/html/latest/.htaccess 038a4c9 
> 
> Diff: https://reviews.apache.org/r/25170/diff/
> 
> 
> Testing
> ---
> 
> tested before and after getting user-data and metadata, with and without
> trailing slashes.
> 
> provisioned new router.
> 
> 
> Thanks,
> 
> Fred Clift
> 
>



Re: Review Request 25023: CLOUDSTACK-7405: Allow VR metadata to be accessed without trailing slash

2014-11-27 Thread Sebastien Goasguen


> On Aug. 26, 2014, 8:39 p.m., Fred Clift wrote:
> > ./systemvm/patches/debian/config/var/www/html/latest/.htaccess
> > 
> > 
> > That file has a stub-version of the file, and is pre-seeded with one 
> > rewrite rule...
> > 
> > looks like this:
> > 
> > Options +FollowSymLinks
> > RewriteEngine On
> > #RewriteBase /
> > 
> > RewriteRule ^user-data$  ../userdata/%{REMOTE_ADDR}/user-data [L,NC,QSA]
> > 
> > 
> > That rule also probably needs to be updated.
> > 
> > You might also want to look at 
> > 
> > https://reviews.apache.org/r/25065/
> > 
> > 
> > and perhaps we could combine our patches...
> 
> Erik Weber wrote:
> I tested by deleting the .htaccess and restarting the VR.
> This is the total content of .htaccess:
> Options +FollowSymLinks
> RewriteEngine On
> 
> RewriteRule ^user-data/?$  ../userdata/%{REMOTE_ADDR}/user-data [L,NC,QSA]
> RewriteRule ^service-offering/?$  
> ../metadata/%{REMOTE_ADDR}/service-offering [L,NC,QSA]
> RewriteRule ^meta-data/(.+[^/])/?$  ../metadata/%{REMOTE_ADDR}/$1 
> [L,NC,QSA]
> RewriteRule ^meta-data/?$  ../metadata/%{REMOTE_ADDR}/meta-data [L,NC,QSA]
> RewriteRule ^availability-zone/?$  
> ../metadata/%{REMOTE_ADDR}/availability-zone [L,NC,QSA]
> RewriteRule ^local-ipv4/?$  ../metadata/%{REMOTE_ADDR}/local-ipv4 
> [L,NC,QSA]
> RewriteRule ^local-hostname/?$  ../metadata/%{REMOTE_ADDR}/local-hostname 
> [L,NC,QSA]
> RewriteRule ^public-ipv4/?$  ../metadata/%{REMOTE_ADDR}/public-ipv4 
> [L,NC,QSA]
> RewriteRule ^public-hostname/?$  
> ../metadata/%{REMOTE_ADDR}/public-hostname [L,NC,QSA]
> RewriteRule ^instance-id/?$  ../metadata/%{REMOTE_ADDR}/instance-id 
> [L,NC,QSA]
> RewriteRule ^vm-id/?$  ../metadata/%{REMOTE_ADDR}/vm-id [L,NC,QSA]
> RewriteRule ^public-keys/?$  ../metadata/%{REMOTE_ADDR}/public-keys 
> [L,NC,QSA]
> RewriteRule ^cloud-identifier/?$  
> ../metadata/%{REMOTE_ADDR}/cloud-identifier [L,NC,QSA]
> 
> I don't mind combining the patches. If you want to provide it and receive 
> credit I believe this patch has been commited to the 4.3 branch. You can 
> probably provide a patch based on that :-)

erik, can you mark this review as submitted, this is in 4.3 and Fred's patch is 
in master and 4.5


- Sebastien


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


On Aug. 25, 2014, 7:55 p.m., Erik Weber wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25023/
> ---
> 
> (Updated Aug. 25, 2014, 7:55 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen, Sebastien Goasguen, and Wido 
> den Hollander.
> 
> 
> Bugs: CLOUDSTACK-7405
> https://issues.apache.org/jira/browse/CLOUDSTACK-7405
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> As per https://issues.apache.org/jira/browse/CLOUDSTACK-7405 cloud-init 
> expects to be able to get meta-data directory without using a trailing slash.
> 
> Ultimately this should be fixed in cloud-init, but it's an unintrusive fix in 
> cloudstack
> 
> 
> Diffs
> -
> 
>   systemvm/patches/debian/config/opt/cloud/bin/vmdata.py f508032 
> 
> Diff: https://reviews.apache.org/r/25023/diff/
> 
> 
> Testing
> ---
> 
> tested with curl that both new and old url works
> 
> [root@jenkins ~]# curl -I -s 10.30.81.1/latest/meta-data/vm-id | grep HTTP
> HTTP/1.1 200 OK
> [root@jenkins ~]# curl -I -s 10.30.81.1/latest/meta-data | grep HTTP
> HTTP/1.1 200 OK
> 
> 
> Thanks,
> 
> Erik Weber
> 
>



Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Rohit Yadav


> On Nov. 27, 2014, 10:15 a.m., Rohit Yadav wrote:
> > +1
> > LGTM, if any of the other designated reviewers don't object let's merge 
> > this on master/4.5; I've already picked/fixed this for 4.3 branch.
> > 
> > Hari - thanks for the patch, I encourage you to use Github Pull Requests in 
> > future which I find is less painful than using reviewboard.
> 
> Rajani Karuturi wrote:
> and also on 4.4 please. since its already on 4.3, it should goto all 4.3+ 
> releases.
> 
> Rohit Yadav wrote:
> Yes, Hari please send another patch (maybe via Github PR) for 4.4 branch 
> as well? I'll help merging this on 4.5/master in the meanwhile.
> 
> Harikrishna Patnala wrote:
> Thanks Rohit, I'll put github PR for 4.4 branch

Maybe check with Daan on this as 4.4.2 release/tag is public now. This involves 
DB upgrade/migration paths (just to update the settings and change router ram 
size) so I don't know where you should put the upgrade paths.


- Rohit


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


On Nov. 27, 2014, 9:22 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17941/
> ---
> 
> (Updated Nov. 27, 2014, 9:22 a.m.)
> 
> 
> Review request for cloudstack, Jayapal Reddy, Kishan Kavala, and Rajani 
> Karuturi.
> 
> 
> Bugs: CLOUDSTACK-6075
> https://issues.apache.org/jira/browse/CLOUDSTACK-6075
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6075: Increase the ram size for router service offering 
> Increased the ram size of Internal load balancer vm service offering also
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade442to450.java dc1057f 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java
>  803d3a5 
>   server/src/com/cloud/configuration/Config.java cd0824e 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 
> 9fb47fd 
>   setup/db/db/schema-442to450.sql 107f10c 
> 
> Diff: https://reviews.apache.org/r/17941/diff/
> 
> 
> Testing
> ---
> 
> tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>



Jenkins build is back to stable : simulator-singlerun #707

2014-11-27 Thread jenkins
See 



Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Daan Hoogland
If this contains db upgrade code, where did this go in 4.3? In the
review request I see changes to 442to450 upgrade files so this should
not go in 4.3 or 4.4. What am I missing?

On Thu, Nov 27, 2014 at 11:40 AM, Rohit Yadav  wrote:
>
>
>> On Nov. 27, 2014, 10:15 a.m., Rohit Yadav wrote:
>> > +1
>> > LGTM, if any of the other designated reviewers don't object let's merge 
>> > this on master/4.5; I've already picked/fixed this for 4.3 branch.
>> >
>> > Hari - thanks for the patch, I encourage you to use Github Pull Requests 
>> > in future which I find is less painful than using reviewboard.
>>
>> Rajani Karuturi wrote:
>> and also on 4.4 please. since its already on 4.3, it should goto all 
>> 4.3+ releases.
>>
>> Rohit Yadav wrote:
>> Yes, Hari please send another patch (maybe via Github PR) for 4.4 branch 
>> as well? I'll help merging this on 4.5/master in the meanwhile.
>>
>> Harikrishna Patnala wrote:
>> Thanks Rohit, I'll put github PR for 4.4 branch
>
> Maybe check with Daan on this as 4.4.2 release/tag is public now. This 
> involves DB upgrade/migration paths (just to update the settings and change 
> router ram size) so I don't know where you should put the upgrade paths.
>
>
> - Rohit
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17941/#review63196
> ---
>
>
> On Nov. 27, 2014, 9:22 a.m., Harikrishna Patnala wrote:
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/17941/
>> ---
>>
>> (Updated Nov. 27, 2014, 9:22 a.m.)
>>
>>
>> Review request for cloudstack, Jayapal Reddy, Kishan Kavala, and Rajani 
>> Karuturi.
>>
>>
>> Bugs: CLOUDSTACK-6075
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6075
>>
>>
>> Repository: cloudstack-git
>>
>>
>> Description
>> ---
>>
>> CLOUDSTACK-6075: Increase the ram size for router service offering
>> Increased the ram size of Internal load balancer vm service offering also
>>
>>
>> Diffs
>> -
>>
>>   engine/schema/src/com/cloud/upgrade/dao/Upgrade442to450.java dc1057f
>>   
>> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java
>>  803d3a5
>>   server/src/com/cloud/configuration/Config.java cd0824e
>>   server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 
>> 9fb47fd
>>   setup/db/db/schema-442to450.sql 107f10c
>>
>> Diff: https://reviews.apache.org/r/17941/diff/
>>
>>
>> Testing
>> ---
>>
>> tested locally
>>
>>
>> Thanks,
>>
>> Harikrishna Patnala
>>
>>
>



-- 
Daan


Re: Moving ec2stack and gstack to the cloudstack repos.

2014-11-27 Thread Sebastien Goasguen

On Nov 26, 2014, at 2:09 PM, Chiradeep Vittal  
wrote:

> I’m +1 on this. I hope the original contributors and developers continue to 
> invest energy into maintaining it (rather than hoping that the community 
> comes for free, just as a side-effect of being in ACS).

we were thinking you would help :)

> 
> From: Ian Duffy mailto:i...@ianduffy.ie>>
> Reply-To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Date: Wednesday, November 26, 2014 at 4:46 AM
> To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Subject: Re: Moving ec2stack and gstack to the cloudstack repos.
> 
> I think unit tests are great for type checking and the like, but are
> there any integration tests?
> 
> At the moment there aren't any, we could add some using eutester very
> easily and chain it onto the current CI tasks. As Sebastien has mentioned
> earlier in this thread he has already looked at doing this a little bit.
> 
> Not to sound tit-for-tat but awsapi has same issue and has much less unit
> testing.
> 
> Any plans to add any?
> 
> Its not *my personal* immediate plan, but isn't that the beauty of open
> source and community building? The project is open to everybody to
> contribute, if you see value for integration tests to be added and wish to
> do it then go ahead. Its a donation of code, not a we'll supply xyz
> software to do xyz service and be the sole maintainers of it forever. If we
> want things that work we need community(user and dev) support, want and
> time.
> 
> For me EC2Stack had two primary goals:
> 
> 1) Make contributing easy, we wanted to produce clean(ish) code that was
> easily extendable by the community so we could get some support if/when it
> takes off. AWSAPI is a bit terrifying to look at, there's a large amount of
> auto generated code and its a bit scary at first.
> 
> In brief to add a new API command:
>- Open controllers.py, add a new API call into the actions object: e.g.
> 'AttachVolume': volumes.attach_volume,
> - Head over to the referenced module/function and fill it out e.g.
> https://github.com/BroganD1993/ec2stack/blob/master/ec2stack/providers/cloudstack/volumes.py
> - Done.
> 
> 2) Make it portable. We didn't want the AWS compatibility layer to always
> have to be hosted by the Cloudstack provider. We wanted the flexibility to
> use it against any Cloudstack 4.0.0> API. This was a success and we
> successfully use EC2Stack against ExoScale as shown in the earlier
> referenced screencast.
> 
> Hope this answers your questions,
> 
> Ian
> 
> 
> On 26 November 2014 at 02:47, ChunFeng 
> mailto:chunf...@domolo.com>> wrote:
> 
> hi all,
> 
> 
> I need help for  a clean picture about  the umbrella projects of
> cloudstack:
> such as :
> 1. the umbrella project links in cloudstack.org homepage
> 2. the source code structure and relations with cloudstack source code in
> git repos.
> 3. the rules for us to agree one as umbrella projects
> 
> 
> 
> BTW,  is there any others umbrella proejcts as cloudmonkey ?
> 
> 
> --
> Regards,
> 
> 
> ChunFeng
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- Original --
> From:  "Sebastien Goasguen"mailto:run...@gmail.com>>;
> Date:  Tue, Nov 25, 2014 06:29 AM
> To:  "dev"mailto:dev@cloudstack.apache.org>>;
> 
> Subject:  Re: Moving ec2stack and gstack to the cloudstack repos.
> 
> 
> 
> On Nov 24, 2014, at 5:05 PM, Chiradeep Vittal 
> mailto:chiradeep.vit...@citrix.com>>
> wrote:
> 
>> I do see a bug fix this year from Likitha  and the fact that Hugo etc
> are making fixes is positive as well.
>> But, the end state we desire is (a) good AWSAPI implementation with
> automated tests, not (b) 2 AWSAPI implementations with no tests!
>> 
> 
> time for bed here, but to keep the conversation going, couple things:
> 
> Hugo is fixing coverity issues kind of automatically, I don't think it
> represents a need.
> One fix from Likitha and one applied patch from me in a year is really
> slim.
> 
> We don't test the current awsapi during the release process or upgrade, so
> I actually have no clue if it's working with 4.3 and 4.4.
> 
> Right now I don't see tests for the current awsapi, at least not on
> jenkins.buildacloud.org.
> Current awsapi also includes S3 stuff which I think we can all agree is
> confusing and unused since it's really an interface to an NFS store and not
> a distributed object store.
> 
> So the choice for me is between:
> 
> -current awsapi, not clearly maintained, without tests and which state in
> the release is unknown
> 
> and
> 
> -a new implementation < 6 months old, smaller code base, up to date with
> AWS version number, tested manually with boto, eutester and awscli and with
> 99% unit test coverage.
> 
> 
>> —
>> Chiradeep
>> 
>> From: Sebastien Goasguen 
>> mailto:run...@gmail.com>>
>> Reply-To: 
>> "dev@cloudstack.apache.org

[QUESTION] @ReflectionUse

2014-11-27 Thread Daan Hoogland
H Kelven (or others),

What are the plans with this annotation, ReflectionUse. Is there to be
an implementation or folow up or is it maybe just there to ignore?

-- 
Daan


Re: Review Request 25585: [CLOUDSTACK-2823] SystemVMs start fail on CentOS 6.4

2014-11-27 Thread Rohit Yadav

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


Thanks for your contribution. It failed for me on 4.3, but I manually fixed it 
and committed on 4.3 branch.
Please consider using Github Pull Request in future as they are less painful 
for many of us helping with reviews and merging patches back to ACS branches.

commit 0a935a336ebf9dcc1c3b25a56f629bb9a217b56f
Author: David Bierce 
Date:   Thu Nov 27 16:50:51 2014 +0530

CLOUDSTACK-2823: Loop through cmdline when patching routers

Backported from https://reviews.apache.org/r/25585/diff which did not merge
this fix on 4.3 branch. Occasionally the while loop can exit with no data 
(Probably
 recieving an EOF) before receiveing CMDline data from the certial port.
Continue looping until cmdline is populated

Signed-off-by: Rohit Yadav 

- Rohit Yadav


On Sept. 13, 2014, 1:01 a.m., David Bierce wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25585/
> ---
> 
> (Updated Sept. 13, 2014, 1:01 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> SystemVMs start fail on CentOS 6
> 
> 
> Diffs
> -
> 
>   systemvm/patches/debian/config/etc/init.d/cloud-early-config 9152df2 
> 
> Diff: https://reviews.apache.org/r/25585/diff/
> 
> 
> Testing
> ---
> 
> Code patch applied to Systemvm.iso and cloud-early inside the systemvm 
> template.  Routers start consitently after patched.
> 
> Tested against cloudstack 4.2.1
> Centos 6.4
> 
> Patch is against 4.3 since 4.2+ is effected by the issue.
> 
> 
> File Attachments
> 
> 
> Updated Patch which includes a sleep
>   
> https://reviews.apache.org/media/uploaded/files/2014/09/13/c612e257-c83e-4a8e-8970-44d078838db6__patch.diff
> 
> 
> Thanks,
> 
> David Bierce
> 
>



Re: Review Request 25585: [CLOUDSTACK-2823] SystemVMs start fail on CentOS 6.4

2014-11-27 Thread Rohit Yadav


> On Nov. 27, 2014, 11:26 a.m., Rohit Yadav wrote:
> > Thanks for your contribution. It failed for me on 4.3, but I manually fixed 
> > it and committed on 4.3 branch.
> > Please consider using Github Pull Request in future as they are less 
> > painful for many of us helping with reviews and merging patches back to ACS 
> > branches.
> > 
> > commit 0a935a336ebf9dcc1c3b25a56f629bb9a217b56f
> > Author: David Bierce 
> > Date:   Thu Nov 27 16:50:51 2014 +0530
> > 
> > CLOUDSTACK-2823: Loop through cmdline when patching routers
> > 
> > Backported from https://reviews.apache.org/r/25585/diff which did not 
> > merge
> > this fix on 4.3 branch. Occasionally the while loop can exit with no 
> > data (Probably
> >  recieving an EOF) before receiveing CMDline data from the certial port.
> > Continue looping until cmdline is populated
> > 
> > Signed-off-by: Rohit Yadav 

On 4.4;
commit 9d7624f6acac104415ae64d7c7126b5771141d8e
Author: David Bierce 
Date:   Fri Sep 12 10:52:29 2014 -0500

Occasionally the while loop can exit with no data (Probably recieving an 
EOF) before receiveing CMDline data from the certial port. Continue looping 
until cmdline is populated

Signed-off-by: Rohit Yadav 


- Rohit


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


On Sept. 13, 2014, 1:01 a.m., David Bierce wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25585/
> ---
> 
> (Updated Sept. 13, 2014, 1:01 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> SystemVMs start fail on CentOS 6
> 
> 
> Diffs
> -
> 
>   systemvm/patches/debian/config/etc/init.d/cloud-early-config 9152df2 
> 
> Diff: https://reviews.apache.org/r/25585/diff/
> 
> 
> Testing
> ---
> 
> Code patch applied to Systemvm.iso and cloud-early inside the systemvm 
> template.  Routers start consitently after patched.
> 
> Tested against cloudstack 4.2.1
> Centos 6.4
> 
> Patch is against 4.3 since 4.2+ is effected by the issue.
> 
> 
> File Attachments
> 
> 
> Updated Patch which includes a sleep
>   
> https://reviews.apache.org/media/uploaded/files/2014/09/13/c612e257-c83e-4a8e-8970-44d078838db6__patch.diff
> 
> 
> Thanks,
> 
> David Bierce
> 
>



Re: Review Request 28511: CLOUDSTACK-7412: Can't create proper template from VM on S3 secondary storage environment

2014-11-27 Thread Rajani Karuturi

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

Ship it!


Ship It!

- Rajani Karuturi


On Nov. 27, 2014, 10:38 a.m., Hiroki Ohashi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28511/
> ---
> 
> (Updated Nov. 27, 2014, 10:38 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-7412
> https://issues.apache.org/jira/browse/CLOUDSTACK-7412
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> [Abstract]
> 
> Root cause of this issue is a way to handle cache using S3 as
> Secondary Storage.
> 
> When CloudStack uploads a disk image on Primary Storage(PS) to
> Secondary Storage(SS), it caches the disk image on Secondary Staging
> Store(SSS). This is a bug.
> 
> CloudStack uses disk image cache every time if the cache exists. For
> this behavior, the old cache on SSS will be uploaded as a template
> though a CloudStack user creates the template from a newer disk image
> on PS than the cache.
> 
> So, we fixed this issue in a way that CloudStack deletes the cache on
> SSS after CloudStack uploads disk image to SS.
> 
> 
> [Details]
> 
> Process of handling cache is different between copy from SS to
> PS(download) and copy from PS to SS(upload).
> 
> * Downloading a disk image from SS to PS
> 
> This is the case that a CloudStack user creates an instance from a
> template. CloudStack caches the image on SSS.
> 
> * Uploading a disk image from PS to SS
> 
> This is the case that a CloudStack user creates a template from a disk
> image of an instance. CloudStack shouldn't cache a disk image because
> it usually happens that a cache image is older than a volume of an
> instance.
> 
> However, there is a bug in branch condition about post process of
> uploading a disk image. Then CloudStack doesn't delete the disk image
> on SSS.
> 
> CloudStack uses a common method to copy a disk image between PS and SS
> for upload and download. The method includes post process of disk
> image cache.
> 
> As a part of post process, it is judged whether a disk image on SSS is
> used as cache or not in this method:
> 
>   a. Delete a disk image as upload procedure
> 
>   b. Delete a disk image to handle errors
> 
>   c. Cache a disk image as download procedure
> 
> In case of uploading a disk image, branch-a should be selected. But
> branch-c is always selected by the condition bug. As a result, a disk
> image is left on SSS and used as cache next time a CloudStack user
> creates a template from an instance.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/datamotion/src/org/apache/cloudstack/storage/motion/AncientDataMotionStrategy.java
>  d6759cb 
> 
> Diff: https://reviews.apache.org/r/28511/diff/
> 
> 
> Testing
> ---
> 
> Items below are confirmed.
> 
> - A template created from an instance reflects a volume of the instance.
> - No cache file exists on NFS secondary staging store.
> - No cache entry exists on template_store_ref.
> 
> We use this patch in our environment.
> 
> 
> Thanks,
> 
> Hiroki Ohashi
> 
>



Re: Review Request 24779: [CLOUDSTACK-6254] Template disappears when download cleanup

2014-11-27 Thread Rohit Yadav


> On Nov. 20, 2014, 6:33 p.m., edison su wrote:
> > seems it's already checked into master and 4.5 by Nitin? see commit: 
> > 5393387bbd4e2d3659fb0c7171e6ff347ad6a07b
> 
> David Bierce wrote:
> This was a backport to 4.2 and 4.3

David, the applies cleanly on 4.2 so I've merged it but it fails on 4.3. Also, 
it would be great if you can consider sending Github PR :)

Can you create a new patch for 4.3?


This is from 4.2:
commit 7edde4a5c7d849f5c9184972f8d4bc1f79770f65
Author: David Bierce 
Date:   Wed Aug 27 09:31:18 2014 -0500

PATCH: CLOUDSTACK-6254

Fixes the cleanup process to only remove the Template symlink, instead of 
delete the template from Secondary Storage.

Signed-off-by: Rohit Yadav 


- Rohit


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


On Aug. 27, 2014, 3:46 p.m., David Bierce wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24779/
> ---
> 
> (Updated Aug. 27, 2014, 3:46 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-6254
> https://issues.apache.org/jira/browse/CLOUDSTACK-6254
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> PATCH] This is a quick stab at fixing a dataloss bug.  The ultimate
>  solution is to refactor UploadManager to not use any deprecated code. It
>  appears there is still code left over that uses the UploadVO/Dao which no
>  long contains data about URL transfers.  This method was hardcoded to always
>  pass Upload.Type.VOLUME as part of cleanup which was causing templates to be
>  removed entirely from secondary storage not just the symlink on secondary
>  storage.
> 
> Rather than try to refactor all of it out, this puts
> logic for determining if the cleanup task is for a volume or a template
> by doing a lookup on the URL.  It is a duplication of the same logic
> from the calling method but is a very minimal code change until the
> large problem is fixed.
> 
> 
> Diffs
> -
> 
>   
> engine/api/src/org/apache/cloudstack/storage/image/datastore/ImageStoreEntity.java
>  7ebfd0d 
>   
> engine/storage/image/src/org/apache/cloudstack/storage/image/store/ImageStoreImpl.java
>  7bbe324 
>   
> engine/storage/src/org/apache/cloudstack/storage/image/BaseImageStoreDriverImpl.java
>  2905f08 
>   
> engine/storage/src/org/apache/cloudstack/storage/image/ImageStoreDriver.java 
> 444a6c7 
>   
> plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
>  4796653 
>   server/src/com/cloud/storage/StorageManagerImpl.java 2a79b0c 
> 
> Diff: https://reviews.apache.org/r/24779/diff/
> 
> 
> Testing
> ---
> 
> On Cloudstack 4.2 4.3
> Set cleanupurl to 30 seconds.  Downloaded a template, cleanup remvoed it from 
> database, didn't remove the template.
> Downloaded Volume, volume was cleaned up from secondary stoage and database.
> 
> 
> Thanks,
> 
> David Bierce
> 
>



Re: Review Request 28511: CLOUDSTACK-7412: Can't create proper template from VM on S3 secondary storage environment

2014-11-27 Thread Rajani Karuturi


> On Nov. 27, 2014, 11:30 a.m., Rajani Karuturi wrote:
> > Ship It!

Thanks for the detailed explanation and the patch. I will push this to the 
relevant branches.


- Rajani


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


On Nov. 27, 2014, 10:38 a.m., Hiroki Ohashi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28511/
> ---
> 
> (Updated Nov. 27, 2014, 10:38 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-7412
> https://issues.apache.org/jira/browse/CLOUDSTACK-7412
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> [Abstract]
> 
> Root cause of this issue is a way to handle cache using S3 as
> Secondary Storage.
> 
> When CloudStack uploads a disk image on Primary Storage(PS) to
> Secondary Storage(SS), it caches the disk image on Secondary Staging
> Store(SSS). This is a bug.
> 
> CloudStack uses disk image cache every time if the cache exists. For
> this behavior, the old cache on SSS will be uploaded as a template
> though a CloudStack user creates the template from a newer disk image
> on PS than the cache.
> 
> So, we fixed this issue in a way that CloudStack deletes the cache on
> SSS after CloudStack uploads disk image to SS.
> 
> 
> [Details]
> 
> Process of handling cache is different between copy from SS to
> PS(download) and copy from PS to SS(upload).
> 
> * Downloading a disk image from SS to PS
> 
> This is the case that a CloudStack user creates an instance from a
> template. CloudStack caches the image on SSS.
> 
> * Uploading a disk image from PS to SS
> 
> This is the case that a CloudStack user creates a template from a disk
> image of an instance. CloudStack shouldn't cache a disk image because
> it usually happens that a cache image is older than a volume of an
> instance.
> 
> However, there is a bug in branch condition about post process of
> uploading a disk image. Then CloudStack doesn't delete the disk image
> on SSS.
> 
> CloudStack uses a common method to copy a disk image between PS and SS
> for upload and download. The method includes post process of disk
> image cache.
> 
> As a part of post process, it is judged whether a disk image on SSS is
> used as cache or not in this method:
> 
>   a. Delete a disk image as upload procedure
> 
>   b. Delete a disk image to handle errors
> 
>   c. Cache a disk image as download procedure
> 
> In case of uploading a disk image, branch-a should be selected. But
> branch-c is always selected by the condition bug. As a result, a disk
> image is left on SSS and used as cache next time a CloudStack user
> creates a template from an instance.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/datamotion/src/org/apache/cloudstack/storage/motion/AncientDataMotionStrategy.java
>  d6759cb 
> 
> Diff: https://reviews.apache.org/r/28511/diff/
> 
> 
> Testing
> ---
> 
> Items below are confirmed.
> 
> - A template created from an instance reflects a volume of the instance.
> - No cache file exists on NFS secondary staging store.
> - No cache entry exists on template_store_ref.
> 
> We use this patch in our environment.
> 
> 
> Thanks,
> 
> Hiroki Ohashi
> 
>



Re: Review Request 20518: CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings

2014-11-27 Thread Rohit Yadav

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


Hi Hari, should we backport this to 4.3? If yes, please send a patch. Thanks.

- Rohit Yadav


On Nov. 25, 2014, 6:06 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20518/
> ---
> 
> (Updated Nov. 25, 2014, 6:06 a.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Rajani Karuturi.
> 
> 
> Bugs: CLOUDSTACK-6465
> https://issues.apache.org/jira/browse/CLOUDSTACK-6465
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings 
> 
> 
> Diffs
> -
> 
>   plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 
> 7c23699 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
>  4f24882 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  e3bfbe5 
>   server/src/com/cloud/configuration/Config.java 5ac0e90 
> 
> Diff: https://reviews.apache.org/r/20518/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>



Re: Review Request 28511: CLOUDSTACK-7412: Can't create proper template from VM on S3 secondary storage environment

2014-11-27 Thread Rajani Karuturi


> On Nov. 27, 2014, 11:30 a.m., Rajani Karuturi wrote:
> > Ship It!
> 
> Rajani Karuturi wrote:
> Thanks for the detailed explanation and the patch. I will push this to 
> the relevant branches.

4.3: 0e0827f07c47289dc210dd50551c4c6df26d0573
4.4: d15033675b05a116905d5b19c697a1ef7bf52aaf
4.5: 0f8f6eff2c6e17594d042a3b9009e1c3a0c56aa6
4.6/master: 9d31e59d5b54ef64475e6e8ea36c3e2fc2e7f379


- Rajani


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


On Nov. 27, 2014, 10:38 a.m., Hiroki Ohashi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28511/
> ---
> 
> (Updated Nov. 27, 2014, 10:38 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-7412
> https://issues.apache.org/jira/browse/CLOUDSTACK-7412
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> [Abstract]
> 
> Root cause of this issue is a way to handle cache using S3 as
> Secondary Storage.
> 
> When CloudStack uploads a disk image on Primary Storage(PS) to
> Secondary Storage(SS), it caches the disk image on Secondary Staging
> Store(SSS). This is a bug.
> 
> CloudStack uses disk image cache every time if the cache exists. For
> this behavior, the old cache on SSS will be uploaded as a template
> though a CloudStack user creates the template from a newer disk image
> on PS than the cache.
> 
> So, we fixed this issue in a way that CloudStack deletes the cache on
> SSS after CloudStack uploads disk image to SS.
> 
> 
> [Details]
> 
> Process of handling cache is different between copy from SS to
> PS(download) and copy from PS to SS(upload).
> 
> * Downloading a disk image from SS to PS
> 
> This is the case that a CloudStack user creates an instance from a
> template. CloudStack caches the image on SSS.
> 
> * Uploading a disk image from PS to SS
> 
> This is the case that a CloudStack user creates a template from a disk
> image of an instance. CloudStack shouldn't cache a disk image because
> it usually happens that a cache image is older than a volume of an
> instance.
> 
> However, there is a bug in branch condition about post process of
> uploading a disk image. Then CloudStack doesn't delete the disk image
> on SSS.
> 
> CloudStack uses a common method to copy a disk image between PS and SS
> for upload and download. The method includes post process of disk
> image cache.
> 
> As a part of post process, it is judged whether a disk image on SSS is
> used as cache or not in this method:
> 
>   a. Delete a disk image as upload procedure
> 
>   b. Delete a disk image to handle errors
> 
>   c. Cache a disk image as download procedure
> 
> In case of uploading a disk image, branch-a should be selected. But
> branch-c is always selected by the condition bug. As a result, a disk
> image is left on SSS and used as cache next time a CloudStack user
> creates a template from an instance.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/datamotion/src/org/apache/cloudstack/storage/motion/AncientDataMotionStrategy.java
>  d6759cb 
> 
> Diff: https://reviews.apache.org/r/28511/diff/
> 
> 
> Testing
> ---
> 
> Items below are confirmed.
> 
> - A template created from an instance reflects a volume of the instance.
> - No cache file exists on NFS secondary staging store.
> - No cache entry exists on template_store_ref.
> 
> We use this patch in our environment.
> 
> 
> Thanks,
> 
> Hiroki Ohashi
> 
>



Re: Review Request 24779: [CLOUDSTACK-6254] Template disappears when download cleanup

2014-11-27 Thread Rohit Yadav


> On Nov. 20, 2014, 6:33 p.m., edison su wrote:
> > seems it's already checked into master and 4.5 by Nitin? see commit: 
> > 5393387bbd4e2d3659fb0c7171e6ff347ad6a07b
> 
> David Bierce wrote:
> This was a backport to 4.2 and 4.3
> 
> Rohit Yadav wrote:
> David, the applies cleanly on 4.2 so I've merged it but it fails on 4.3. 
> Also, it would be great if you can consider sending Github PR :)
> 
> Can you create a new patch for 4.3?
> 
> 
> This is from 4.2:
> commit 7edde4a5c7d849f5c9184972f8d4bc1f79770f65
> Author: David Bierce 
> Date:   Wed Aug 27 09:31:18 2014 -0500
> 
> PATCH: CLOUDSTACK-6254
> 
> Fixes the cleanup process to only remove the Template symlink, 
> instead of delete the template from Secondary Storage.
> 
> Signed-off-by: Rohit Yadav 

Just checked, fix is already in 4.3 by Edison. Thanks.


- Rohit


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


On Aug. 27, 2014, 3:46 p.m., David Bierce wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24779/
> ---
> 
> (Updated Aug. 27, 2014, 3:46 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-6254
> https://issues.apache.org/jira/browse/CLOUDSTACK-6254
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> PATCH] This is a quick stab at fixing a dataloss bug.  The ultimate
>  solution is to refactor UploadManager to not use any deprecated code. It
>  appears there is still code left over that uses the UploadVO/Dao which no
>  long contains data about URL transfers.  This method was hardcoded to always
>  pass Upload.Type.VOLUME as part of cleanup which was causing templates to be
>  removed entirely from secondary storage not just the symlink on secondary
>  storage.
> 
> Rather than try to refactor all of it out, this puts
> logic for determining if the cleanup task is for a volume or a template
> by doing a lookup on the URL.  It is a duplication of the same logic
> from the calling method but is a very minimal code change until the
> large problem is fixed.
> 
> 
> Diffs
> -
> 
>   
> engine/api/src/org/apache/cloudstack/storage/image/datastore/ImageStoreEntity.java
>  7ebfd0d 
>   
> engine/storage/image/src/org/apache/cloudstack/storage/image/store/ImageStoreImpl.java
>  7bbe324 
>   
> engine/storage/src/org/apache/cloudstack/storage/image/BaseImageStoreDriverImpl.java
>  2905f08 
>   
> engine/storage/src/org/apache/cloudstack/storage/image/ImageStoreDriver.java 
> 444a6c7 
>   
> plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
>  4796653 
>   server/src/com/cloud/storage/StorageManagerImpl.java 2a79b0c 
> 
> Diff: https://reviews.apache.org/r/24779/diff/
> 
> 
> Testing
> ---
> 
> On Cloudstack 4.2 4.3
> Set cleanupurl to 30 seconds.  Downloaded a template, cleanup remvoed it from 
> database, didn't remove the template.
> Downloaded Volume, volume was cleaned up from secondary stoage and database.
> 
> 
> Thanks,
> 
> David Bierce
> 
>



Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Rohit Yadav
Daan,

On Thu, Nov 27, 2014 at 4:17 PM, Daan Hoogland 
wrote:

> If this contains db upgrade code, where did this go in 4.3? In the
> review request I see changes to 442to450 upgrade files so this should
> not go in 4.3 or 4.4. What am I missing?
>

For 4.3, the upgrade path (it's just data migration no schema changes so
easily backportable) is from 4.3.1 to 4.3.2 in Upgrade431to432 class.

The fix simply goes through existing VRs and updates their RAM size, no
schema changes here only data migrations.

Regards.


Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Daan Hoogland
ok, so that would go in 442to443?

On Thu, Nov 27, 2014 at 12:52 PM, Rohit Yadav  wrote:
> Daan,
>
> On Thu, Nov 27, 2014 at 4:17 PM, Daan Hoogland 
> wrote:
>>
>> If this contains db upgrade code, where did this go in 4.3? In the
>> review request I see changes to 442to450 upgrade files so this should
>> not go in 4.3 or 4.4. What am I missing?
>
>
> For 4.3, the upgrade path (it's just data migration no schema changes so
> easily backportable) is from 4.3.1 to 4.3.2 in Upgrade431to432 class.
>
> The fix simply goes through existing VRs and updates their RAM size, no
> schema changes here only data migrations.
>
> Regards.
>



-- 
Daan


[GitHub] cloudstack pull request: Merge 4.5 to master

2014-11-27 Thread karuturi
Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/45#issuecomment-64782805
  
looks like it is from this commit 91d448ff4576086b875436a6a002e0be32352657 
(7 days ago) which came after your commit 
a52fd08a142edc6a62e43838113bc504c225fa11 (14 days ago)
But, it looks right in the current version of the file [1]. confused..
[1] 
https://github.com/apache/cloudstack/blob/4.5/engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java#L221
  


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


Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Rohit Yadav
On Thu, Nov 27, 2014 at 5:30 PM, Daan Hoogland 
wrote:

> ok, so that would go in 442to443?
>

Yes, but do you plan to do a 4.4.3? The whole debate around maintaining 4.3
vs 4.4 comes down to stakeholder's interests, you've shared that you may
not want to put a lot of efforts on 4.4 branch since 4.5.0 is around but if
I'm mistaken and since you're the release manager you should backport
changes applicable on 4.4 and do a 4.4.3 release. That would be great for
4.4.x users.

Before the patch could be ported, Hari will need to use an empty upgrade
path from 4.4.2 to 4.4.3 and change versions in pom files etc. Hari let me
know if you can do that in your backport or if Daan or I need to add that
for you. Thanks.


>
> On Thu, Nov 27, 2014 at 12:52 PM, Rohit Yadav  wrote:
> > Daan,
> >
> > On Thu, Nov 27, 2014 at 4:17 PM, Daan Hoogland 
> > wrote:
> >>
> >> If this contains db upgrade code, where did this go in 4.3? In the
> >> review request I see changes to 442to450 upgrade files so this should
> >> not go in 4.3 or 4.4. What am I missing?
> >
> >
> > For 4.3, the upgrade path (it's just data migration no schema changes so
> > easily backportable) is from 4.3.1 to 4.3.2 in Upgrade431to432 class.
> >
> > The fix simply goes through existing VRs and updates their RAM size, no
> > schema changes here only data migrations.
> >
> > Regards.
> >
>
>
>
> --
> Daan
>


Re: [DISCUSS] LTS Releases

2014-11-27 Thread Andrei Mikhailovsky
ChunFeng, 

I think as long as there is a change to the current efforts it will improve the 
stability of the product. At the moment, it is clearly not working very well 
for the end users, otherwise, we would not be discussing this topic. 

As to answer your previous concerns, I agree, having a 5 year support is not an 
option for CloudStack, especially taking into considering the dynamic 
development and the current maturity of the product. It has to be more 
frequent. Perhaps the LTS equivalent version should be released with every 
two/three releases of the non-LTS release. Two/three release cycles should be 
enough time to community test the new features and correct the bugs for the 
stable release. 

IMHO the naming concept is less important as long as the documentation and 
release notes make a distinction. Having fancy letters at the end of the 
product name is a marketing/PR/sales job ). Some companies use LTS, others GA, 
others simply use odd/even version numbering to distinguish between the 
production and testing releases. 

One issue that I foresee with the LTS / non-LTS release cycles is that the 
non-LTS releases might have a smaller userbase as a lot of users want to have a 
production ready system and they perhaps be less likely to install and test the 
non-LTS release. 

Andrei 
- Original Message -

> From: "ChunFeng" 
> To: "dev" 
> Sent: Thursday, 27 November, 2014 10:36:46 AM
> Subject: Re: [DISCUSS] LTS Releases

> hi,

> LTS means Long Term Support , for ubuntu means 5 years support for
> both desktop and server distributions. If we adopt to release
> cloudstack's LTS version , how many years should we support ? 5
> years ? of course can not accept ! even 3 years may be too long to
> old for support as a IAAS management software . 2 or 1 years ? this
> should not call LTS version .

> Second ,the time span for ubuntu release next new LTS version is
> every 2 years . Then , consider the first question , what kind of
> years interval should we take?

> Third, even if the above two issues is false positive , how should we
> name the LTS release version's ? such as: CloudStack-LTS-4.x-201401
> , CloudStack-LTS-4.X-201402 etc , this may cause a more confuse to
> end-users to make a right choice .

> IMO , if a software could automatically upgrade to newer version by
> just one or fews clickes , which kind software is suitable for LTS
> release mechanism , otherwise the cost for end-user to upgrade from
> the older one to newer which will be same as user to choice next
> release version, ie reinstall .

> as Hugo, sebgoa and Andrija said: " we need a WAY to focus here on
> FIXING, POLISHING ", "then LTS becomes less important" and " I’m not
> in favor of supporting LTS releases as a community. "

> --

> Regards,

> ChunFeng

> -- Original --
> From: "sebgoa";
> Date: Thu, Nov 27, 2014 05:14 PM
> To: "dev";

> Subject: Re: [DISCUSS] LTS Releases

> On Nov 27, 2014, at 9:01 AM, Andrija Panic 
> wrote:

> > my 2 cents again:
> >
> > Whether we have this LTS release or not - is not just about having
> > release
> > - we need a WAY to focus here on FIXING, POLISHING product and more
> > important to stimulate/make developers interested in doing so.
> > If this was company owned product, it would be very easy to set
> > goals, and
> > then speak to devs, fix this, fix that.
> >
> > Since this is ofcourse comunity based product - we need some way of
> > focusing on fixing the stuff, and really stop adding features
> > (maybe not
> > completely quit adding features, but...)
> >
> > One important note, and possible scenario - just by having LTS
> > release, but
> > still having majority of developer working on non-LTS release
> > (ading new
> > features) is a big probability, and then we are back to zero with
> > our
> > progress, so I guess this is also an option/problem that we need to
> > consider.
> >
> > I have a very nice experience with CloudStack so far (in general,
> > except
> > being frustrated by some childish problems) - if this was all
> > polished, and
> > documentation complete - I'm 100% sure there will be no better
> > cloud
> > project on the market any time soon, and I really mean it !
> >
> > It is my wish (and I hope of others) to see CloudStack migrate from
> > #CloudstackWorks to #CloudStackRocks for the next CCC and I think
> > this is
> > VERY much possible.
> >

> Thanks for this Andrija, it made my morning :)

> I am of the opinion that if/when we improve our committing habits, we
> will have high confidence that every bug fixed in a release branch
> will also be fixed in the next release.

> Little process changing that we are making, like using github PR,
> merging back to master etc, will help us get into somewhat of a
> rolling release.

> If we take great care with our upgrade paths and avoid regressions
> then LTS becomes less important. We have had some challenges with
> 4.4 and the fact that 4.3 is solid 

RE: Differences in schema-442to450.sql between 4.5 and master

2014-11-27 Thread Kishan Kavala
Added commit 1091d458 to 4.5 branch.

Regards,
Kishan

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Thursday, November 27, 2014 3:14 PM
To: dev
Subject: Re: Differences in schema-442to450.sql between 4.5 and master

Please take note that people that made the change probably made it to 
schema-441to450.sql which I renamed.

On Thu, Nov 27, 2014 at 10:32 AM, Hugo Trippaers  wrote:
> See this diff:
> Hugos-MacBook-Pro-7:cloudstack hugo (master)$ git diff master 4.5 
> setup/db/db/schema-442to450.sql diff --git 
> a/setup/db/db/schema-442to450.sql b/setup/db/db/schema-442to450.sql 
> index f84bca6..083943b 100644
> --- a/setup/db/db/schema-442to450.sql
> +++ b/setup/db/db/schema-442to450.sql
> @@ -753,8 +753,6 @@ INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, 
> category_id, display_name, crea  INSERT IGNORE INTO `cloud`.`guest_os` 
> (id, uuid, category_id, display_name, created) VALUES (247, UUID(), 3, 
> 'Oracle Linux 7', utc_timestamp());  INSERT IGNORE INTO 
> `cloud`.`guest_os` (id, uuid, category_id, display_name, created) 
> VALUES (248, UUID(), 1, 'CentOS 6 (32-bit)', utc_timestamp());  INSERT 
> IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
> created) VALUES (249, UUID(), 1, 'CentOS 6 (64-bit)', 
> utc_timestamp()); -INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, 
> category_id, display_name, created) VALUES (250, UUID(), 3, 'Oracle 
> Enterprise Linux 6.5 (32-bit)', utc_timestamp()); -INSERT IGNORE INTO 
> `cloud`.`guest_os` (id, uuid, category_id, display_name, created) 
> VALUES (251, UUID(), 3, 'Oracle Enterprise Linux 6.5 (64-bit)', 
> utc_timestamp());
>
>  INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
> (uuid,hypervisor_type, hypervisor_version, guest_os_name, guest_os_id, 
> created, is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT 
> IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, 
> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0 @@ -837,8 +835,6 
> @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
> (uuid,hypervisor_type, hypervis  INSERT IGNORE INTO 
> `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, 
> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, 
> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, 
> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0 -INSERT IGNORE 
> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, 
> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0 -INSERT IGNORE 
> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, 
> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, 
> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, 
> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
> hypervisor_version, guest_os_name, guest_os_id, created, 
> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0 @@ -935,16 +931,6 
> @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
> (uuid,hypervisor_type, hypervis
>
>  INSERT IGNORE INTO `cloud`.`hypervisor_capabilities`(uuid, 
> hypervisor_type, hypervisor_version, max_guests_limit, 
> security_group_enabled, max_data_volumes_limit, storage_motion_sup
>
> -update vlan set vlan_id=concat('vlan://', vlan_id) where vlan_type = 
> "VirtualNetwork" and vlan_id not like "vlan://%";
> -
> -CREATE TABLE `cloud`.`baremetal_rct` (
> -  `id` bigint unsigned UNIQUE AUTO_INCREMENT,
> -  `uuid` varchar(40) UNIQUE NOT NULL,
> -  `url` varchar(2048) NOT NULL,
> -  `rct` text NOT NULL,
> -   PRIMARY KEY (`id`)
> -) ENGINE = InnoDB DEFAULT CHARSET=utf8;
> -
>  --Remove duplicates from guest_os_hypervisor table  DELETE t1 FROM 
> guest_os_hypervisor t1, guest_os_hypervisor t2 WHERE 
> (t1.hypervisor_type = t2.hypervisor_type AND t1.hypervisor_version = 
> t2.hypervisor_version AND t1.guest_os_id =
>
> @@ -958,9 +944,6 @@ ALTER TABLE `cloud`.`user_vm_details` MODIFY 
> `value` VARCHAR(5120);
>
>  UPDATE `cloud`.`host` SET resource = REPLACE(resource, 
> 'com.cloud.hypervisor.xen.resource', 
> 'com.cloud.hypervisor.xenserver.resource') WHERE 
> hypervisor_type='XenServer' AND REMOVED
>
> -INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public, 
> created, t

Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Rajani Karuturi
I dont like the idea of release manager cherry-picking/backporting the
fixes to the release branches.

As a community we are supporting past two releases. ie) at this point we
have to support 4.3 and 4.4
As a developer/contributor, if I feel a bug is relevant for 4.3 I should be
committing it to all the 4.3+ releases. Otherwise it would be a nightmare
for people trying to upgrade later.
If and when a release is required, we should release from that branch.

~Rajani

On Thu, Nov 27, 2014 at 6:13 PM, Rohit Yadav  wrote:

>
> On Thu, Nov 27, 2014 at 5:30 PM, Daan Hoogland 
> wrote:
>
>> ok, so that would go in 442to443?
>>
>
> Yes, but do you plan to do a 4.4.3? The whole debate around maintaining
> 4.3 vs 4.4 comes down to stakeholder's interests, you've shared that you
> may not want to put a lot of efforts on 4.4 branch since 4.5.0 is around
> but if I'm mistaken and since you're the release manager you should
> backport changes applicable on 4.4 and do a 4.4.3 release. That would be
> great for 4.4.x users.
>
> Before the patch could be ported, Hari will need to use an empty upgrade
> path from 4.4.2 to 4.4.3 and change versions in pom files etc. Hari let me
> know if you can do that in your backport or if Daan or I need to add that
> for you. Thanks.
>
>
>>
>> On Thu, Nov 27, 2014 at 12:52 PM, Rohit Yadav 
>> wrote:
>> > Daan,
>> >
>> > On Thu, Nov 27, 2014 at 4:17 PM, Daan Hoogland > >
>> > wrote:
>> >>
>> >> If this contains db upgrade code, where did this go in 4.3? In the
>> >> review request I see changes to 442to450 upgrade files so this should
>> >> not go in 4.3 or 4.4. What am I missing?
>> >
>> >
>> > For 4.3, the upgrade path (it's just data migration no schema changes so
>> > easily backportable) is from 4.3.1 to 4.3.2 in Upgrade431to432 class.
>> >
>> > The fix simply goes through existing VRs and updates their RAM size, no
>> > schema changes here only data migrations.
>> >
>> > Regards.
>> >
>>
>>
>>
>> --
>> Daan
>>
>
>


Jenkins build became unstable: simulator-singlerun #708

2014-11-27 Thread jenkins
See 



Re: Differences in schema-442to450.sql between 4.5 and master

2014-11-27 Thread Hugo Trippaers
Thanks Kishan!

Cheers,

Hugo
> On 27 nov. 2014, at 13:50, Kishan Kavala  wrote:
> 
> Added commit 1091d458 to 4.5 branch.
> 
> Regards,
> Kishan
> 
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
> Sent: Thursday, November 27, 2014 3:14 PM
> To: dev
> Subject: Re: Differences in schema-442to450.sql between 4.5 and master
> 
> Please take note that people that made the change probably made it to 
> schema-441to450.sql which I renamed.
> 
> On Thu, Nov 27, 2014 at 10:32 AM, Hugo Trippaers  wrote:
>> See this diff:
>> Hugos-MacBook-Pro-7:cloudstack hugo (master)$ git diff master 4.5 
>> setup/db/db/schema-442to450.sql diff --git 
>> a/setup/db/db/schema-442to450.sql b/setup/db/db/schema-442to450.sql 
>> index f84bca6..083943b 100644
>> --- a/setup/db/db/schema-442to450.sql
>> +++ b/setup/db/db/schema-442to450.sql
>> @@ -753,8 +753,6 @@ INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, 
>> category_id, display_name, crea  INSERT IGNORE INTO `cloud`.`guest_os` 
>> (id, uuid, category_id, display_name, created) VALUES (247, UUID(), 3, 
>> 'Oracle Linux 7', utc_timestamp());  INSERT IGNORE INTO 
>> `cloud`.`guest_os` (id, uuid, category_id, display_name, created) 
>> VALUES (248, UUID(), 1, 'CentOS 6 (32-bit)', utc_timestamp());  INSERT 
>> IGNORE INTO `cloud`.`guest_os` (id, uuid, category_id, display_name, 
>> created) VALUES (249, UUID(), 1, 'CentOS 6 (64-bit)', 
>> utc_timestamp()); -INSERT IGNORE INTO `cloud`.`guest_os` (id, uuid, 
>> category_id, display_name, created) VALUES (250, UUID(), 3, 'Oracle 
>> Enterprise Linux 6.5 (32-bit)', utc_timestamp()); -INSERT IGNORE INTO 
>> `cloud`.`guest_os` (id, uuid, category_id, display_name, created) 
>> VALUES (251, UUID(), 3, 'Oracle Enterprise Linux 6.5 (64-bit)', 
>> utc_timestamp());
>> 
>> INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
>> (uuid,hypervisor_type, hypervisor_version, guest_os_name, guest_os_id, 
>> created, is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT 
>> IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
>> hypervisor_version, guest_os_name, guest_os_id, created, 
>> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0 @@ -837,8 +835,6 
>> @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
>> (uuid,hypervisor_type, hypervis  INSERT IGNORE INTO 
>> `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
>> hypervisor_version, guest_os_name, guest_os_id, created, 
>> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
>> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
>> hypervisor_version, guest_os_name, guest_os_id, created, 
>> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
>> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
>> hypervisor_version, guest_os_name, guest_os_id, created, 
>> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0 -INSERT IGNORE 
>> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
>> hypervisor_version, guest_os_name, guest_os_id, created, 
>> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0 -INSERT IGNORE 
>> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
>> hypervisor_version, guest_os_name, guest_os_id, created, 
>> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
>> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
>> hypervisor_version, guest_os_name, guest_os_id, created, 
>> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
>> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
>> hypervisor_version, guest_os_name, guest_os_id, created, 
>> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0  INSERT IGNORE 
>> INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
>> hypervisor_version, guest_os_name, guest_os_id, created, 
>> is_user_defined) VALUES (UUID(),'Xenserver', '6.5.0 @@ -935,16 +931,6 
>> @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
>> (uuid,hypervisor_type, hypervis
>> 
>> INSERT IGNORE INTO `cloud`.`hypervisor_capabilities`(uuid, 
>> hypervisor_type, hypervisor_version, max_guests_limit, 
>> security_group_enabled, max_data_volumes_limit, storage_motion_sup
>> 
>> -update vlan set vlan_id=concat('vlan://', vlan_id) where vlan_type = 
>> "VirtualNetwork" and vlan_id not like "vlan://%";
>> -
>> -CREATE TABLE `cloud`.`baremetal_rct` (
>> -  `id` bigint unsigned UNIQUE AUTO_INCREMENT,
>> -  `uuid` varchar(40) UNIQUE NOT NULL,
>> -  `url` varchar(2048) NOT NULL,
>> -  `rct` text NOT NULL,
>> -   PRIMARY KEY (`id`)
>> -) ENGINE = InnoDB DEFAULT CHARSET=utf8;
>> -
>> --Remove duplicates from guest_os_hypervisor table  DELETE t1 FROM 
>> guest_os_hypervisor t1, guest_os_hypervisor t2 WHERE 
>> (t1.hypervisor_type = t2.hypervisor_type AND t1.hypervisor_version = 
>> t2.hypervisor_version AND t1.guest_os_id =
>> 
>> @@ -958,9 +944,6 @@ ALTER TABLE `cloud`.`user_vm_details` MODIFY 
>> `value` VARCHAR(5120);
>> 
>> UPDATE `cloud`.`host` SET resource = REPLACE(resource, 
>> 'com.cloud.hypervisor.xen

[GitHub] cloudstack pull request: Add improved support for packaging CloudS...

2014-11-27 Thread asfgit
Github user asfgit closed the pull request at:

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


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


Jenkins build is still unstable: simulator-singlerun #709

2014-11-27 Thread jenkins
See 



A secure way to reset VMs password

2014-11-27 Thread Alireza Eskandari
HiI viewed the bash script that resets Linux password 
(http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in)It 
seems that it doesn't use a secure way for transferring password string to 
instance.Instances on a shared network can sniff password requests and export 
requested password of other instances.I suggest to use SSL (https) instead of 
plan text.Regards



Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Rohit Yadav
Hi Rajani,

I've already started a thread on user/dev ML around LTS releases, we should
have discussion there.

On Thu, Nov 27, 2014 at 6:26 PM, Rajani Karuturi  wrote:

> I dont like the idea of release manager cherry-picking/backporting the
> fixes to the release branches.
>
> As a community we are supporting past two releases. ie) at this point we
> have to support 4.3 and 4.4
> As a developer/contributor, if I feel a bug is relevant for 4.3 I should
> be committing it to all the 4.3+ releases. Otherwise it would be a
> nightmare for people trying to upgrade later.
> If and when a release is required, we should release from that branch.
>

+1 that's the ideal case and everyone should do it but since I had to
backport more than 90 fixes from 4.4/4.5/master to 4.3 many of us were
clearly not doing that.

In many opensource projects such as Linux, it's common to see different
people maintaining a certain branch or major release. I want to do the same
for 4.3 until a stable 4.5.x or 4.6.x is out that is fairly tested and used
in the wild. Everyone is welcome to do it for any branches they do.

Regards.


>
> ~Rajani
>
> On Thu, Nov 27, 2014 at 6:13 PM, Rohit Yadav  wrote:
>
>>
>> On Thu, Nov 27, 2014 at 5:30 PM, Daan Hoogland 
>> wrote:
>>
>>> ok, so that would go in 442to443?
>>>
>>
>> Yes, but do you plan to do a 4.4.3? The whole debate around maintaining
>> 4.3 vs 4.4 comes down to stakeholder's interests, you've shared that you
>> may not want to put a lot of efforts on 4.4 branch since 4.5.0 is around
>> but if I'm mistaken and since you're the release manager you should
>> backport changes applicable on 4.4 and do a 4.4.3 release. That would be
>> great for 4.4.x users.
>>
>> Before the patch could be ported, Hari will need to use an empty upgrade
>> path from 4.4.2 to 4.4.3 and change versions in pom files etc. Hari let me
>> know if you can do that in your backport or if Daan or I need to add that
>> for you. Thanks.
>>
>>
>>>
>>> On Thu, Nov 27, 2014 at 12:52 PM, Rohit Yadav 
>>> wrote:
>>> > Daan,
>>> >
>>> > On Thu, Nov 27, 2014 at 4:17 PM, Daan Hoogland <
>>> daan.hoogl...@gmail.com>
>>> > wrote:
>>> >>
>>> >> If this contains db upgrade code, where did this go in 4.3? In the
>>> >> review request I see changes to 442to450 upgrade files so this should
>>> >> not go in 4.3 or 4.4. What am I missing?
>>> >
>>> >
>>> > For 4.3, the upgrade path (it's just data migration no schema changes
>>> so
>>> > easily backportable) is from 4.3.1 to 4.3.2 in Upgrade431to432 class.
>>> >
>>> > The fix simply goes through existing VRs and updates their RAM size, no
>>> > schema changes here only data migrations.
>>> >
>>> > Regards.
>>> >
>>>
>>>
>>>
>>> --
>>> Daan
>>>
>>
>>
>


RE: CloudStack Job offering @exoscale

2014-11-27 Thread Octavian Popescu
Just a quick note to confirm that Interoute is indeed hiring as well a 
Cloudstack developer to be based in our London office, feel free to drop me an 
email directly for additional info. I was wondering if maybe we could have a 
separate mailing list for CS-related roles (e.g. j...@cloudstack.apache.org) 
Personally I feel like there's a lot of value in connecting directly job 
seekers with hiring managers and on Linkedin there's just way too much noise 
these days (or maybe I'm just too old school when it comes to technical 
recruiting ;)

Thanks,
Octavian

>-Original Message-
>From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
>Sent: 27 November 2014 09:46
>To: dev@cloudstack.apache.org
>Subject: RE: CloudStack Job offering @exoscale
>
>
>But being such a small community right now, I think its great to see Exoscale
>creating developer roles around Cloudstack and agree, right now, that this is
>the most sensible place to post them  - really good news Antoine.
>At the same time its worth mentioning that ShapeBlue have a number of
>Cloudstack dev & Engineering positions open Shapeblue.com/careers And,
>yes, Interoute are also hiring Cloudstack people
>
>As the jobs market around Cloudstack is clearly developing (what a fantastic
>sign),  long-term, nobody wants to see our dev list getting spammed by
>recruiters, etc - but I also do think it is useful for people in our community 
>to
>see that, if they want, they can develop their careers around ACS May I
>suggest that we encourage people going forward to use the various
>Cloudstack linkedin groups for these sort of subjects - that would keep these
>out of the dev list
>
>Thoughts ?
>
>
>Kind Regards
>Giles
>
>D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com
>
>
>
>
>-Original Message-
>From: sebgoa [mailto:run...@gmail.com]
>Sent: 27 November 2014 07:58
>To: dev@cloudstack.apache.org
>Subject: Fwd: CloudStack Job offering @exoscale
>
>I think this is legitimate on dev@
>
>Note that there are also jobs available at interoute.
>
>Begin forwarded message:
>
>> From: "Coetsier, Antoine" 
>> Subject: CloudStack Job offering @exoscale
>> Date: November 26, 2014 5:20:57 PM GMT+01:00
>> To: "us...@cloudstack.apache.org" 
>> Reply-To: us...@cloudstack.apache.org
>>
>> Hello All,
>>
>> We are looking for a developer that already has some knowledge of
>CloudStack to join our team at Exoscale. Trendy topics about network
>functions/distributed LB in CS for this full time job.
>>
>> This is based in Switzerland of course. The job description is here:
>> https://www.exoscale.ch/jobs/ Get in touch with us at: hr -AT-
>> exoscale.ch
>>
>> Thank you,
>> --
>> Antoine COETSIER – EXOSCALE CEO
>
>Find out more about ShapeBlue and our range of CloudStack related services
>
>IaaS Cloud Design & Buildbuild//>
>CSForge – rapid IaaS deployment
>framework
>CloudStack Consulting
>CloudStack Software Engineeringsoftware-engineering/>
>CloudStack Infrastructure Supportinfrastructure-support/>
>CloudStack Bootcamp Training Coursestraining/>
>
>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 SA Pty Ltd is a
>company registered by The Republic of South Africa and is traded under
>license from Shape Blue Ltd. ShapeBlue is a registered trademark.


Re: A secure way to reset VMs password

2014-11-27 Thread Nux!
+1 on this, Alireza I think it would be best if you submitted a bug in 
https://issues.apache.org/jira/

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Alireza Eskandari" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, 27 November, 2014 14:54:40
> Subject: A secure way to reset VMs password

> HiI viewed the bash script that resets Linux password
> (http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in)It
> seems that it doesn't use a secure way for transferring password string to
> instance.Instances on a shared network can sniff password requests and export
> requested password of other instances.I suggest to use SSL (https) instead of
> plan text.Regards


Re: A secure way to reset VMs password

2014-11-27 Thread Alireza Eskandari
Lucian, I send email here to see developers opinion about this issue and 
discuss about it.I'll open a jira ticket about it soon.Thanks for your "+1" :)
  From: Nux! 
 To: dev@cloudstack.apache.org; Alireza Eskandari  
 Sent: Thursday, November 27, 2014 7:58 PM
 Subject: Re: A secure way to reset VMs password
   
+1 on this, Alireza I think it would be best if you submitted a bug in 
https://issues.apache.org/jira/

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro   

Jenkins build is still unstable: simulator-singlerun #710

2014-11-27 Thread jenkins
See 



Re: [QUESTION] @ReflectionUse

2014-11-27 Thread Min Chen
If I understand this clearly, this annotation was introduced by Kelven to 
prevent people from mistakenly removing those annotated methods if they find 
from IDE that those methods are not explicitly called anywhere. These methods 
are actually invoked through reflection.

Thanks
-min



> On Nov 27, 2014, at 3:21 AM, "Daan Hoogland"  wrote:
> 
> H Kelven (or others),
> 
> What are the plans with this annotation, ReflectionUse. Is there to be
> an implementation or folow up or is it maybe just there to ignore?
> 
> -- 
> Daan


Jenkins build is still unstable: simulator-singlerun #711

2014-11-27 Thread jenkins
See 



Jenkins build is still unstable: simulator-singlerun #712

2014-11-27 Thread jenkins
See 



Re: [JENKINS] Added CentOS 7 slaves

2014-11-27 Thread Erik Weber
On Wed, Nov 26, 2014 at 4:25 PM, Hugo Trippaers  wrote:

> If any one needs something build or tested on CentOS 7 let me know or
> create a build tagged for cloudstack-buildslave-centos7
>
> Cheers,
>
> Hugo
>
> P.S. Still looking for people willing to add slaves to jenkins. What we
> need are one or two fast machines capable of running the simulator tests.



What would describe a fast machine? I'm currently not able to provide
SSD-based machines, but providing CPU and memory shouldn't be a problem.

-- 
Erik


Re: [JENKINS] Added CentOS 7 slaves

2014-11-27 Thread Hugo Trippaers
Erik,

The term fast machine is indeed not very accurate. At the moment most of out 
jobs seem CPU bound, so enough memory (for java) and a fast CPU should make for 
a decent build machine.

If i can add one or two machines that can be used for build, rpm build and 
simulator i would be very happy. Especially the simulator builds need to happen 
far more frequently, but they need a database so are limited to a single run 
per host concurrently. (Until i figure out how to make the database name 
configurable)

Cheers,

Hugo

> On 27 nov. 2014, at 21:57, Erik Weber  wrote:
> 
> On Wed, Nov 26, 2014 at 4:25 PM, Hugo Trippaers  wrote:
> 
>> If any one needs something build or tested on CentOS 7 let me know or
>> create a build tagged for cloudstack-buildslave-centos7
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> P.S. Still looking for people willing to add slaves to jenkins. What we
>> need are one or two fast machines capable of running the simulator tests.
> 
> 
> 
> What would describe a fast machine? I'm currently not able to provide
> SSD-based machines, but providing CPU and memory shouldn't be a problem.
> 
> -- 
> Erik



Jenkins build is still unstable: simulator-singlerun #713

2014-11-27 Thread jenkins
See 



Re: [JENKINS] Added CentOS 7 slaves

2014-11-27 Thread Erik Weber
Should be ok then, send me the public key you want jenkins to authenticate
as, and I'll see what I can do :-)


 --
Erik

On Thu, Nov 27, 2014 at 10:42 PM, Hugo Trippaers  wrote:

> Erik,
>
> The term fast machine is indeed not very accurate. At the moment most of
> out jobs seem CPU bound, so enough memory (for java) and a fast CPU should
> make for a decent build machine.
>
> If i can add one or two machines that can be used for build, rpm build and
> simulator i would be very happy. Especially the simulator builds need to
> happen far more frequently, but they need a database so are limited to a
> single run per host concurrently. (Until i figure out how to make the
> database name configurable)
>
> Cheers,
>
> Hugo
>
> > On 27 nov. 2014, at 21:57, Erik Weber  wrote:
> >
> > On Wed, Nov 26, 2014 at 4:25 PM, Hugo Trippaers 
> wrote:
> >
> >> If any one needs something build or tested on CentOS 7 let me know or
> >> create a build tagged for cloudstack-buildslave-centos7
> >>
> >> Cheers,
> >>
> >> Hugo
> >>
> >> P.S. Still looking for people willing to add slaves to jenkins. What we
> >> need are one or two fast machines capable of running the simulator
> tests.
> >
> >
> >
> > What would describe a fast machine? I'm currently not able to provide
> > SSD-based machines, but providing CPU and memory shouldn't be a problem.
> >
> > --
> > Erik
>
>


Re: [DISCUSS] LTS Releases

2014-11-27 Thread ChunFeng
Thanks to Rohit  & Andrei shares focus on this topic .  


I am +1 on we should "reshape"  the rhythm of new release  .


btw, 

 http://en.wikipedia.org/wiki/Linux_kernel

 Since the 2004 release of the 2.6 kernel, Linux no longer uses this system, 
and has a much shorter release cycle.
 In 2004, after version 2.6.0 was released, the kernel developers held several 
discussions regarding the release and version scheme[200][201] and ultimately 
Linus Torvalds and others decided that a much shorter "time-based" release 
cycle would be beneficial.
 The even-odd system of alternation between stable and unstable was gone. 
Instead, development pre-releases are titled release candidates, which is 
indicated by appending the suffix '-rc' to the kernel version, followed by an 
ordinal number.





--


Regards,
ChunFeng




 

 
 
 
-- Original --
From:  "Andrei Mikhailovsky";
Date:  Thu, Nov 27, 2014 08:51 PM
To:  "dev"; 

Subject:  Re: [DISCUSS] LTS Releases

 
ChunFeng, 

I think as long as there is a change to the current efforts it will improve the 
stability of the product. At the moment, it is clearly not working very well 
for the end users, otherwise, we would not be discussing this topic. 

As to answer your previous concerns, I agree, having a 5 year support is not an 
option for CloudStack, especially taking into considering the dynamic 
development and the current maturity of the product. It has to be more 
frequent. Perhaps the LTS equivalent version should be released with every 
two/three releases of the non-LTS release. Two/three release cycles should be 
enough time to community test the new features and correct the bugs for the 
stable release. 

IMHO the naming concept is less important as long as the documentation and 
release notes make a distinction. Having fancy letters at the end of the 
product name is a marketing/PR/sales job ). Some companies use LTS, others GA, 
others simply use odd/even version numbering to distinguish between the 
production and testing releases. 

One issue that I foresee with the LTS / non-LTS release cycles is that the 
non-LTS releases might have a smaller userbase as a lot of users want to have a 
production ready system and they perhaps be less likely to install and test the 
non-LTS release. 

Andrei 
- Original Message -

> From: "ChunFeng" 
> To: "dev" 
> Sent: Thursday, 27 November, 2014 10:36:46 AM
> Subject: Re: [DISCUSS] LTS Releases

> hi,

> LTS means Long Term Support , for ubuntu means 5 years support for
> both desktop and server distributions. If we adopt to release
> cloudstack's LTS version , how many years should we support ? 5
> years ? of course can not accept ! even 3 years may be too long to
> old for support as a IAAS management software . 2 or 1 years ? this
> should not call LTS version .

> Second ,the time span for ubuntu release next new LTS version is
> every 2 years . Then , consider the first question , what kind of
> years interval should we take?

> Third, even if the above two issues is false positive , how should we
> name the LTS release version's ? such as: CloudStack-LTS-4.x-201401
> , CloudStack-LTS-4.X-201402 etc , this may cause a more confuse to
> end-users to make a right choice .

> IMO , if a software could automatically upgrade to newer version by
> just one or fews clickes , which kind software is suitable for LTS
> release mechanism , otherwise the cost for end-user to upgrade from
> the older one to newer which will be same as user to choice next
> release version, ie reinstall .

> as Hugo, sebgoa and Andrija said: " we need a WAY to focus here on
> FIXING, POLISHING ", "then LTS becomes less important" and " I’m not
> in favor of supporting LTS releases as a community. "

> --

> Regards,

> ChunFeng

> -- Original --
> From: "sebgoa";
> Date: Thu, Nov 27, 2014 05:14 PM
> To: "dev";

> Subject: Re: [DISCUSS] LTS Releases

> On Nov 27, 2014, at 9:01 AM, Andrija Panic 
> wrote:

> > my 2 cents again:
> >
> > Whether we have this LTS release or not - is not just about having
> > release
> > - we need a WAY to focus here on FIXING, POLISHING product and more
> > important to stimulate/make developers interested in doing so.
> > If this was company owned product, it would be very easy to set
> > goals, and
> > then speak to devs, fix this, fix that.
> >
> > Since this is ofcourse comunity based product - we need some way of
> > focusing on fixing the stuff, and really stop adding features
> > (maybe not
> > completely quit adding features, but...)
> >
> > One important note, and possible scenario - just by having LTS
> > release, but
> > still having majority of developer working on non-LTS release
> > (ading new
> > features) is a big probability, and then we are back to zero with
> > our
> > progress, so I guess this is also an option/problem that we need to
> > consider.
> >
> > I have a very nice experience wit

Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)

2014-11-27 Thread Pierre-Luc Dion
sorry for the late response, I've tested following upgrade:
4.4.0 -> 4.4.1 -> 4.4.2
4.4.0 -> 4.4.2

so far all work fine, but from frest 4.4.0 ,  manual alter table in MySQL
is require. I'll update the Release Notes...

PL

On Wed, Nov 26, 2014 at 12:42 PM, Nux!  wrote:

> What is your setup and zone type?
>
> Some logs might help, too.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Pierre-Luc Dion" 
> > To: dev@cloudstack.apache.org
> > Sent: Wednesday, 26 November, 2014 17:20:24
> > Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
>
> > ok, then, I will test 4.4.0 -> 4.4.1 -> 4.4.2.while doing 4.4.0 to
> > 4.4.2 I've endup behing unable to create network because the systemvm
> > template was not mark as ready, although, ssvm and cpvm as been upgraded
> to
> > 4.4.1 system-vm template without issue. also still need the manual mysql
> > query...
> >
> >
> >
> >
> > On Wed, Nov 26, 2014 at 12:14 PM, Nux!  wrote:
> >
> >> I tried from 4.4.1; what problems are you seeing?
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
> >>
> >> - Original Message -
> >> > From: "Pierre-Luc Dion" 
> >> > To: dev@cloudstack.apache.org
> >> > Sent: Wednesday, 26 November, 2014 17:11:10
> >> > Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341
> (#2)
> >>
> >> > Did anyone try an upgrade from a fresh 4.4.0 to 4.4.2?  so far I did
> not
> >> > had too much success but before do a negative vote I want to make
> sure my
> >> > test env, is ok.
> >> >
> >> > thanks,
> >> >
> >> > PL
> >> >
> >> >
> >> > On Wed, Nov 26, 2014 at 3:46 AM, Nux!  wrote:
> >> >
> >> >> Pierre,
> >> >>
> >> >> In my case it did not, everything worked well, but do note I manually
> >> >> patched the sysvm tmpl for CLOUDSTACK-7781.
> >> >>
> >> >> HTH
> >> >> Lucian
> >> >>
> >> >> --
> >> >> Sent from the Delta quadrant using Borg technology!
> >> >>
> >> >> Nux!
> >> >> www.nux.ro
> >> >>
> >> >> - Original Message -
> >> >> > From: "Pierre-Luc Dion" 
> >> >> > To: dev@cloudstack.apache.org
> >> >> > Sent: Tuesday, 25 November, 2014 23:43:41
> >> >> > Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341
> >> (#2)
> >> >>
> >> >> > Does 4.4.2 require new set of systemvm compare to 4.4.1 ?
> >> >> >
> >> >> >
> >> >> > On Tue, Nov 25, 2014 at 11:15 AM, Tomasz Zięba <
> t.a.zi...@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> >> +1
> >> >> >>
> >> >> >> for:
> >> >> >>
> >> >> >>
> >> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-package-rpm/
> >> >> >> <-- build 317
> >> >> >>
> >> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/
> >> >> >> <-- build 171
> >> >> >>
> >> >> >> Regards
> >> >> >> Tom
> >> >> >>
> >> >> >> 2014-11-21 3:59 GMT+01:00 Daan Hoogland  >:
> >> >> >>
> >> >> >> > Hi All,
> >> >> >> >
> >> >> >> > I've created a 4.4.2 release, with the following artifacts up
> for a
> >> >> vote:
> >> >> >> >
> >> >> >> > Git Branch and Commit SH:
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4
> >> >> >> > Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb
> >> >> >> >
> >> >> >> > List of changes:
> >> >> >> > `CLOUDSTACK-7887
> >> >> >> > `_
> fail to
> >> >> >> > push snapshot to secondary storage if using multipart using
> >> swift...
> >> >> >> >
> >> >> >> > `CLOUDSTACK-7883
> >> >> >> > `_
> Allow
> >> >> >> > infrastructure to handle delete of volume from DB...
> >> >> >> >
> >> >> >> > `CLOUDSTACK-7871
> >> >> >> > `_  Fix
> >> update
> >> >> >> > VirtualMachine/Template API to allow nic/disk controller details
> >> for
> >> >> >> > ...
> >> >> >> >
> >> >> >> > `CLOUDSTACK-7855
> >> >> >> > `_  Sec
> >> >> >> > storage/network MTU should be on nic3 and not nic1...
> >> >> >> >
> >> >> >> > `CLOUDSTACK-7826
> >> >> >> > `_  UI -
> >> >> dialog
> >> >> >> > widget - dependent dropdown field (dependsOn property
> specified) -
> >> >> >> > f...
> >> >> >> >
> >> >> >> > `CLOUDSTACK-7822
> >> >> >> > `_  test
> >> SSL
> >> >> >> > cert expired...
> >> >> >> >
> >> >> >> > `CLOUDSTACK-7752
> >> >> >> > `_
> >> Management
> >> >> >> > Server goes in infinite loop while creating a vm with tagged
> local
> >> >> >> > da...
> >> >> >> >
> >> >> >> > `CLOUDSTACK-7722
> >> >> >> > `_
> >> add.label:
> >> >> >> > Add button for tags show the label not "Add" text...
> >> >> >> >
> >> >> >> > `CLOUDSTAC

Re: [QUESTION] @ReflectionUse

2014-11-27 Thread Rajani Karuturi
It came in through the discussion on this thread
http://markmail.org/message/j7ird7yzb3pvszbw


~Rajani

On Thu, Nov 27, 2014 at 11:28 PM, Min Chen  wrote:

> If I understand this clearly, this annotation was introduced by Kelven to
> prevent people from mistakenly removing those annotated methods if they
> find from IDE that those methods are not explicitly called anywhere. These
> methods are actually invoked through reflection.
>
> Thanks
> -min
>
>
>
> > On Nov 27, 2014, at 3:21 AM, "Daan Hoogland" 
> wrote:
> >
> > H Kelven (or others),
> >
> > What are the plans with this annotation, ReflectionUse. Is there to be
> > an implementation or folow up or is it maybe just there to ignore?
> >
> > --
> > Daan
>


Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering

2014-11-27 Thread Harikrishna Patnala
Hi,

This patch was only intended to put in 4.5 and master and later it was back 
ported to 4.3.
If you can help me adding the upgrade path from 4.4.2 to 4.4.3, I’ll put the PR 
for back porting to 4.4.3

Thanks,
Harikrishna

On 27-Nov-2014, at 8:59 pm, Rohit Yadav 
mailto:bhais...@apache.org>> wrote:

Hi Rajani,

I've already started a thread on user/dev ML around LTS releases, we should 
have discussion there.

On Thu, Nov 27, 2014 at 6:26 PM, Rajani Karuturi 
mailto:raj...@apache.org>> wrote:
I dont like the idea of release manager cherry-picking/backporting the fixes to 
the release branches.

As a community we are supporting past two releases. ie) at this point we have 
to support 4.3 and 4.4
As a developer/contributor, if I feel a bug is relevant for 4.3 I should be 
committing it to all the 4.3+ releases. Otherwise it would be a nightmare for 
people trying to upgrade later.
If and when a release is required, we should release from that branch.

+1 that's the ideal case and everyone should do it but since I had to backport 
more than 90 fixes from 4.4/4.5/master to 4.3 many of us were clearly not doing 
that.

In many opensource projects such as Linux, it's common to see different people 
maintaining a certain branch or major release. I want to do the same for 4.3 
until a stable 4.5.x or 4.6.x is out that is fairly tested and used in the 
wild. Everyone is welcome to do it for any branches they do.

Regards.


~Rajani

On Thu, Nov 27, 2014 at 6:13 PM, Rohit Yadav 
mailto:bhais...@apache.org>> wrote:

On Thu, Nov 27, 2014 at 5:30 PM, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:
ok, so that would go in 442to443?

Yes, but do you plan to do a 4.4.3? The whole debate around maintaining 4.3 vs 
4.4 comes down to stakeholder's interests, you've shared that you may not want 
to put a lot of efforts on 4.4 branch since 4.5.0 is around but if I'm mistaken 
and since you're the release manager you should backport changes applicable on 
4.4 and do a 4.4.3 release. That would be great for 4.4.x users.

Before the patch could be ported, Hari will need to use an empty upgrade path 
from 4.4.2 to 4.4.3 and change versions in pom files etc. Hari let me know if 
you can do that in your backport or if Daan or I need to add that for you. 
Thanks.


On Thu, Nov 27, 2014 at 12:52 PM, Rohit Yadav 
mailto:bhais...@apache.org>> wrote:
> Daan,
>
> On Thu, Nov 27, 2014 at 4:17 PM, Daan Hoogland 
> mailto:daan.hoogl...@gmail.com>>
> wrote:
>>
>> If this contains db upgrade code, where did this go in 4.3? In the
>> review request I see changes to 442to450 upgrade files so this should
>> not go in 4.3 or 4.4. What am I missing?
>
>
> For 4.3, the upgrade path (it's just data migration no schema changes so
> easily backportable) is from 4.3.1 to 4.3.2 in Upgrade431to432 class.
>
> The fix simply goes through existing VRs and updates their RAM size, no
> schema changes here only data migrations.
>
> Regards.
>



--
Daan






How to skip some child projects maven test intentionally ?

2014-11-27 Thread ChunFeng
How to skip some child projects maven test intentionally ?


I am now building my coding development environment , of course , I do not need 
some sub projects , such as : Network Brocade VCS,  Midokura Midonet etc .


When I run command : mvn install -P developer,systemvm ,  maven list all sub 
child projects of cloudstack , especially for Plugin projects , I want just 
"SKIP" maven test them for time cost reason.


Can I just skip those maven test by assign some command after :  mvn install -P 
developer,systemvm  ( such as -skip:midonet ) ?




--


Regards,


ChunFeng

Re: How to skip some child projects maven test intentionally ?

2014-11-27 Thread Yitao Jiang
Try  -D skiTests​


---
Thanks,
Yitao(依涛 姜)
jiangyt.github.io

On Fri, Nov 28, 2014 at 3:12 PM, ChunFeng  wrote:

> How to skip some child projects maven test intentionally ?
>
>
> I am now building my coding development environment , of course , I do not
> need some sub projects , such as : Network Brocade VCS,  Midokura Midonet
> etc .
>
>
> When I run command : mvn install -P developer,systemvm ,  maven list all
> sub child projects of cloudstack , especially for Plugin projects , I want
> just "SKIP" maven test them for time cost reason.
>
>
> Can I just skip those maven test by assign some command after :  mvn
> install -P developer,systemvm  ( such as -skip:midonet ) ?
>
>
>
>
> --
>
>
> Regards,
>
>
> ChunFeng


Re: How to skip some child projects maven test intentionally ?

2014-11-27 Thread Yitao Jiang
Sorry about typo, it's -D skipTests wich skip all tests


---
Thanks,
Yitao(依涛 姜)
jiangyt.github.io

On Fri, Nov 28, 2014 at 3:32 PM, Yitao Jiang  wrote:

> Try  -D skiTests​
>
>
> ---
> Thanks,
> Yitao(依涛 姜)
> jiangyt.github.io
>
> On Fri, Nov 28, 2014 at 3:12 PM, ChunFeng  wrote:
>
>> How to skip some child projects maven test intentionally ?
>>
>>
>> I am now building my coding development environment , of course , I do
>> not need some sub projects , such as : Network Brocade VCS,  Midokura
>> Midonet etc .
>>
>>
>> When I run command : mvn install -P developer,systemvm ,  maven list all
>> sub child projects of cloudstack , especially for Plugin projects , I want
>> just "SKIP" maven test them for time cost reason.
>>
>>
>> Can I just skip those maven test by assign some command after :  mvn
>> install -P developer,systemvm  ( such as -skip:midonet ) ?
>>
>>
>>
>>
>> --
>>
>>
>> Regards,
>>
>>
>> ChunFeng
>
>
>