[PROPOSAL] JIRA 4406: Remove cleanString() call for every API to improve performance - especially of the list APIs

[Mandar Barve]

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

I propose following for a solution:

Approach #1

* Check for all the cmds that carry sensitive data each time the logging
function is called to strip sensitive information
* Pros: Easy to implement, with little code impact
* Cons: Won't scale well since any new additional command will mean code
modification required where checks are made

Approach #2

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

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

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

In my opinion we should implement approach #2. I have tested this approach
for couple of sensitive commands list Users and list Accounts. It looks to
work fine.

Please let me know if you have concerns, suggestions.

Thanks,
Mandar

Need +W access to CWIKI page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Plans

[Prashant Kumar Mishra]

Hi,
I need  +W access to CWIKI page 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Plans# , can 
someone help me on this.

Thanks
prashant

Re: Need +W access to CWIKI page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Plans

[Daan Hoogland]

What user id do you have? I can not find you on the wiki.

On Thu, Nov 28, 2013 at 10:52 AM, Prashant Kumar Mishra
 wrote:
> Hi,
> I need  +W access to CWIKI page 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Plans# , can 
> someone help me on this.
>
> Thanks
> prashant

RE: Need +W access to CWIKI page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Plans

[Prashant Kumar Mishra]

Hi Daan ,
Here are details 
User id =prashantkm
Mail id = prashantkumar.mis...@citrix.com

Thanks for quick reply .



-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Thursday, November 28, 2013 3:28 PM
To: dev
Subject: Re: Need +W access to CWIKI page 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Plans

What user id do you have? I can not find you on the wiki.

On Thu, Nov 28, 2013 at 10:52 AM, Prashant Kumar Mishra 
 wrote:
> Hi,
> I need  +W access to CWIKI page 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Plans# , can 
> someone help me on this.
>
> Thanks
> prashant

Re: Review Request 15832: enable custom offering support for scalevm

[bharat kumar]

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

(Updated Nov. 28, 2013, 10:29 a.m.)


Review request for cloudstack and Koushik Das.


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


Repository: cloudstack-git


Description
---

enable scaling of a vm using custom offering
CLOUDSTACK-5161


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java 7b87264 
  
api/src/org/apache/cloudstack/api/command/admin/systemvm/ScaleSystemVMCmd.java 
a7c864d 
  
api/src/org/apache/cloudstack/api/command/admin/systemvm/UpgradeSystemVMCmd.java
 1357a7d 
  api/src/org/apache/cloudstack/api/command/user/vm/ScaleVMCmd.java 6cb49c1 
  api/src/org/apache/cloudstack/api/command/user/vm/UpgradeVMCmd.java 3dfcdf9 
  api/src/org/apache/cloudstack/api/response/ServiceOfferingResponse.java 
7ec739e 
  engine/api/src/com/cloud/vm/VirtualMachineManager.java c78942f 
  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 3a3de70 
  engine/schema/src/com/cloud/event/UsageEventVO.java 719a79b 
  engine/schema/src/com/cloud/service/ServiceOfferingVO.java d968de5 
  engine/schema/src/com/cloud/service/dao/ServiceOfferingDao.java 10d6616 
  engine/schema/src/com/cloud/service/dao/ServiceOfferingDaoImpl.java f1f97fc 
  engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java cd746c2 
  server/src/com/cloud/api/query/dao/ServiceOfferingJoinDaoImpl.java 4f351eb 
  server/src/com/cloud/api/query/vo/ServiceOfferingJoinVO.java 2260e1e 
  server/src/com/cloud/capacity/CapacityManagerImpl.java c733c03 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 3770eb8 
  server/src/com/cloud/server/ManagementServerImpl.java d34da4f 
  server/src/com/cloud/vm/UserVmManager.java 8463326 
  server/src/com/cloud/vm/UserVmManagerImpl.java c0b0031 
  server/test/com/cloud/vm/UserVmManagerTest.java 71bbebe 
  usage/src/com/cloud/usage/UsageManagerImpl.java 81e7892 

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


Testing
---

Tested on master.


Thanks,

bharat kumar

Re: [Discuss] AutoScaling.next in CloudStack

[Nguyen Anh Tu]

On Wed, Nov 27, 2013 at 6:15 PM, Daan Hoogland wrote:

> I have some (limited) experience, it seems the fs[1] refered in this
> thread is good enough if you need to expose data. How much of this is
> being implemented at the moment?
>
> I suppose you need to design a way for leveraging data from
> components, do you? i.e. the monitoriing service from Chiradeeps
> picture[2]
>
> Daan
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+Integrating+CS+alerts+via+SNMP+to+external+management+system
> [2]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Autoscale+framework
>

Thanks Daan,

Sure, I already read these pages. The SNMP alert feature is a good starting
point. I learn how to push SNMP traps to SNMP external manages. But it's
not really fit my scenario. That feature takes alert information from
build-in event alert module, formats it to trap messages and forwards them
to SNMP manager. Actually alert information don't cover VM-level. I need to
think about installing SNMP agent to each VM, or a method that helps
hypervisor to collect information from it's VMs.

Cheers,

Re: Ask about 'Failed to load ApplicationContext' in unit tests during maven building

[Daan Hoogland]

H Alex,

I suppose you are no longer struggling with this but just in case;
check which context xml is loaded in your test and make sure the
appropriate classes are defined in that file. The tests don't
necessarily load all the definitions.

regards,
Daan

On Tue, Nov 19, 2013 at 10:38 PM, Alex Ough  wrote:
> All,
>
> I'm back to Java development after quite long years, so currently I have
> difficulty finding out what causes this error.
>
> Basically, I'd like use 'DomainDao/AccountDao/UserDao' and/or
> 'AccountMgr/DomainMgr' by 'Injecting' them in
> 'com.cloud.event.ActionEventInterceptor' class to find domain/account/user
> information.
>
> But strangely, the injections of all of the classes except 'AccountMgr'
> cause the above error in the unit tests ('com.cloud.vpc.Site2SiteVpnTest'
> and 'org.apache.cloudstack.lb.ApplicationLoadBalancerTest') during building
> 'Server' project.
>
> I'm not familiar with 'inject' tag, so I'm not sure what the problem is,
> but just defining a variable using 'inject' tag causes the failure.
>
> Your help will be very appreciate.
> Thanks
> Alex Ough

Re: need access to QA folder

[Daan Hoogland]

Raja, what is your user account?

On Fri, Nov 22, 2013 at 5:56 AM, Raja Pullela  wrote:
> Hi,
>
> Can I please get me +W access to the QA folder under CWIKI.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home
>
> Thanks,
> Raja
>

Re: Regarding w+ access to Cwiki

[Daan Hoogland]

done

On Fri, Nov 22, 2013 at 6:00 AM, Kiran Koneti  wrote:
> Hi,
>
> I used to have the write access to the cwiki earlier but somehow now the 
> access is been removed .So please provide me the access so that I can add my 
> testplans in the cwiki.
>
>
> Regards,
> Kiran.

Jenkins build is back to normal : cloudstack-4.3-maven-build-noredist #41

[jenkins]

See 

[Responsiveness report] users 2013w47

[Daan Hoogland]

http://markmail.org/message/akg3b3rbs6tuixq4 System VMs running butnot
up by Fariborz Navidan
http://markmail.org/message/5wmrdo3lnmcrmkye vm console is blank with
xenserver 6.2 by Dean Kamali
http://markmail.org/message/ajpzk4sjtpyjy353 Creating unattend.xml
answer file for windows 2008 template by Fariborz Navidan
http://markmail.org/message/hzfcdtnlafurnc75 4.2.0 secondary storage
issue by Nick Wales

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

Re: [Discuss] AutoScaling.next in CloudStack

[Daan Hoogland]

I don't think we should try to go beyond the hypervisor extensions on
the vms (unless it's the systemvms) is this what you mean?

on the systemvm it seems we could indeed. Is that what you mean?

on the others we should try to collect through the hypevisor and not
beyond that, would you agree?



On Thu, Nov 28, 2013 at 11:31 AM, Nguyen Anh Tu  wrote:
> On Wed, Nov 27, 2013 at 6:15 PM, Daan Hoogland wrote:
>
>> I have some (limited) experience, it seems the fs[1] refered in this
>> thread is good enough if you need to expose data. How much of this is
>> being implemented at the moment?
>>
>> I suppose you need to design a way for leveraging data from
>> components, do you? i.e. the monitoriing service from Chiradeeps
>> picture[2]
>>
>> Daan
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+Integrating+CS+alerts+via+SNMP+to+external+management+system
>> [2]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Autoscale+framework
>>
>
> Thanks Daan,
>
> Sure, I already read these pages. The SNMP alert feature is a good starting
> point. I learn how to push SNMP traps to SNMP external manages. But it's
> not really fit my scenario. That feature takes alert information from
> build-in event alert module, formats it to trap messages and forwards them
> to SNMP manager. Actually alert information don't cover VM-level. I need to
> think about installing SNMP agent to each VM, or a method that helps
> hypervisor to collect information from it's VMs.
>
> Cheers,

Re: persistence layer

[Lukas Eder]

Hi Frank,

Thank you for your detailed feedback. This is very interesting insight for
me and for Data Geekery. Let me try to address your concerns by first
categorising them into the following items (please correct me if I might
have misunderstood).

- A concern about Spring support.
- A concern about standards (JPA)
- A concern about CRUD verbosity
- A concern about fluent APIs vs. SQL
- A concern about fluent APIs vs. custom query building APIs

Spring support
===
It is true that we cannot offer you a "formal" affiliation with Spring (or
rather with Oliver Gierke, the lead developer behind Spring Data). I have
been observing this collaboration between Spring Data and QueryDSL and I
feel that it is a strategic alliance that mutually benefits both vendors.
QueryDSL gets some more traction by being auto-shipped to a much broader
audience, whereas Spring Data gets a fluent API for both JPA and SQL.

>From our perspective, we want jOOQ to be entirely independent of any
transaction and connection pooling API as this facilitates integration with
JTA transaction modelling and other models. We believe that by keeping
things simple and by separating concerns, you will get a stack that is
better focused on your individual needs. In that way, we believe that you
should be able to combine Spring IOC with jOOQ just as much as with JEE
components.

Most importantly, Spring Data, much like JDO in the past and like QueryDSL
today aim for integrating NoSQL databases into a unified API, which we find
a poor fit, as transaction models, data models, query models are
fundamentally different between these various data stores. We believe that
by pursuing such unification, frameworks are easily distracted from sound
SQL support. We highly value Spring's transaction model simplification and
this has worked well with jOOQ in the past.

Standards (JPA)

Now, one of your arguments in favour of JPA is the non-lock-in. Spring has
been challenging JEE standards for quite some time and there is no other
vendor in the market to replace Spring once you build upon Spring. Even
more so, by choosing a Spring+QueryDSL combination, you get an equally
strong vendor-lockin (or even a stronger one, as the stack gets more
complex) than when choosing Spring+jOOQ. If standards are important to you,
I suggest you only use JPA and Criteria Query (Note, that JEE also supports
IoC). And I'm sure that Adam Bien will agree with me on this :-)
But even then, you will have a hard time migrating from Hibernate to
EclipseLink or OpenJPA as the implementations are subtly different in many
ways.

The decision is up to you, and I fully understand these concerns. Standards
are a good thing because many disparate things from various vendors have
been unified and hopefully matured over time. But vendors also innovate and
thus deviate from the standard again. Without such deviation, there would
be no more progress, nor innovation in a standard. Take EclipseLink for
instance, a JPA implementation that has started to "flirt" with NoSQL
support:
http://wiki.eclipse.org/EclipseLink/Examples/JPA/NoSQL

The above is orthogonal to JPA and will add lots of complexity to this
particular implementation. JDO was another standard that has attempted to
integrate other, non-relational data stores in a single API, yet it has not
succeeded, leaving a pretty much dead standard.

Now, while you are absolutely right by saying that you cannot switch the
implementation of the jOOQ API at the moment, we're striving to innovate on
the standards front as we see room for various JSRs in the area of RDBMS
meta modelling (beyond JDBC's DatabaseMetaData), internal DSL modelling in
general, SQL DSL modelling in particular. We believe that jOOQ is the most
innovative platform for SQL to Java integration in the market at the moment

CRUD verbosity
===
> In this area, JPA does the right thing.
>
> Author author = new Author(...);
> JPAEntityManary.persist(author);
>
> The later one is more Java more OOP.

Compare this to jOOQ's CRUD features:
AuthorRecord author = ctx.newRecord(AUTHOR);
author.store();

Or alternatively:
AuthorDao dao = ...
dao.insert(new Author());

Relevant sections in the manual are:
-
http://www.jooq.org/doc/3.2/manual/sql-execution/crud-with-updatablerecords/
-
http://www.jooq.org/doc/3.2/manual/sql-execution/crud-with-updatablerecords/simple-crud/
- http://www.jooq.org/doc/3.2/manual/sql-execution/daos/

Fluent APIs vs. SQL
===
I fully understand this concern. Using the jOOQ fluent API is not the same
as writing SQL directly. But let me remind you of the concerns you are
having with respect to database independence. By writing SQL directly
(through JDBC, through views or through stored procedures) you will not be
able to support dozens of databases very easily. Both JPA and jOOQ solve
this problem quite well. JPA abstracts SQL entirely, while jOOQ abstracts
the subtle differences, only.

Fluent APIs vs. custom query building APIs
=

Re: [PROPOSAL] JIRA 4406: Remove cleanString() call for every API to improve performance - especially of the list APIs

[Daan Hoogland]

On Thu, Nov 28, 2013 at 10:38 AM, Mandar Barve  wrote:
>
> In my opinion we should implement approach #2. I have tested this approach
> for couple of sensitive commands list Users and list Accounts. It looks to
> work fine.


H Mandar, I agree but can some automation be done i.e. recognize
sensitive names of fields [pP]assword or varieties thereof? This can
be done at construction or even classloadtime and shouldn't impact
performance very much.

otherwise #2 is more elegant and i mean this as an extension of #2

Re: Need +W access to CWIKI page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+Plans

[Daan Hoogland]

On Thu, Nov 28, 2013 at 11:19 AM, Prashant Kumar Mishra
 wrote:
> prashantkm


added

Re: [DISCUSS] Reporting tool for feeding back zone, pod and cluster information

[Wido den Hollander]

On 11/26/2013 10:42 PM, Steve Wilson wrote:

I built something like this for products at Sun Microsystems.  We embedded
into nearly everything we built:

The Java Runtime Environment
Open Office
Solaris
MySQL
Even things like Server LOMs
(the list goes on)

By default, when each of these products installed/first run, it would try
to bring the user into the program.  It was always possible to opt out,
but we really worked to get people to not opt out.  We got shockingly HUGE
piles of data (literally from millions of installed product instances).
We didn't get any complaints (EVER) in the years we ran this program.  It
was hugely useful to the product teams.



I wouldn't go for opt-out by default. We might ask the question during 
the initial management server installation, but it shouldn't be opt-out 
and not informing the user.



BTW, we didn't even make this data anonymous.  You could obviously choose
to be anonymous, but if people want to give their names/companies then why
not let them?  You'd be surprised how many people wouldn't mind.



I wouldn't want a database with all that information in there. I'm also 
aiming for usage about CloudStack, not who uses it.


We might make something where you can "claim" your data, but I'd 
anonimize it anyway.


Wido


-Steve

On 11/26/13 12:49 PM, "Chiradeep Vittal" 
wrote:


+1.
Of course we must ensure proper treatment of this data (anonymization,
retention, removal, copyrights)

On 11/23/13 11:01 AM, "Wido den Hollander"  wrote:


Hi,

I discussed this during CCCEU13 with David, Chip and Hugo and I promised
I put it on the ml.

My idea is to come up with a reporting tool which users can run daily
which feeds us back information about how they are using CloudStack:

* Hypervisors
* Zone sizes
* Cluster sizes
* Primary Storage sizes and types
* Same for Secondary Storage
* Number of management servers
* Version

This would ofcourse be anonimized where we would send one file with JSON
data back to our servers where we can proccess it to do statistics.

The tool will obviously be open source and participating in this will be
opt-in only.

We currently don't know what's running out there, so that would be great
to know.

Some questions remain:
* Who is going to maintain the data?
* Who has access to the data?
* How long do we keep it?
* Do we do logging of IPs sending the data to us?

I certainly do not want to spy on our users, so that's why it's opt-in
and the tool should be part of the main repo, but I think that for us as
a project it's very useful to know what our users are doing with
CloudStack.

Comments?

Wido

Re: [PROPOSAL] JIRA 4406: Remove cleanString() call for every API to improve performance - especially of the list APIs

[Mandar Barve]

Daan,
The child classes will "know" (since the API request/response
parameters are known) at load time if they are to carry sensitive data and
they can set the flags at class load time/construction like you mentioned.
Flag check will be at the time of logging.

Did you mean to suggest the same or am I missing something?

Thanks,
Mandar


On Thu, Nov 28, 2013 at 5:22 PM, Daan Hoogland wrote:

> On Thu, Nov 28, 2013 at 10:38 AM, Mandar Barve 
> wrote:
> >
> > In my opinion we should implement approach #2. I have tested this
> approach
> > for couple of sensitive commands list Users and list Accounts. It looks
> to
> > work fine.
>
>
> H Mandar, I agree but can some automation be done i.e. recognize
> sensitive names of fields [pP]assword or varieties thereof? This can
> be done at construction or even classloadtime and shouldn't impact
> performance very much.
>
> otherwise #2 is more elegant and i mean this as an extension of #2
>
>

Re: 4.2.1 anytime soon?

[sebgoa]

moved to dev@

I have been checking on this, and the release notes don't build, there is some 
freaking weird error with publican :(
Staring at it all morning did not help...

If anyone feels like it, check out the docs repo and try to build the release 
notes on the 4.2 branch….

thanks,

ps: need a break...

-sebastien



On Nov 28, 2013, at 12:19 PM, Nux!  wrote:

> On 28.11.2013 05:24, Animesh Chaturvedi wrote:
>> Animesh> Here is the list of issues that are fixed
>> https://issues.apache.org/jira/issues/?filter=12325707. This being a
>> maintenance release there are no new features
> 
> Great, thanks! :)
> -- 
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: [PROPOSAL] JIRA 4406: Remove cleanString() call for every API to improve performance - especially of the list APIs

[Daan Hoogland]

Almost, I would like to see some construct that would allow for child
classes not to bother and let the baseclass do the checking and set
the flag at load time so api implemeters don't have to worry about
this. It is kind of a challenge but using reflection it should be
possible.

As I understand your proposal every implementer of an api has to make
the consideration considering every field of the class. It will work
but automated processing of the api class could prevent oversights by
developers.

On the other hand we will run into privacy and security related
situations not foreseeable right now. I am not sure if what I am
saying will pay off.



On Thu, Nov 28, 2013 at 3:24 PM, Mandar Barve  wrote:
> Daan,
> The child classes will "know" (since the API request/response
> parameters are known) at load time if they are to carry sensitive data and
> they can set the flags at class load time/construction like you mentioned.
> Flag check will be at the time of logging.
>
> Did you mean to suggest the same or am I missing something?
>
> Thanks,
> Mandar
>
>
> On Thu, Nov 28, 2013 at 5:22 PM, Daan Hoogland wrote:
>
>> On Thu, Nov 28, 2013 at 10:38 AM, Mandar Barve 
>> wrote:
>> >
>> > In my opinion we should implement approach #2. I have tested this
>> approach
>> > for couple of sensitive commands list Users and list Accounts. It looks
>> to
>> > work fine.
>>
>>
>> H Mandar, I agree but can some automation be done i.e. recognize
>> sensitive names of fields [pP]assword or varieties thereof? This can
>> be done at construction or even classloadtime and shouldn't impact
>> performance very much.
>>
>> otherwise #2 is more elegant and i mean this as an extension of #2
>>
>>

Re: 4.2.1 anytime soon?

[Travis Graham]

Have you tried backing out each commit until it builds clean to see what
broke things?

Travis

On Thursday, November 28, 2013, sebgoa wrote:

> moved to dev@
>
> I have been checking on this, and the release notes don't build, there is
> some freaking weird error with publican :(
> Staring at it all morning did not help...
>
> If anyone feels like it, check out the docs repo and try to build the
> release notes on the 4.2 branch….
>
> thanks,
>
> ps: need a break...
>
> -sebastien
>
>
>
> On Nov 28, 2013, at 12:19 PM, Nux! > wrote:
>
> > On 28.11.2013 05:24, Animesh Chaturvedi wrote:
> >> Animesh> Here is the list of issues that are fixed
> >> https://issues.apache.org/jira/issues/?filter=12325707. This being a
> >> maintenance release there are no new features
> >
> > Great, thanks! :)
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
>
>

contrail package organisation

[Daan Hoogland]

H,

Someone queried for the status of the contrail plugin and I noticed
that the package structure is different then the other network
plugins. The difference being that the contrail classes have
'contrail' in their package name.

1 is this intentional
2 is this going to hurt some automated plugin resolving mechanism?

regards,.

Re: Review Request 15391: few cleanups in CertServiceTest and CertService

[Syed Ahmed]

> On Nov. 11, 2013, 8:32 p.m., Syed Ahmed wrote:
> > Ship It!

Hi Laszlo, 

Can you please move this to submitted if its done. 

Thanks,
-Syed


- Syed


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


On Nov. 10, 2013, 6:26 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15391/
> ---
> 
> (Updated Nov. 10, 2013, 6:26 p.m.)
> 
> 
> Review request for cloudstack and Syed Ahmed.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Tests:
> - all tests are @Test rather than having one test to call them, so they 
> can be run one by one
> - tests that expect exception from a method fail if there is none
> - no longer extends TestCase so that the original method names could be 
> kept as test
> 
> Implementation:
> - include root cause in exceptions when possible - helps at troubleshuting
> - close readers
> 
> 
> Diffs
> -
> 
>   server/src/org/apache/cloudstack/network/lb/CertServiceImpl.java 53dae50 
>   server/test/org/apache/cloudstack/network/lb/CertServiceTest.java e47fc01 
> 
> Diff: https://reviews.apache.org/r/15391/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: Review Request 15832: enable custom offering support for scalevm

[bharat kumar]

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

(Updated Nov. 29, 2013, 5:09 a.m.)


Review request for cloudstack and Koushik Das.


Changes
---

patch for master


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


Repository: cloudstack-git


Description
---

enable scaling of a vm using custom offering
CLOUDSTACK-5161


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java 7b87264 
  
api/src/org/apache/cloudstack/api/command/admin/systemvm/ScaleSystemVMCmd.java 
a7c864d 
  
api/src/org/apache/cloudstack/api/command/admin/systemvm/UpgradeSystemVMCmd.java
 1357a7d 
  api/src/org/apache/cloudstack/api/command/user/vm/ScaleVMCmd.java 6cb49c1 
  api/src/org/apache/cloudstack/api/command/user/vm/UpgradeVMCmd.java 3dfcdf9 
  api/src/org/apache/cloudstack/api/response/ServiceOfferingResponse.java 
7ec739e 
  engine/api/src/com/cloud/vm/VirtualMachineManager.java c78942f 
  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 3a3de70 
  engine/schema/src/com/cloud/event/UsageEventVO.java 719a79b 
  engine/schema/src/com/cloud/service/ServiceOfferingVO.java d968de5 
  engine/schema/src/com/cloud/service/dao/ServiceOfferingDao.java 10d6616 
  engine/schema/src/com/cloud/service/dao/ServiceOfferingDaoImpl.java f1f97fc 
  engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java cd746c2 
  server/src/com/cloud/api/query/dao/ServiceOfferingJoinDaoImpl.java 4f351eb 
  server/src/com/cloud/api/query/vo/ServiceOfferingJoinVO.java 2260e1e 
  server/src/com/cloud/capacity/CapacityManagerImpl.java c733c03 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 3770eb8 
  server/src/com/cloud/server/ManagementServerImpl.java d34da4f 
  server/src/com/cloud/vm/UserVmManager.java 8463326 
  server/src/com/cloud/vm/UserVmManagerImpl.java c0b0031 
  server/test/com/cloud/vm/UserVmManagerTest.java 71bbebe 
  usage/src/com/cloud/usage/UsageManagerImpl.java 81e7892 

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


Testing
---

Tested on master.


Thanks,

bharat kumar

RE: [Doc] Validation Issue in Release Notes

[Radhika Puthiyetath]

It's done it's done...

Sebastien helped us nailed it down the issue. Doc is building, finally !

Who is treating Sebastien ?

-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com] 
Sent: Monday, November 25, 2013 4:29 PM
To: dev@cloudstack.apache.org
Subject: Re: [Doc] Validation Issue in Release Notes


On Nov 25, 2013, at 5:40 AM, Abhinandan Prateek  
wrote:

> There are some issues with the 4.2/master docs. 4.2 is a priority.
> 
> Anyone who fixes the build gets a special mention in the release notes !
> Now can we have someone fix this.
> 

I can't even locate: en-US/Revision_History.xml


> -abhi
> 
> On 23/11/13 4:20 pm, "Radhika Puthiyetath"
>  wrote:
> 
>> Hi,
>> 
>> Sorry for cross-posting.
>> 
>> While validating the Release Notes by using publican,  there is a 
>> validity issue which I am not able to resolve.
>> 
>> The command used is:
>> 
>> 
>> Publican build -format=test -langs=en-us -config=publican.cfg.
>> 
>> 
>> The error I am getting is the following:
>> 
>> Release_Notes.xml:3509: validity error : Element listitem content 
>> does not follow the DTD, expecting (calloutlist | glosslist | 
>> bibliolist | itemizedlist | orderedlist | segmentedlist | simplelist 
>> | v ariablelist | caution | important | note | tip | warning | 
>> literallayout
>> | programlisting | programl
>> istingco | screen | screenco | screenshot | synopsis | cmdsynopsis | 
>> funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | 
>> destructorsynopsis | methodsynopsis
>> | formalpara | para | simp
>> ara | address | blockquote | graphic | graphicco | mediaobject | 
>> mediaobjectco | informalequation | informalexample | informalfigure | 
>> informaltable | equation | example | figure | table | msgset | pr 
>> ocedure | sidebar | qandaset | task | anchor | bridgehead | remark | 
>> highlights | abstract | authorb lurb | epigraph | indexterm | 
>> beginpage)+, got (para programlisting CDATA)
>> 
>> The issue is that the CDATA cannot be located in the file. If it is 
>> removed, we can successfully build the file. The issue persists on 
>> both Master and 4.2
>> 
>> Thanks in advance
>> 
>> -Radhika
> 

Re: Review Request 15832: enable custom offering support for scalevm

[bharat kumar]

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

(Updated Nov. 29, 2013, 7:46 a.m.)


Review request for cloudstack and Koushik Das.


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


Repository: cloudstack-git


Description
---

enable scaling of a vm using custom offering
CLOUDSTACK-5161


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java 7b87264 
  
api/src/org/apache/cloudstack/api/command/admin/systemvm/ScaleSystemVMCmd.java 
a7c864d 
  
api/src/org/apache/cloudstack/api/command/admin/systemvm/UpgradeSystemVMCmd.java
 1357a7d 
  api/src/org/apache/cloudstack/api/command/user/vm/ScaleVMCmd.java 6cb49c1 
  api/src/org/apache/cloudstack/api/command/user/vm/UpgradeVMCmd.java 3dfcdf9 
  api/src/org/apache/cloudstack/api/response/ServiceOfferingResponse.java 
7ec739e 
  engine/api/src/com/cloud/vm/VirtualMachineManager.java c78942f 
  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 3a3de70 
  
engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
 c02e0ad 
  engine/schema/src/com/cloud/event/UsageEventVO.java 719a79b 
  engine/schema/src/com/cloud/service/ServiceOfferingVO.java d968de5 
  engine/schema/src/com/cloud/service/dao/ServiceOfferingDao.java 10d6616 
  engine/schema/src/com/cloud/service/dao/ServiceOfferingDaoImpl.java f1f97fc 
  engine/schema/src/com/cloud/storage/DiskOfferingVO.java 8a9dd3d 
  engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java cd746c2 
  server/src/com/cloud/api/query/dao/ServiceOfferingJoinDaoImpl.java 4f351eb 
  server/src/com/cloud/api/query/vo/ServiceOfferingJoinVO.java 2260e1e 
  server/src/com/cloud/capacity/CapacityManagerImpl.java c733c03 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 3770eb8 
  server/src/com/cloud/server/ManagementServerImpl.java d34da4f 
  server/src/com/cloud/vm/UserVmManager.java 8463326 
  server/src/com/cloud/vm/UserVmManagerImpl.java c0b0031 
  server/test/com/cloud/vm/UserVmManagerTest.java 71bbebe 
  usage/src/com/cloud/usage/UsageManagerImpl.java 81e7892 

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


Testing
---

Tested on master.


Thanks,

bharat kumar