Re: [PROPOSAL] Ability to add new guest OS

[Daan Hoogland]

+1 for the feature,

Did you consider systemvms? Or the default vm-template? Or are those
marked as undeletable or even hardcoded in case the table gets editted
outside of ACS?

The delete feature is vital. You marked it as open for discussion but
I don't agree. The admin should delete when he makes a mistake! Or
when an os has a structural vulnerability!

How and when is memory mapping done? Someone is busy instantiating a
template based on an os which in the meanwhile is being deleted. What
happens?

regards,

On Mon, Mar 3, 2014 at 9:44 PM, Amogh Vasekar  wrote:
> Hi,
>
> CloudStack currently does not allow an easy way to add new guest OS types,
> for example, a standard way to add say, CentOS 6.5 even though a
> hypervisor may support it.
> Part of the reason is since the OS to hypervisor-specific platform
> mappings are currently hard-coded into the code-base [1][2]
> To support such new OS addition, the current way is to manipulate the DB
> using upgrade scripts and make the necessary code changes.
> This proposal aims to partially mitigate this issue by allowing the
> CloudStack admin the ability to add new OS in the list, and update the
> mapping to hypervisor-specific platform names, via APIs / UI. For now, the
> admin will be responsible for providing the mapping to hypervisor-specific
> platform names based on his knowledge, which may be enhanced in future.
> For example, based on [1], an admin should be able to add a mapping like :
> CentOS 6.5 (64 bit) -> CentsOS 6.5 .
>
> The functional spec can be found at :
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal+-+Ability+t
> o+add+new+guest+OS+mappings
>
> Comments / suggestions welcome.
>
> Thanks,
> Amogh
>
>
> [1]
> https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/sr
> c/com/cloud/hypervisor/kvm/resource/KVMGuestOsMapper.java
> [2]
> https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/xen/sr
> c/com/cloud/hypervisor/xen/resource/CitrixHelper.java
>



-- 
Daan

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[Daan Hoogland]

H Alena,

You are right. I was under the impression that response format was
being extended.

I saw you already reverted. If the response was extended with the
extra value it would be alright, would it?

On Mon, Mar 3, 2014 at 7:06 PM, Alena Prokharchyk
 wrote:
> Daan, this fix break API compatibility! All the customers using these API,
> will end up with broken code on their side. As the response format is
> changed. Can you please roll it back?
>
> Thanks,
> Alena.
>
> On 3/3/14, 2:03 AM, "daan Hoogland"  wrote:
>
>>
>>---
>>This is an automatically generated e-mail. To reply, visit:
>>https://reviews.apache.org/r/17591/#review35953
>>---
>>
>>Ship it!
>>
>>
>>ebcaec8632dbd92c071317f3190915244a287afb
>>
>>- daan Hoogland
>>
>>
>>On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:
>>>
>>> ---
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/17591/
>>> ---
>>>
>>> (Updated Jan. 31, 2014, 2:51 p.m.)
>>>
>>>
>>> Review request for cloudstack.
>>>
>>>
>>> Bugs: CLOUDSTACK-5872
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-5872
>>>
>>>
>>> Repository: cloudstack-git
>>>
>>>
>>> Description
>>> ---
>>>
>>> CLOUDSTACK-5872: Async response from addAccountToProject doesn't
>>>contain useful information
>>>
>>> Updated the following classes to return a project object after async
>>>jobs complete:
>>>  api/src/com/cloud/projects/ProjectService.java |  6 ++--
>>>  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
>>>  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
>>>  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
>>>  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
>>>  .../src/com/cloud/projects/ProjectManagerImpl.java | 34
>>>+++---
>>>  .../com/cloud/projects/MockProjectManagerImpl.java | 16 +-
>>>
>>> Previously these API commands only returned "success => true" in the
>>>aysnc job result.  Now it returns the project that a user was
>>>added/deleted to.
>>>
>>>
>>> Diffs
>>> -
>>>
>>>   api/src/com/cloud/projects/ProjectService.java dc882ef
>>>
>>>api/src/org/apache/cloudstack/api/command/user/account/AddAccountToProjec
>>>tCmd.java 36df579
>>>
>>>api/src/org/apache/cloudstack/api/command/user/account/DeleteAccountFromP
>>>rojectCmd.java f6aa36c
>>>
>>>api/src/org/apache/cloudstack/api/command/user/project/UpdateProjectInvit
>>>ationCmd.java dda7b54
>>>   server/src/com/cloud/projects/ProjectManager.java f568146
>>>   server/src/com/cloud/projects/ProjectManagerImpl.java 5a0ed1c
>>>   server/test/com/cloud/projects/MockProjectManagerImpl.java dc377ff
>>>
>>> Diff: https://reviews.apache.org/r/17591/diff/
>>>
>>>
>>> Testing
>>> ---
>>>
>>> Testing done on master.
>>>
>>>
>>> Thanks,
>>>
>>> David Grizzanti
>>>
>>>
>>
>



-- 
Daan

Re: 4.3 createVMSnapshot doesn't check volume state

[Daan Hoogland]

H Qian,

Submit a bug report in jira [1].
If you have a fix for the 'master' branch submit a review request in
the review board [2] be sure to add enough contents to the fields and
set the group to 'cloudstack'. Find the people most involved with the
code you changed and ask them to review.
If you feel it is really a bug and must be ported to 4.3 add a second
review request with changes to the branch '4.3-forward'. then ask the
release manager to apply it to the 4.3 branch.

[1] https://issues.apache.org/jira/browse/CLOUDSTACK
[2] https://reviews.apache.org/

On Tue, Mar 4, 2014 at 3:40 AM, Qian Shaohua  wrote:
> Hi,
>
> We meet the follow case in 4.2.1:
>
> 1. deploy a vm
>
> 2. stop it
>
> 3. restore it, ROOT volume is allocated.
>
> 4. create vm snapshot
>
> Step 4 should always fail, but a createVMSnapshot job is still created
> without checking volume state.
>
> The problem seems also in 4.3 according to the source
> VMSnapshotManagerImpl.allocVMSnapshot().
>
> I'm not a committer but eager to be. How to do with it?
>
>
>
>
>
> --Qian
>



-- 
Daan

Re: Review Request 16688: console-proxy add support of AltGr key and FR azerty keyboard

[Axel Delahaye]

> On March 4, 2014, 7:35 a.m., daan Hoogland wrote:
> > This is ust for 4.2.x, does it apply to higher version as well or do you 
> > want to submit a separate patch for those?

I don't try it with newest cloudstack version (I don't have a 4.3) but if the 
console-proxy doesn't change a lot it may can work.


- Axel


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


On March 3, 2014, 11:20 a.m., Axel Delahaye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16688/
> ---
> 
> (Updated March 3, 2014, 11:20 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Firstly, I add a match condition 'altgr' for "Conditional mapping entry" in 
> ajaxviwer.js.
> altgr : , -- match on altgr state
> 
> It works like the shift match condition.
> shift : , -- match on shift state
> 
> Browser can't detect difference between AltGr and Ctrl+Alt pressed at the 
> same time.
> So when the modifier is 896, (Alt(512) + Ctrl(384)) I assume it is the AltGr 
> key and 'altgr' condition will be true.
> 
> In the ajaxkey.js file you got for example:
> {type: KEY_DOWN, code: 0x32, modifiers: 0, altgr: true}
> to send the spécified key to vnc if user pressed the AltGr (or Ctrl+Alt) key
> 
> Secondly,
> I wrote the French AZERTY translation table in ajaxkeys.js with the support 
> of AltGr character (like #{}[]|,etc.)
> 
> For example the '#':
> 
> {keycode: 51, entry: [ //User type the "3# key and each condition 
> match 'altgr'
> {type: KEY_DOWN, code: 0xffea, modifiers: 0, altgr: true}, //press the VNC 
> AltGR key
> {type: KEY_DOWN, code: 0x33, modifiers: 0, altgr: true},   //press the 3 key
> {type: KEY_UP, code: 0x33, modifiers: 0, altgr: true}, //release it
> {type: KEY_UP, code: 0xffea, modifiers: 0, altgr: true}//release the 
> AltGr key
> ]},
> 
> I replace the Standard (US) keyboard translation table because I can't add an 
> entry in the console proxy keyboard menu.
> 
> Thanks for watching my work
> 
> Axel Delahaye
> 
> 
> Diffs
> -
> 
>   services/console-proxy/server/css/ajaxviewer.css fd2fb3c 
>   services/console-proxy/server/js/ajaxkeys.js 60c9798 
>   services/console-proxy/server/js/ajaxviewer.js e5657e1 
>   
> services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxyClientBase.java
>  b3cda0b 
> 
> Diff: https://reviews.apache.org/r/16688/diff/
> 
> 
> Testing
> ---
> 
> Tested with
> Hardware : French AZERTY keyboard
> Software : Configured in windows as FR keyboard
> Console-proxy : Customized Standard (US) keyboard
> Guest : CentOS 6.5 , Debian 7 and FreeBSD 8
> Guest keymap : fr, fr-pc
> 
> Only the "<" ">" key doesn't work
> 
> 
> Thanks,
> 
> Axel Delahaye
> 
>

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

[Antonio Fornié Casarrubios]

Alena, I saw it, at first I thought it would be a problem in a certain cmd
and then I saw it's the same for all of them. Actually Cmd#getCommandName()
should give us what we want here, the command name, right? Why are we
returning the cmdNameResponse instead?

On top of that, if we continue this way (getting it from the annotation as
you propose) then we would end up having N places with the same code smell
(a couple of lines getting the actual cmd name from the annotation), so
instead I should create a new method in the BaseCmd that does this, so that
these clients (like my code) only have to do: cmd.getActualCmdName()

...but then, have you got a suggestion for how to call this method
considering that we already have a method getCommandName?




2014-03-04 1:44 GMT+01:00 Alena Prokharchyk :

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17888/
>
> Antonio, when you log the WARN about incorrect param name, can you please 
> past the actual name of the command? Right now you log the response object 
> name instead:
>
> 2014-03-03 16:41:57,806 WARN  [c.c.a.d.ParamGenericValidationWorker] 
> (1574968208@qtp-585372613-2:ctx-0261a262 ctx-9867c49e) Received unknown 
> parameters for command listregionsresponse. Unknown parameters : listall
> 2014-03-03 16:41:57,843 WARN  [c.c.a.d.ParamGenericValidationWorker] 
> (589128916@qtp-585372613-5:ctx-80f1e7ec ctx-8d796be3) Received unknown 
> parameters for command listprojectsresponse. Unknown parameters : accountid
>
>
> You can get the command name from @APICommand annotation
>
>
> - Alena Prokharchyk
>
> On March 4th, 2014, 12:18 a.m. UTC, Antonio Fornie wrote:
>   Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and
> Hugo Trippaers.
> By Antonio Fornie.
>
> *Updated March 4, 2014, 12:18 a.m.*
>  *Repository: * cloudstack-git
> Description
>
> Dispatcher corrections, refactoring and tests. Corrects problems from 
> previous attempts that were reverted by Alena. Most of the changes are the 
> same, but this one is not creating conflicts of Map types for Aync Commands 
> or for parameters as Lists or Maps.
>
>   Testing
>
> Full build and test plus manually testing many features. Also including 
> CreateTagsCommand that failed in previous commit.
>
> All unit and integration tests.
>
> Test CS Web UI with the browser going through several use cases.
>
> Also use the CS API by sending HTTP requests generated manually including 
> requests for Async Commands with Map parameters and during these tests apart 
> fromtesting correct functionality I also debugged to check that Maps created 
> correctly where they should but also that in the cases where the async 
> command must be persisted and later on retrieved and deserialized by gson 
> everything works ok and does what and where is expected. An example based on 
> the comment by 
> Alena:http://localhost:8096/client/api?command=createTags&resourceids=ids&resourcetype=type&tags[0].key=region&tags[0].value=canada
> Also other examples 
> likehttp://localhost:8096/client/api?command=createSecondaryStagingStore&url=httpbla&details[0].key=region&details[0].value=canada&details[1].key=element&details[1].value=fire
>
>   Diffs
>
>- api/src/org/apache/cloudstack/api/ApiConstants.java (7b7f9ca)
>- api/src/org/apache/cloudstack/api/BaseCmd.java (0e83cee)
>- api/src/org/apache/cloudstack/api/BaseListCmd.java (c1a4b4c)
>- api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java
>(b2c6734)
>- api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java
>(cf5d355)
>- 
> api/src/org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmProfileCmd.java
>(570e018)
>- 
> server/resources/META-INF/cloudstack/core/spring-server-core-misc-context.xml
>(fd2f5fb)
>- server/src/com/cloud/api/ApiAsyncJobDispatcher.java (f037f2e)
>- server/src/com/cloud/api/ApiDispatcher.java (ed95c72)
>- server/src/com/cloud/api/ApiServer.java (25792fb)
>- server/src/com/cloud/api/ApiServlet.java (46f7eba)
>- server/src/com/cloud/api/dispatch/CommandCreationWorker.java
>(PRE-CREATION)
>- server/src/com/cloud/api/dispatch/DispatchChain.java (PRE-CREATION)
>- server/src/com/cloud/api/dispatch/DispatchChainFactory.java
>(PRE-CREATION)
>- server/src/com/cloud/api/dispatch/DispatchTask.java (PRE-CREATION)
>- server/src/com/cloud/api/dispatch/DispatchWorker.java (PRE-CREATION)
>- server/src/com/cloud/api/dispatch/ParamGenericValidationWorker.java
>(PRE-CREATION)
>- server/src/com/cloud/api/dispatch/ParamProcessWorker.java
>(PRE-CREATION)
>- server/src/com/cloud/api/dispatch/ParamSemanticValidationWorker.java
>(PRE-CREATION)
>- server/src/com/cloud/api/dispatch/ParamUnpackWorker.java
>(PRE-CREATION)
>- server/src/com/cloud/network/as/AutoScaleManagerImpl.java (208b4a4)
>- 
> server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.

Re: Review Request 18616: added delete iso api to the simulator

[Koushik Das]

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

Ship it!


master -> 8e2c4c810557005995f8d49ed55e903d6bc4126d

- Koushik Das


On March 4, 2014, 5:55 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18616/
> ---
> 
> (Updated March 4, 2014, 5:55 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Koushik Das, Santhosh 
> Edukulla, SrikanteswaraRao Talluri, and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> in the smoke tests, this will fix test_03_delete_iso when run against a 
> simulator
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/simulator/src/org/apache/cloudstack/storage/datastore/driver/SimulatorImageStoreDriverImpl.java
>  ff5c3a6 
> 
> Diff: https://reviews.apache.org/r/18616/diff/
> 
> 
> Testing
> ---
> 
> ran the below to verify the test case runs fine
> $ nosetests --with-marvin --marvin-config=setup/dev/advanced.cfg --load 
> test/integration/smoke/test_iso.py
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: Review Request 18680: added mock handlers for VpnUsersCfgCommand and RemoteAccessVpnCfgCommand in the simulator

[Koushik Das]

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

Ship it!


master -> 9be51e1961aa3be09948202e3244e13343d567f9

- Koushik Das


On March 4, 2014, 5:56 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18680/
> ---
> 
> (Updated March 4, 2014, 5:56 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Koushik Das, Santhosh 
> Edukulla, and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
>  added mock handlers for VpnUsersCfgCommand and RemoteAccessVpnCfgCommand in 
> the simulator
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/simulator/src/com/cloud/agent/manager/SimulatorManagerImpl.java
>  3739481 
> 
> Diff: https://reviews.apache.org/r/18680/diff/
> 
> 
> Testing
> ---
> 
> tested by running test/integration/smoke/test_vpc_vpn.py
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: Review Request 16688: console-proxy add support of AltGr key and FR azerty keyboard

[daan Hoogland]

> On March 4, 2014, 7:35 a.m., daan Hoogland wrote:
> > This is ust for 4.2.x, does it apply to higher version as well or do you 
> > want to submit a separate patch for those?
> 
> Axel Delahaye wrote:
> I don't try it with newest cloudstack version (I don't have a 4.3) but if 
> the console-proxy doesn't change a lot it may can work.

It does apply on 4.2-forward but not on 4.3 or master
I can check it in but is unlikely that a new 4.2 version will be released so 
please port to master.


- daan


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


On March 3, 2014, 11:20 a.m., Axel Delahaye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16688/
> ---
> 
> (Updated March 3, 2014, 11:20 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Firstly, I add a match condition 'altgr' for "Conditional mapping entry" in 
> ajaxviwer.js.
> altgr : , -- match on altgr state
> 
> It works like the shift match condition.
> shift : , -- match on shift state
> 
> Browser can't detect difference between AltGr and Ctrl+Alt pressed at the 
> same time.
> So when the modifier is 896, (Alt(512) + Ctrl(384)) I assume it is the AltGr 
> key and 'altgr' condition will be true.
> 
> In the ajaxkey.js file you got for example:
> {type: KEY_DOWN, code: 0x32, modifiers: 0, altgr: true}
> to send the spécified key to vnc if user pressed the AltGr (or Ctrl+Alt) key
> 
> Secondly,
> I wrote the French AZERTY translation table in ajaxkeys.js with the support 
> of AltGr character (like #{}[]|,etc.)
> 
> For example the '#':
> 
> {keycode: 51, entry: [ //User type the "3# key and each condition 
> match 'altgr'
> {type: KEY_DOWN, code: 0xffea, modifiers: 0, altgr: true}, //press the VNC 
> AltGR key
> {type: KEY_DOWN, code: 0x33, modifiers: 0, altgr: true},   //press the 3 key
> {type: KEY_UP, code: 0x33, modifiers: 0, altgr: true}, //release it
> {type: KEY_UP, code: 0xffea, modifiers: 0, altgr: true}//release the 
> AltGr key
> ]},
> 
> I replace the Standard (US) keyboard translation table because I can't add an 
> entry in the console proxy keyboard menu.
> 
> Thanks for watching my work
> 
> Axel Delahaye
> 
> 
> Diffs
> -
> 
>   services/console-proxy/server/css/ajaxviewer.css fd2fb3c 
>   services/console-proxy/server/js/ajaxkeys.js 60c9798 
>   services/console-proxy/server/js/ajaxviewer.js e5657e1 
>   
> services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxyClientBase.java
>  b3cda0b 
> 
> Diff: https://reviews.apache.org/r/16688/diff/
> 
> 
> Testing
> ---
> 
> Tested with
> Hardware : French AZERTY keyboard
> Software : Configured in windows as FR keyboard
> Console-proxy : Customized Standard (US) keyboard
> Guest : CentOS 6.5 , Debian 7 and FreeBSD 8
> Guest keymap : fr, fr-pc
> 
> Only the "<" ">" key doesn't work
> 
> 
> Thanks,
> 
> Axel Delahaye
> 
>

Re: Review Request 16688: console-proxy add support of AltGr key and FR azerty keyboard

[daan Hoogland]

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

Ship it!


eb2f323c48ac4d26d268cc5ee566520b475c74cf (note that needs work for 4.3 and 
master)

- daan Hoogland


On March 3, 2014, 11:20 a.m., Axel Delahaye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16688/
> ---
> 
> (Updated March 3, 2014, 11:20 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Firstly, I add a match condition 'altgr' for "Conditional mapping entry" in 
> ajaxviwer.js.
> altgr : , -- match on altgr state
> 
> It works like the shift match condition.
> shift : , -- match on shift state
> 
> Browser can't detect difference between AltGr and Ctrl+Alt pressed at the 
> same time.
> So when the modifier is 896, (Alt(512) + Ctrl(384)) I assume it is the AltGr 
> key and 'altgr' condition will be true.
> 
> In the ajaxkey.js file you got for example:
> {type: KEY_DOWN, code: 0x32, modifiers: 0, altgr: true}
> to send the spécified key to vnc if user pressed the AltGr (or Ctrl+Alt) key
> 
> Secondly,
> I wrote the French AZERTY translation table in ajaxkeys.js with the support 
> of AltGr character (like #{}[]|,etc.)
> 
> For example the '#':
> 
> {keycode: 51, entry: [ //User type the "3# key and each condition 
> match 'altgr'
> {type: KEY_DOWN, code: 0xffea, modifiers: 0, altgr: true}, //press the VNC 
> AltGR key
> {type: KEY_DOWN, code: 0x33, modifiers: 0, altgr: true},   //press the 3 key
> {type: KEY_UP, code: 0x33, modifiers: 0, altgr: true}, //release it
> {type: KEY_UP, code: 0xffea, modifiers: 0, altgr: true}//release the 
> AltGr key
> ]},
> 
> I replace the Standard (US) keyboard translation table because I can't add an 
> entry in the console proxy keyboard menu.
> 
> Thanks for watching my work
> 
> Axel Delahaye
> 
> 
> Diffs
> -
> 
>   services/console-proxy/server/css/ajaxviewer.css fd2fb3c 
>   services/console-proxy/server/js/ajaxkeys.js 60c9798 
>   services/console-proxy/server/js/ajaxviewer.js e5657e1 
>   
> services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxyClientBase.java
>  b3cda0b 
> 
> Diff: https://reviews.apache.org/r/16688/diff/
> 
> 
> Testing
> ---
> 
> Tested with
> Hardware : French AZERTY keyboard
> Software : Configured in windows as FR keyboard
> Console-proxy : Customized Standard (US) keyboard
> Guest : CentOS 6.5 , Debian 7 and FreeBSD 8
> Guest keymap : fr, fr-pc
> 
> Only the "<" ">" key doesn't work
> 
> 
> Thanks,
> 
> Axel Delahaye
> 
>

Re: [4.4] Feature request: root resize (FAO Marcus)

[Nux!]

On 27.02.2014 09:29, Nux! wrote:

Hi,

Having talked about this issue recently, I'd like to request this
feature so as to avoid template duplication.
Marcus, you said you have a working patch, if you get it to apply to
4.4 I will invest time in testing it.

I have opened an issue with rationale, example etc
https://issues.apache.org/jira/browse/CLOUDSTACK-6181


Hello Mike & Wido, can you guys check out CLOUDSTACK-6181? Looks like 
your blessings are required for this to go through.


Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [PROPOSAL][QUESTION] Map parameters in API Commands

[Bharat Kumar]

Hi ALL,
There are many other APIs that use Map like createNetworkOffering, updateZone, 
createTemplate, in most of the cases we do not
say how to use maps, one way would be to write this in the description or to 
use the same way to access maps of all APIs.

BTW the way to use details in deploy vm API is 
details[0].foo=bar&details[1].baz=12 where foo and baz are keys.

Also  if we want to use the regix protected static final String 
MAP_KEY_PATTERN_EXPRESSION = 
"^([^\\[^\\]]+)\\[(\\d+)\\]\\.key$";
   protected static final 
String MAP_VALUE_PATTERN_EXPRESSION = "^[^\\[^\\]]+\\[\\d+\\]\\.value$”;

wil this work in the following case. I believe service is the key here which 
repeats.
http://10.147.59.119:8080/client/api?command=createNetworkOffering&response=json&sessionkey=/kGFJDXFmMQU8JZnnC7QFfj3tV8=&name=bharat&displayText=bharat&guestIpType=Isolated&lbType=publicLb&;
servicecapabilitylist[0].service=SourceNat&servicecapabilitylist[0].capabilitytype=SupportedSourceNatTypes&
servicecapabilitylist[0].capabilityvalue=peraccount&
servicecapabilitylist[1].service=lb&servicecapabilitylist[1].capabilitytype=SupportedLbIsolation&
servicecapabilitylist[1].capabilityvalue=dedicated&availability=Optional&egresspolicy=ALLOW&state=Creating&status=Creating&allocationstate=Creating&supportedServices=Vpn,Dhcp,Dns,Firewall,Lb,UserData,SourceNat,StaticNat,PortForwarding&specifyIpRanges=false&specifyVlan=false&isPersistent=false&conservemode=false&serviceProviderList[0].service=Vpn&serviceProviderList[0].provider=VirtualRouter&serviceProviderList[1].service=Dhcp&serviceProviderList[1].provider=VirtualRouter&serviceProviderList[2].service=Dns&serviceProviderList[2].provider=VirtualRouter&serviceProviderList[3].service=Firewall&serviceProviderList[3].provider=VirtualRouter&serviceProviderList[4].service=Lb&serviceProviderList[4].provider=VirtualRouter&serviceProviderList[5].service=UserData&serviceProviderList[5].provider=VirtualRouter&serviceProviderList[6].service=SourceNat&serviceProviderList[6].provider=JuniperSRX&serviceProviderList[7].service=StaticNat&serviceProviderList[7].provider=JuniperSRX&serviceProviderList[8].service=PortForwarding&serviceProviderList[8].provider=JuniperSRX&egressdefaultpolicy=true&traffictype=GUEST&_=1393925230248



On 04-Mar-2014, at 2:30 am, Marcus 
mailto:shadow...@gmail.com>> wrote:

Along these lines, the details parameter in deployVirtualMachine seems
broken. If I call "details[0].key=foo,details[0].value=bar", it stores
entries in the database like this:

id | vmid | name | value | display

12 | 25   |  value | bar   | 1
13 | 25   |  key   | foo   | 1

It seems as though this might be correct per Alena's email, but I
don't understand how this can be reconstructed into foo=bar when
there's no binding between the two rows. Perhaps details are supposed
to be passed differently than the resource tags, because if I do
"details[0].foo=bar&details[1].baz=12", I get:

id | vmid | name | value | display

12 | 25   |  foo| bar| 1
13 | 25   |  baz   | 12 | 1

And indeed there is code utilizing these details already committed
that expects this format, as deployVirtualMachines getDetails() only
seems to pass a correct Map with Key, Value if I use
this format.

On Mon, Mar 3, 2014 at 11:48 AM, Antonio Fornié Casarrubios
mailto:antonio.for...@gmail.com>> wrote:
Hi Alena,

Of course, the API will not have any changes. This is not a functional
change, just some refactoring. The problem is there are many things in CS
that really need some refactoring otherwise the problem will continue
growing more and more, but doing the change and above all making sure it
all works afterwards is not simple.

I will make sure that everything works exactly the same way and that the
data returned is also the same.

Thanks. Cheers
Antonio


2014-03-03 18:48 GMT+01:00 Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>:

Antonio, sure I will review the patch. But please make sure that API
backwards compatibly is intact, otherwise the fix won¹t be accepted.

-Alena.


On 3/2/14, 4:31 PM, "Antonio Fornié Casarrubios"
mailto:antonio.for...@gmail.com>> wrote:

Hi Alena,

The reasons for this strange format? I don't know. There doesn't seem to
be
one. After asking on my team and in the dev list I thought perhaps you
could know. It seems we all see it strange and nobody knows why. But of
course, if it is for reasons I will stop the change.



And about the DB, you are right, in the DB is not like I said. But you can
have this in a table row field:
{0={value=Toronto,key=City}}
for some tables. I think there are two cases:

1- params in wich the get method fixes the params on the fly. In these of
course the strange format is not propagated anymore. But this is still
wrong: the format itself before the get is invoked, the time spent on
fixing something that should be a normal Map from the begining (each time
the

Re: [PROPOSAL] Ability to add new guest OS

[Abhinandan Prateek]

On 04/03/14 2:14 am, "Amogh Vasekar"  wrote:

>Hi,
>
>CloudStack currently does not allow an easy way to add new guest OS types,
>for example, a standard way to add say, CentOS 6.5 even though a
>hypervisor may support it.
>Part of the reason is since the OS to hypervisor-specific platform
>mappings are currently hard-coded into the code-base [1][2]

The guest os support is driven by Hypervisor and their version.
Is the initial list of supported os coming from Hypervisor (like for xen
we can get it by Œxe template-list¹ ) ?


>To support such new OS addition, the current way is to manipulate the DB
>using upgrade scripts and make the necessary code changes.
>This proposal aims to partially mitigate this issue by allowing the
>CloudStack admin the ability to add new OS in the list, and update the
>mapping to hypervisor-specific platform names, via APIs / UI. For now, the
>admin will be responsible for providing the mapping to hypervisor-specific
>platform names based on his knowledge, which may be enhanced in future.
>For example, based on [1], an admin should be able to add a mapping like :
>CentOS 6.5 (64 bit) -> CentsOS 6.5 .
>
>The functional spec can be found at :
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal+-+Ability+
>t
>o+add+new+guest+OS+mappings
>
>Comments / suggestions welcome.
>
>Thanks,
>Amogh
>
>
>[1] 
>https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/s
>r
>c/com/cloud/hypervisor/kvm/resource/KVMGuestOsMapper.java
>[2] 
>https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/xen/s
>r
>c/com/cloud/hypervisor/xen/resource/CitrixHelper.java
>

Re: ALARM - ACS reboots host servers!!!

[France]

Hi Marcus and others.

There is no need to kill of the entire hypervisor, if one of the primary 
storages fail.
You just need to kill the VMs and probably disable SR on XenServer, 
because all other SRs and VMs have no problems.
if you kill those, then you can safely start them elsewhere. On 
XenServer 6.2 you call destroy the VMs which lost access to NFS without 
any problems.


If you really want to still kill the entire host and it's VMs in one go, 
I would suggest live migrating the VMs which have had not lost their 
storage off first, and then kill those VMs on a stale NFS by doing hard 
reboot. Additional time, while migrating working VMs, would even give 
some grace time for NFS to maybe recover. :-)


Hard reboot to recover from D state of NFS client can also be avoided by 
using soft mount options.


I run a bunch of Pacemaker/Corosync/Cman/Heartbeat/etc clusters and we 
don't just kill whole nodes but fence services from specific nodes. 
STONITH is implemented only when the node looses the quorum.


Regards,
F.

On 3/3/14 5:35 PM, Marcus wrote:

It's the standard clustering problem. Any software that does any sort
of avtive clustering is going to fence nodes that have problems, or
should if it cares about your data. If the risk of losing a host due
to a storage pool outage is too great, you could perhaps look at
rearranging your pool-to-host correlations (certain hosts run vms from
certain pools) via clusters. Note that if you register a storage pool
with a cluster, it will register the pool with libvirt when the pool
is not in maintenance, which, when the storage pool goes down will
cause problems for the host even if no VMs from that storage are
running (fetching storage stats for example will cause agent threads
to hang if its NFS), so you'd need to put ceph in its own cluster and
NFS in its own cluster.

It's far more dangerous to leave a host in an unknown/bad state. If a
host loses contact with one of your storage nodes, with HA, cloudstack
will want to start the affected VMs elsewhere. If it does so, and your
original host wakes up from it's NFS hang, you suddenly have a VM
running in two locations, corruption ensues. You might think we could
just stop the affected VMs, but NFS tends to make things that touch it
go into D state, even with 'intr' and other parameters, which affects
libvirt and the agent.

We could perhaps open a feature request to disable all HA and just
leave things as-is, disallowing operations when there are outages. If
that sounds useful you can create the feature request on
https://issues.apache.org/jira.


On Mon, Mar 3, 2014 at 5:37 AM, Andrei Mikhailovsky  wrote:

Koushik, I understand that and I will put the storage into the maintenance mode 
next time. However, things happen and servers crash from time to time, which is 
not the reason to reboot all host servers, even those which do not have any 
running vms with volumes on the nfs storage. The bloody agent just rebooted 
every single host server regardless if they were running vms with volumes on 
the rebooted nfs server. 95% of my vms are running from ceph and those should 
have never been effected in the first place.
- Original Message -

From: "Koushik Das" 
To: "" 
Cc: dev@cloudstack.apache.org
Sent: Monday, 3 March, 2014 5:55:34 AM
Subject: Re: ALARM - ACS reboots host servers!!!

The primary storage needs to be put in maintenance before doing any 
upgrade/reboot as mentioned in the previous mails.

-Koushik

On 03-Mar-2014, at 6:07 AM, Marcus  wrote:


Also, please note that in the bug you referenced it doesn't have a
problem with the reboot being triggered, but with the fact that reboot
never completes due to hanging NFS mount (which is why the reboot
occurs, inaccessible primary storage).

On Sun, Mar 2, 2014 at 5:26 PM, Marcus  wrote:

Or do you mean you have multiple primary storages and this one was not
in use and put into maintenance?

On Sun, Mar 2, 2014 at 5:25 PM, Marcus  wrote:

I'm not sure I understand. How do you expect to reboot your primary
storage while vms are running? It sounds like the host is being
fenced since it cannot contact the resources it depends on.

On Sun, Mar 2, 2014 at 3:24 PM, Nux!  wrote:

On 02.03.2014 21:17, Andrei Mikhailovsky wrote:

Hello guys,


I've recently came across the bug CLOUDSTACK-5429 which has rebooted
all of my host servers without properly shutting down the guest vms.
I've simply upgraded and rebooted one of the nfs primary storage
servers and a few minutes later, to my horror, i've found out that all
of my host servers have been rebooted. Is it just me thinking so, or
is this bug should be fixed ASAP and should be a blocker for any new
ACS release. I mean not only does it cause downtime, but also possible
data loss and server corruption.


Hi Andrei,

Do you have HA enabled and did you put that primary storage in maintenance
mode before rebooting it?
It's my understanding that ACS relies on the shared storage to perform HA so
if the storage goes

RE: master branch DbUtilTest failure

[Alex Hitchins]

I too have run into this however not yet managed to sort it out.


Regards

Alex Hitchins

D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969

alex.hitch...@shapeblue.com

-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com]
Sent: 03 March 2014 23:35
To: dev@cloudstack.apache.org
Subject: RE: master branch DbUtilTest failure

Yes! The surefire log prints this:

Caused by: com.cloud.utils.exception.CloudRuntimeException: File containing 
secret key not found: /etc/cloudstack/management/key
at 
com.cloud.utils.crypt.EncryptionSecretKeyChecker.check(EncryptionSecretKeyChecker.java:91)
at com.cloud.utils.db.DbProperties.getDbProperties(DbProperties.java:80)
at com.cloud.utils.db.TransactionLegacy.(TransactionLegacy.java:1024)
... 39 more
Caused by: java.io.FileNotFoundException: \etc\cloudstack\management\key (The 
system cannot find the path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:146)
at java.io.FileReader.(FileReader.java:72)
at 
com.cloud.utils.crypt.EncryptionSecretKeyChecker.check(EncryptionSecretKeyChecker.java:87)
... 41 more


So what is the equivalent path for my Windows setup for this to work? Anyone 
with Windows has got this to work?

Prachi

-Original Message-
From: Wido den Hollander [mailto:w...@widodh.nl]
Sent: Monday, March 03, 2014 3:15 PM
To: dev@cloudstack.apache.org
Subject: Re: master branch DbUtilTest failure



On 03/03/2014 11:40 PM, Prachi Damle wrote:
> Hi,
>
> I am facing this error while doing a clean install on latest master.
>
> It fails running 'com.cloud.utils.DbUtilTest' with error 'Could not 
> initialize class com.cloud.utils.db.TransactionLegacy'
>
> I am on Windows.  Anyone seeing this? Any ideas to fix?
>

Does the logfile of the surefire plugin say something interesting?
Should be in the target directory.

>
> Prachi
>
>
>
>
> [INFO]
> --
> -- [INFO] Building Apache CloudStack Framework - Event Notification
> 4.4.0-SNAPSHOT [INFO]
> --
> --
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
> cloud-framework-db --- [INFO] Deleting
> C:\cloud\apache-cloudstack-oss\incubator-cloudstack\framework\db\targe
> t (includes = [**/*], excludes = []) [INFO] Deleting
> C:\cloud\apache-cloudstack-oss\incubator-cloudstack\framework\db
> (includes = [target, dist], excludes = []) [INFO] [INFO] --- 
> maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
> cloud-framework-db --- [INFO] Starting audit...
> Audit done.
>
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.3:process (default) @
> cloud-framework-db --- [INFO] [INFO] ---
> maven-resources-plugin:2.5:resources (default-resources) @
> cloud-framework-db --- [debug] execute contextualize [INFO] Using
> 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO] Copying 3 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @
> cloud-framework-db --- [INFO] Compiling 43 source files to
> C:\cloud\apache-cloudstack-oss\incubator-cloudstack\framework\db\targe
> t\classes
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:testResources
> (default-testResources) @ cloud-framework-db --- [debug] execute
> contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> C:\cloud\apache-cloudstack-oss\incubator-cloudstack\framework\db\test\
> resources
> [INFO] Copying 3 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.5.1:testCompile
> (default-testCompile) @ cloud-framework-db --- [INFO] Compiling 15
> source files to
> C:\cloud\apache-cloudstack-oss\incubator-cloudstack\framework\db\targe
> t\test-classes
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12:test (default-test) @
> cloud-framework-db --- [INFO] Surefire report directory:
> C:\cloud\apache-cloudstack-oss\incubator-cloudstack\framework\db\targe
> t\surefire-reports
>
> ---
> T E S T S
> ---
> Running com.cloud.utils.DbUtilTest
> log4j:WARN No appenders could be found for logger 
> (com.cloud.utils.crypt.EncryptionSecretKeyChecker).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
> info.
> Tests run: 28, Failures: 0, Errors: 26, Skipped: 2, Time elapsed: 0.667 sec 
> <<< FAILURE!
>
> Results :
>
> Tests in error:
>getTableName(com.cloud.utils.DbUtilTest)
>getTableName(com.cloud.utils.DbUtilTest): Could not initialize class 
> com.cloud.utils.db.TransactionLegacy
>closeStatement(com.cloud.utils.DbUtilTest): Could not initialize class 
> com.cloud.utils.db.TransactionLegacy
>closeStatement(com.cloud.utils.DbUtilTest): Could not initialize class 
> com.cloud.utils.db.TransactionLega

CLOUDSTACK-5583: vmopsSnapshot plug-in (XenServer) does not return an error when it should

[Mandar Barve]

Hi,
I tried to reproduce the issue but couldn't get this to fail for
insufficient space. I then injected an exception trying to list files from
a non existent path (added this code in the "try" block). This landed me
into the exception handling code. It raised correct exception saying "file
not found" which was captured in the management server vmops log file. It
was not displayed by the GUI. GUI just reported Error (Are we looking for
GUI displaying error code?). The plugin code returns "0" immediately after
the line of code that raises exception but I think this applies only for
successful execution of the plugin code that reverts the snapshot.

   If any exception is raised (e.g. in the reported case here
insufficient space) then the code should return appropriate error message
to the caller as I found. In exception handling path return "0" wouldn't
execute.

I don't see any problem here. Let me know if I am missing anything.

Thanks,
Mandar

Re: Review Request 17506: mvn clean - test logs- contrail -cleanps up only target, dist directories; testclient.log file should be generated inside target directory

[daan Hoogland]

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

Ship it!


e2f9c11ad3851ab5fd5749474cd11abe970db997

- daan Hoogland


On Jan. 29, 2014, 6:56 p.m., Suresh Balineni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17506/
> ---
> 
> (Updated Jan. 29, 2014, 6:56 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> mvn clean - cleanps up only target, dist directories; testclient.log file 
> should be generated inside target directory
> 
> 
> Diffs
> -
> 
>   plugins/network-elements/juniper-contrail/test/resources/log4j.properties 
> 138a961 
> 
> Diff: https://reviews.apache.org/r/17506/diff/
> 
> 
> Testing
> ---
> 
> verified locally
> 
> 
> Thanks,
> 
> Suresh Balineni
> 
>

Re: Removing TAGS

[David Nalley]

This really isn't 'our' history though. Most of the tags Sebastien
referred to came in on January 8th[1]. When we moved to the ASF, we
removed the vast majority of tags and branches as they simply didn't
have a lot of context here, and increased the already-bewildering
confusion most people experienced.

[1] 
http://mail-archives.apache.org/mod_mbox/cloudstack-commits/201401.mbox/%3caacd7ef5168d411ab6c71e382190f...@git.apache.org%3e

--David

On Tue, Mar 4, 2014 at 2:48 AM, Daan Hoogland  wrote:
> I am actually -1 on any history falsification or destruction. I have
> no interest in this particular history but if citrix doesn't mind us
> seeing it we should leave it as is.
>
> regads,
> Daan
>
> On Mon, Mar 3, 2014 at 7:43 PM, Alex Huang  wrote:
>> Sebastien,
>>
>> It's a -0 for me.  If it's important to do, sure.
>>
>> --Alex
>>
>>> -Original Message-
>>> From: Sebastien Goasguen [mailto:run...@gmail.com]
>>> Sent: Monday, March 3, 2014 9:54 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: Removing TAGS
>>>
>>>
>>> On Mar 3, 2014, at 12:19 PM, Alex Huang  wrote:
>>>
>>> > What does it achieve?  Tags don't cost anything.  The code came from 
>>> > Citrix.
>>> Removing the TAGS is not going to take that away.
>>> >
>>>
>>> That's true they don't cost a thing, but anyone looking at the tags and not
>>> knowing the history will get confused between cloudstack and cloudplaftorm
>>> and will get confused between version numbers.
>>>
>>> I actually think it's almost a case of branding and that we need to protect 
>>> the
>>> cloudstack brand. At the very least, if you want to keep the tags we should
>>> rename them to avoid confusion.
>>>
>>> -sebastien
>>>
>>> > I like having git metadata in case I need to go find something really old 
>>> > or
>>> understand where the code made its fork.  It doesn't happen often but I do
>>> like having the information if I need it.
>>> >
>>> > --Alex
>>> >
>>> >> -Original Message-
>>> >> From: David Nalley [mailto:da...@gnsa.us]
>>> >> Sent: Sunday, March 2, 2014 5:41 PM
>>> >> To: dev@cloudstack.apache.org
>>> >> Subject: Re: Removing TAGS
>>> >>
>>> >> Please do - obviously retain anything that is tied to an ACS release;
>>> >> but it's a version control system - delete tags boldly.  :)
>>> >>
>>> >>
>>> >> --David
>>> >>
>>> >> On Sun, Mar 2, 2014 at 1:26 PM, Sebastien Goasguen 
>>> >> wrote:
>>> >>> Hi,
>>> >>>
>>> >>> When I look at the tags on git, there are a bunch of Citrix specific 
>>> >>> tags.
>>> >>>
>>> >>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=tags
>>> >>>
>>> >>> Can we clean those up ?
>>> >>>
>>> >>> I don't see why we need a TAG_CLOUDPLATFORM_2.2.15_GA2
>>> >>>
>>> >>> -sebastien
>>> >>>
>>> >>>
>>
>
>
>
> --
> Daan

Re: 4.4 Feature Freeze

[Sebastien Goasguen]

On Mar 3, 2014, at 8:18 PM, Animesh Chaturvedi  
wrote:

> 
> 
>> -Original Message-
>> From: Sebastien Goasguen [mailto:run...@gmail.com]
>> Sent: Sunday, March 02, 2014 10:13 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>> 
>> My take is that we are slipping on RC and re-voting because we are forcing
>> code into the release.
>> 
> [Animesh] That is not right, for 4.3 I had called out feature freeze date 
> clearly and do not recall new feature added.  IMHO the one challenge as 
> community that we have which has been raised earlier also is QA contribution 
> is primarily coming from one organization. Most other folks start taking the 
> release for a spin only after RC2/RC3 or so and then we see additional issues 
> and more re-spins.  We really have to get all engaged in testing much earlier 
> in the cycle. Sudha used to call out for help on QA activity but in prior 
> releases I don't think she got much volunteers. We have huge technical debt 
> and that is not going to go away with pointing fingers. If a specific 
> scenario is benefiting someone as a user/developer of CloudStack and it turns 
> out is not guarded with automation sufficiently and regresses in a release 
> shouldn't the person using it also take some responsibility for safeguarding 
> it with automation? 
> 


Of course everyone is a stakeholder in making CloudStack a high quality 
software.

I am not pointing fingers at anyone I am just expressing my perception of what 
is going on. I have seen several things lately where it seems that we prefer to 
put half-baked features in a major release rather than wait.

Say we release every 6 months, since releases are far apart this puts stress on 
the developer to put his feature "in" before feature freeze, perhaps 
sacrificing quality and testing. If we were to release more often then the 
stress to "miss" a release would be alleviated.

I'd rather see/know that developers don't rush their features because they know 
they can see it in less than 4 months then see features being added to a 
release in fear of missing a cycle.

The issue of QA is another one. Personally I'd like to start testing a release 
branch once code has stabilized and I'd prefer to see a RM lock down on the 
release before testing. What we have seen (and I'd be happy to be wrong), is 
lots of code changes -a lot of times without bug ids- even after an RC was out 
(even though this got corrected in the latest RC). When there is so much churn 
on a release so close to an RC being cut it really is not conducive to testing. 
Maybe the churn is not an issue, but imho I would like to see every commit 
being with a bug ID and being a direct decision of the RM.

-Sebastien

Re: Review Request 18623: CLOUDSTACK-6147: Adding first set of test cases for Dynamic Compute Offering feature

[Gaurav Aradhye]

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


Gentle reminder

- Gaurav Aradhye


On Feb. 28, 2014, 7:17 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18623/
> ---
> 
> (Updated Feb. 28, 2014, 7:17 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6147
> https://issues.apache.org/jira/browse/CLOUDSTACK-6147
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Adding first set of automation test cases for Dynamic Compute Offering 
> Feature.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_dynamic_compute_offering.py PRE-CREATION 
>   tools/marvin/marvin/integration/lib/base.py 0a7ad94 
>   tools/marvin/marvin/integration/lib/common.py b2da3ff 
> 
> Diff: https://reviews.apache.org/r/18623/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Deploy VM with dynamic service offering and check VM stats ... ok
> Deploy VM with dynamic service offering and check VM stats ... ok
> Create dynamic compute offering with cpunumber, cpuspeed and memory ... ok
> Create dynamic compute offering with only cpunumber unspecified ... ok
> Create dynamic compute offering with only cpuspeed unspecified ... ok
> Create dynamic compute offering with only memory unspecified ... ok
> Create normal compute offering with non zero values for cpu, ... ok
> Test deploy VM with dynamic compute offering ... ok
> Test deploy VM with dynamic compute offering ... ok
> Test deploy VM with static offering ... ok
> Test deploy VM with static offering ... ok
> --
> Ran 11 tests in 794.431s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: ALARM - ACS reboots host servers!!!

[Andrei Mikhailovsky]

I agree with France, sounds like a more sensible idea and killing hosts left, 
right and centre with live vms. I now understand the reasons behind killing the 
troubled host server, however, this should be done without killing live vms 
with fully working volumes. 


Regarding having nfs and ceph storage in different clusters - sounds like a 
good idea for majority of cases, however, my setup will not allow me to do that 
just yet. I am using ceph for my root and data volumes and NFS for backup 
volumes. I do currently need the backup volumes as snapshotting with KVM is 
somewhat broken / not fully working in 4.2.1. It has been improved from version 
4.2.0 as it was completely broken. I am waiting for 4.3.0 where, hopefully, I 
would be able to keep snapshots on the primary storage (currently this feature 
is broken) which will make the snapshots with KVM usable. 


Cheers for your help guys 
- Original Message -

From: "France"  
To: us...@cloudstack.apache.org, dev@cloudstack.apache.org 
Sent: Tuesday, 4 March, 2014 10:34:36 AM 
Subject: Re: ALARM - ACS reboots host servers!!! 

Hi Marcus and others. 

There is no need to kill of the entire hypervisor, if one of the primary 
storages fail. 
You just need to kill the VMs and probably disable SR on XenServer, 
because all other SRs and VMs have no problems. 
if you kill those, then you can safely start them elsewhere. On 
XenServer 6.2 you call destroy the VMs which lost access to NFS without 
any problems. 

If you really want to still kill the entire host and it's VMs in one go, 
I would suggest live migrating the VMs which have had not lost their 
storage off first, and then kill those VMs on a stale NFS by doing hard 
reboot. Additional time, while migrating working VMs, would even give 
some grace time for NFS to maybe recover. :-) 

Hard reboot to recover from D state of NFS client can also be avoided by 
using soft mount options. 

I run a bunch of Pacemaker/Corosync/Cman/Heartbeat/etc clusters and we 
don't just kill whole nodes but fence services from specific nodes. 
STONITH is implemented only when the node looses the quorum. 

Regards, 
F. 

On 3/3/14 5:35 PM, Marcus wrote: 
> It's the standard clustering problem. Any software that does any sort 
> of avtive clustering is going to fence nodes that have problems, or 
> should if it cares about your data. If the risk of losing a host due 
> to a storage pool outage is too great, you could perhaps look at 
> rearranging your pool-to-host correlations (certain hosts run vms from 
> certain pools) via clusters. Note that if you register a storage pool 
> with a cluster, it will register the pool with libvirt when the pool 
> is not in maintenance, which, when the storage pool goes down will 
> cause problems for the host even if no VMs from that storage are 
> running (fetching storage stats for example will cause agent threads 
> to hang if its NFS), so you'd need to put ceph in its own cluster and 
> NFS in its own cluster. 
> 
> It's far more dangerous to leave a host in an unknown/bad state. If a 
> host loses contact with one of your storage nodes, with HA, cloudstack 
> will want to start the affected VMs elsewhere. If it does so, and your 
> original host wakes up from it's NFS hang, you suddenly have a VM 
> running in two locations, corruption ensues. You might think we could 
> just stop the affected VMs, but NFS tends to make things that touch it 
> go into D state, even with 'intr' and other parameters, which affects 
> libvirt and the agent. 
> 
> We could perhaps open a feature request to disable all HA and just 
> leave things as-is, disallowing operations when there are outages. If 
> that sounds useful you can create the feature request on 
> https://issues.apache.org/jira. 
> 
> 
> On Mon, Mar 3, 2014 at 5:37 AM, Andrei Mikhailovsky  
> wrote: 
>> Koushik, I understand that and I will put the storage into the maintenance 
>> mode next time. However, things happen and servers crash from time to time, 
>> which is not the reason to reboot all host servers, even those which do not 
>> have any running vms with volumes on the nfs storage. The bloody agent just 
>> rebooted every single host server regardless if they were running vms with 
>> volumes on the rebooted nfs server. 95% of my vms are running from ceph and 
>> those should have never been effected in the first place. 
>> - Original Message - 
>> 
>> From: "Koushik Das"  
>> To: ""  
>> Cc: dev@cloudstack.apache.org 
>> Sent: Monday, 3 March, 2014 5:55:34 AM 
>> Subject: Re: ALARM - ACS reboots host servers!!! 
>> 
>> The primary storage needs to be put in maintenance before doing any 
>> upgrade/reboot as mentioned in the previous mails. 
>> 
>> -Koushik 
>> 
>> On 03-Mar-2014, at 6:07 AM, Marcus  wrote: 
>> 
>>> Also, please note that in the bug you referenced it doesn't have a 
>>> problem with the reboot being triggered, but with the fact that reboot 
>>> never completes due to hanging NFS mount (which is 

Re: ALARM - ACS reboots host servers!!!

[Nux!]

On 04.03.2014 12:55, Andrei Mikhailovsky wrote:


Regarding having nfs and ceph storage in different clusters - sounds
like a good idea for majority of cases, however, my setup will not
allow me to do that just yet. I am using ceph for my root and data
volumes and NFS for backup volumes.


Having tiered storage is one of the stronger features that have drawn 
me towards Cloudstack, it should work better.
I do plan to have a second, slower tier for backups and other more 
passive applications.



I do currently need the backup
volumes as snapshotting with KVM is somewhat broken / not fully
working in 4.2.1. It has been improved from version 4.2.0 as it was
completely broken. I am waiting for 4.3.0 where, hopefully, I would be
able to keep snapshots on the primary storage (currently this feature
is broken) which will make the snapshots with KVM usable.


KVM volume snapshots worked well in 4.2.1 AFAIK and they still work 
well in 4.3, but VM snapshots are still not supported and I don't think 
they will be any time soon. We might get somewhere with it if we opt for 
LVM thin storage and snapshots, that'd be cool.


Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[David Grizzanti]

Alena,

Have the same question as Daan. If we left the "success => true" key/value
in the response and added the project in addition, would that be OK?


On Tue, Mar 4, 2014 at 3:05 AM, Daan Hoogland wrote:

> H Alena,
>
> You are right. I was under the impression that response format was
> being extended.
>
> I saw you already reverted. If the response was extended with the
> extra value it would be alright, would it?
>
> On Mon, Mar 3, 2014 at 7:06 PM, Alena Prokharchyk
>  wrote:
> > Daan, this fix break API compatibility! All the customers using these
> API,
> > will end up with broken code on their side. As the response format is
> > changed. Can you please roll it back?
> >
> > Thanks,
> > Alena.
> >
> > On 3/3/14, 2:03 AM, "daan Hoogland"  wrote:
> >
> >>
> >>---
> >>This is an automatically generated e-mail. To reply, visit:
> >>https://reviews.apache.org/r/17591/#review35953
> >>---
> >>
> >>Ship it!
> >>
> >>
> >>ebcaec8632dbd92c071317f3190915244a287afb
> >>
> >>- daan Hoogland
> >>
> >>
> >>On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:
> >>>
> >>> ---
> >>> This is an automatically generated e-mail. To reply, visit:
> >>> https://reviews.apache.org/r/17591/
> >>> ---
> >>>
> >>> (Updated Jan. 31, 2014, 2:51 p.m.)
> >>>
> >>>
> >>> Review request for cloudstack.
> >>>
> >>>
> >>> Bugs: CLOUDSTACK-5872
> >>> https://issues.apache.org/jira/browse/CLOUDSTACK-5872
> >>>
> >>>
> >>> Repository: cloudstack-git
> >>>
> >>>
> >>> Description
> >>> ---
> >>>
> >>> CLOUDSTACK-5872: Async response from addAccountToProject doesn't
> >>>contain useful information
> >>>
> >>> Updated the following classes to return a project object after async
> >>>jobs complete:
> >>>  api/src/com/cloud/projects/ProjectService.java |  6 ++--
> >>>  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
> >>>  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
> >>>  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
> >>>  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
> >>>  .../src/com/cloud/projects/ProjectManagerImpl.java | 34
> >>>+++---
> >>>  .../com/cloud/projects/MockProjectManagerImpl.java | 16 +-
> >>>
> >>> Previously these API commands only returned "success => true" in the
> >>>aysnc job result.  Now it returns the project that a user was
> >>>added/deleted to.
> >>>
> >>>
> >>> Diffs
> >>> -
> >>>
> >>>   api/src/com/cloud/projects/ProjectService.java dc882ef
> >>>
>
> >>>api/src/org/apache/cloudstack/api/command/user/account/AddAccountToProjec
> >>>tCmd.java 36df579
> >>>
>
> >>>api/src/org/apache/cloudstack/api/command/user/account/DeleteAccountFromP
> >>>rojectCmd.java f6aa36c
> >>>
>
> >>>api/src/org/apache/cloudstack/api/command/user/project/UpdateProjectInvit
> >>>ationCmd.java dda7b54
> >>>   server/src/com/cloud/projects/ProjectManager.java f568146
> >>>   server/src/com/cloud/projects/ProjectManagerImpl.java 5a0ed1c
> >>>   server/test/com/cloud/projects/MockProjectManagerImpl.java dc377ff
> >>>
> >>> Diff: https://reviews.apache.org/r/17591/diff/
> >>>
> >>>
> >>> Testing
> >>> ---
> >>>
> >>> Testing done on master.
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> David Grizzanti
> >>>
> >>>
> >>
> >
>
>
>
> --
> Daan
>
>


-- 
David Grizzanti
Software Engineer
Sungard Availability Services

e: david.grizza...@sungard.com
w: 215.446.1431
c: 570.575.0315

Re: ALARM - ACS reboots host servers!!!

[Marcus]

On Tue, Mar 4, 2014 at 3:34 AM, France  wrote:
> Hi Marcus and others.
>
> There is no need to kill of the entire hypervisor, if one of the primary
> storages fail.
> You just need to kill the VMs and probably disable SR on XenServer, because
> all other SRs and VMs have no problems.
> if you kill those, then you can safely start them elsewhere. On XenServer
> 6.2 you call destroy the VMs which lost access to NFS without any problems.

That's a great idea, but as already mentioned, it doesn't work in
practice. You can't kill a VM that is hanging in D state, waiting on
storage. I also mentioned that it causes problems for libvirt and much
of the other system not using the storage.

>
> If you really want to still kill the entire host and it's VMs in one go, I
> would suggest live migrating the VMs which have had not lost their storage
> off first, and then kill those VMs on a stale NFS by doing hard reboot.
> Additional time, while migrating working VMs, would even give some grace
> time for NFS to maybe recover. :-)

You won't be able to live migrate a VM that is stuck in D state, or
use libvirt to do so if one of its storage pools is unresponsive,
anyway.

>
> Hard reboot to recover from D state of NFS client can also be avoided by
> using soft mount options.

As mentioned, soft and intr very rarely actually work, in my
experience. I wish they did as I truly have come to loathe NFS for it.

>
> I run a bunch of Pacemaker/Corosync/Cman/Heartbeat/etc clusters and we don't
> just kill whole nodes but fence services from specific nodes. STONITH is
> implemented only when the node looses the quorum.

Sure, but how do you fence a KVM host from an NFS server? I don't
think we've written a firewall plugin that works to fence hosts from
any NFS server. Regardless, what CloudStack does is more of a poor
man's clustering, the mgmt server is the locking in the sense that it
is managing what's going on, but it's not a real clustering service.
Heck, it doesn't even STONITH, it tries to clean shutdown, which fails
as well due to hanging NFS (per the mentioned bug, to fix it they'll
need IPMI fencing or something like that).

I didn't write the code, I'm just saying that I can completely
understand why it kills nodes when it deems that their storage has
gone belly-up. It's dangerous to leave that D state VM hanging around,
and it will until the NFS storage comes back. In a perfect world you'd
just stop the VMs that were having the issue, or if there were no VMs
you'd just de-register the storage from libvirt, I agree.

>
> Regards,
> F.
>
>
> On 3/3/14 5:35 PM, Marcus wrote:
>>
>> It's the standard clustering problem. Any software that does any sort
>> of avtive clustering is going to fence nodes that have problems, or
>> should if it cares about your data. If the risk of losing a host due
>> to a storage pool outage is too great, you could perhaps look at
>> rearranging your pool-to-host correlations (certain hosts run vms from
>> certain pools) via clusters. Note that if you register a storage pool
>> with a cluster, it will register the pool with libvirt when the pool
>> is not in maintenance, which, when the storage pool goes down will
>> cause problems for the host even if no VMs from that storage are
>> running (fetching storage stats for example will cause agent threads
>> to hang if its NFS), so you'd need to put ceph in its own cluster and
>> NFS in its own cluster.
>>
>> It's far more dangerous to leave a host in an unknown/bad state. If a
>> host loses contact with one of your storage nodes, with HA, cloudstack
>> will want to start the affected VMs elsewhere. If it does so, and your
>> original host wakes up from it's NFS hang, you suddenly have a VM
>> running in two locations, corruption ensues. You might think we could
>> just stop the affected VMs, but NFS tends to make things that touch it
>> go into D state, even with 'intr' and other parameters, which affects
>> libvirt and the agent.
>>
>> We could perhaps open a feature request to disable all HA and just
>> leave things as-is, disallowing operations when there are outages. If
>> that sounds useful you can create the feature request on
>> https://issues.apache.org/jira.
>>
>>
>> On Mon, Mar 3, 2014 at 5:37 AM, Andrei Mikhailovsky 
>> wrote:
>>>
>>> Koushik, I understand that and I will put the storage into the
>>> maintenance mode next time. However, things happen and servers crash from
>>> time to time, which is not the reason to reboot all host servers, even those
>>> which do not have any running vms with volumes on the nfs storage. The
>>> bloody agent just rebooted every single host server regardless if they were
>>> running vms with volumes on the rebooted nfs server. 95% of my vms are
>>> running from ceph and those should have never been effected in the first
>>> place.
>>> - Original Message -
>>>
>>> From: "Koushik Das" 
>>> To: "" 
>>> Cc: dev@cloudstack.apache.org
>>> Sent: Monday, 3 March, 2014 5:55:34 AM
>>> Subject: Re: ALARM - 

Re: ALARM - ACS reboots host servers!!!

[Wido den Hollander]

On 03/04/2014 03:38 PM, Marcus wrote:

On Tue, Mar 4, 2014 at 3:34 AM, France  wrote:

Hi Marcus and others.

There is no need to kill of the entire hypervisor, if one of the primary
storages fail.
You just need to kill the VMs and probably disable SR on XenServer, because
all other SRs and VMs have no problems.
if you kill those, then you can safely start them elsewhere. On XenServer
6.2 you call destroy the VMs which lost access to NFS without any problems.


That's a great idea, but as already mentioned, it doesn't work in
practice. You can't kill a VM that is hanging in D state, waiting on
storage. I also mentioned that it causes problems for libvirt and much
of the other system not using the storage.



Just tuning in here and Marcus is right. If NFS is hanging the processes 
go into status D, both Qemu/KVM and libvirt.


The only remedy at that point to Fence of the host is a reboot, you 
can't do anything with the processes which are blocking.


When you run stuff which only lives in userspace like Ceph with librbd 
it's a different story, but with NFS you are stuck.




If you really want to still kill the entire host and it's VMs in one go, I
would suggest live migrating the VMs which have had not lost their storage
off first, and then kill those VMs on a stale NFS by doing hard reboot.
Additional time, while migrating working VMs, would even give some grace
time for NFS to maybe recover. :-)


You won't be able to live migrate a VM that is stuck in D state, or
use libvirt to do so if one of its storage pools is unresponsive,
anyway.



Indeed, same issue again. Libivrt COMPLETELY blocks, not just one 
storage pool.




Hard reboot to recover from D state of NFS client can also be avoided by
using soft mount options.


As mentioned, soft and intr very rarely actually work, in my
experience. I wish they did as I truly have come to loathe NFS for it.



Indeed, they almost never work. I've been working with NFS for over 10 
years now and those damn options have NEVER worked properly.


That's just the downside of having stuff go through kernel space.



I run a bunch of Pacemaker/Corosync/Cman/Heartbeat/etc clusters and we don't
just kill whole nodes but fence services from specific nodes. STONITH is
implemented only when the node looses the quorum.


Sure, but how do you fence a KVM host from an NFS server? I don't
think we've written a firewall plugin that works to fence hosts from
any NFS server. Regardless, what CloudStack does is more of a poor
man's clustering, the mgmt server is the locking in the sense that it
is managing what's going on, but it's not a real clustering service.
Heck, it doesn't even STONITH, it tries to clean shutdown, which fails
as well due to hanging NFS (per the mentioned bug, to fix it they'll
need IPMI fencing or something like that).



IPMI fencing is something I've been thinking about as well. Would be a 
great benefit for the HA in CloudStack.



I didn't write the code, I'm just saying that I can completely
understand why it kills nodes when it deems that their storage has
gone belly-up. It's dangerous to leave that D state VM hanging around,
and it will until the NFS storage comes back. In a perfect world you'd
just stop the VMs that were having the issue, or if there were no VMs
you'd just de-register the storage from libvirt, I agree.



de-register won't work either... Libvirt tries a umount which will block 
as well.


Wido



Regards,
F.


On 3/3/14 5:35 PM, Marcus wrote:


It's the standard clustering problem. Any software that does any sort
of avtive clustering is going to fence nodes that have problems, or
should if it cares about your data. If the risk of losing a host due
to a storage pool outage is too great, you could perhaps look at
rearranging your pool-to-host correlations (certain hosts run vms from
certain pools) via clusters. Note that if you register a storage pool
with a cluster, it will register the pool with libvirt when the pool
is not in maintenance, which, when the storage pool goes down will
cause problems for the host even if no VMs from that storage are
running (fetching storage stats for example will cause agent threads
to hang if its NFS), so you'd need to put ceph in its own cluster and
NFS in its own cluster.

It's far more dangerous to leave a host in an unknown/bad state. If a
host loses contact with one of your storage nodes, with HA, cloudstack
will want to start the affected VMs elsewhere. If it does so, and your
original host wakes up from it's NFS hang, you suddenly have a VM
running in two locations, corruption ensues. You might think we could
just stop the affected VMs, but NFS tends to make things that touch it
go into D state, even with 'intr' and other parameters, which affects
libvirt and the agent.

We could perhaps open a feature request to disable all HA and just
leave things as-is, disallowing operations when there are outages. If
that sounds useful you can create the feature request on
https://issues.apache.org/j

Re: Review Request 15932: Add support for Primary Storage on Gluster using the libvirt backend

[Marcus]

If you get a moment, please look at resize-root branch and see if it
works for Gluster. I didn't see any code specific to creating volumes
in your patch, mostly just pool stuff, so hopefully it's covered.

Also, Wido, as mentioned on the bug for resize-root I'd prefer it if
you could review the changes made for RBD support. We basically just
override the size for new root volumes with the size of the volume
object passed rather than assuming template size, if it's greater than
the template size.

On Sun, Feb 23, 2014 at 8:23 AM, Niels de Vos  wrote:
>
>
>> On Feb. 19, 2014, 2:35 p.m., Wido den Hollander wrote:
>> > It seems good to me. Applies cleanly to master and builds just fine.
>> >
>> > Code-wise it's simple but effective, should allow us to support Gluster.
>>
>> Wido den Hollander wrote:
>> I just merged it into master and pushed.
>>
>> So gluster is in master right now! Niels, can I ask you to test it all 
>> again? Just to make sure the code all works like you intended.
>>
>> Niels de Vos wrote:
>> Thanks Wido!
>> This seems to be working OK for me. Note that the UI modification 
>> (https://reviews.apache.org/r/15933/) have not been reviewed/merged yet. 
>> Without these, it's rather difficult for users to configure Primary Storage 
>> on Gluster.
>>
>> Also, I've got asked about the dependencies and configuration. I'll add 
>> that here for now, and I'll try figure out how to get it added to the 
>> documentation:
>>
>> In /etc/glusterfs/glusterd.vol, allow unprivileged ports to contact the 
>> 'management' volume to get the volume configuration:
>>
>> option rpc-auth-allow-insecure on
>>
>> After changing the glusterd.vol file, restart the glusterd service to 
>> apply the changes.
>>
>> Per volume, allow unprivileged ports to access the brick processes 
>> (glusterfsd):
>>
>> # gluster volume set  server.allow-insecure on
>> # gluster volume stop 
>> # gluster volume start 
>>
>> Per volume make sure that the kvm user (uid=36) and kvm group (gid=36) 
>> can access the images on the volume:
>>
>> # gluster volume set  storage.owner-uid 36
>> # gluster volume set  storage.owner-gid 36
>>
>> Other dependencies:
>> * libvirt version 1.0.1 (gluster protocol/network disk support)
>> * qemu version 1.3 (gluster block backend support)
>>
>> Note that RHEL-6.5 and derived distributions contain backports that add 
>> sufficient functionality too.
>
> Some further testing showed that there can be some issues with starting 
> virtual machines which have disks on Gluster. 
> https://reviews.apache.org/r/18412/ contains a solution for that.
>
>
> - Niels
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15932/#review34859
> ---
>
>
> On Feb. 19, 2014, 9:24 a.m., Niels de Vos wrote:
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/15932/
>> ---
>>
>> (Updated Feb. 19, 2014, 9:24 a.m.)
>>
>>
>> Review request for cloudstack.
>>
>>
>> Repository: cloudstack-git
>>
>>
>> Description
>> ---
>>
>> The support for Gluster as Primary Storage is mostly based on the
>> implementation for NFS. Like NFS, libvirt can address a Gluster environment
>> through the 'netfs' pool-type.
>>
>>
>> Diffs
>> -
>>
>>   api/src/com/cloud/storage/Storage.java ff83dfc
>>   
>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>>  d63b643
>>   
>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtStoragePoolDef.java
>>  dbe5d4b
>>   
>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtStoragePoolXMLParser.java
>>  a6186f6
>>   
>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
>>  ff75d61
>>   
>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStorageProcessor.java
>>  8cdecd8
>>   
>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
>>  a5f33eb
>>   
>> plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
>>  b90d5fc
>>
>> Diff: https://reviews.apache.org/r/15932/diff/
>>
>>
>> Testing
>> ---
>>
>> See http://blog.nixpanic.net/2013/12/using-gluster-as-primary-storage-in.html
>>
>>
>> Thanks,
>>
>> Niels de Vos
>>
>>
>

Re: 4.4 Feature Freeze

[Daan Hoogland]

Animesh, You are doing a great job as guard on our present release and
I don't recall features slipping in either. instead those should now
be added to the master branch. If Sebastien made it sound that way it
is probably because of something else that is bothering him.

However, Sebastien makes a very good point and I would go further. In
my opinion we shouldn't be talking about how many months we keep
between releases. If I make a new feature I want it scrutinized by all
the guru's. Once they have nothing to nag about anymore it should be
in in less then a month. We are a long way from that, but having to
plan a feature in advance is never going to advance quality and
instead will always be a constraint on it.

I could make the finger pointing point as well; At Schuberg Philis we
are dedicating a lot of effort to quality, both by tracking bug
findings and by setting up an automated test environment. I would
prefer to spend this energy in making nice features for the next
release. There is seven of us now and I don't think we spend one
seventh of our energy/time in new features over the last period. The
next release is containing a bunch of features already that won't be
stable from the get go anyway. let's make a good product before we
make it greater.

So, can we find common ground on this issue? My take, rather one
feature per release (each week) with high quality and intensive
testing then three features with divided attention to the code
involved. This is not a proposal, yet. Just an illustration of my
emotions.

kind regards,
Daan

On Tue, Mar 4, 2014 at 1:45 PM, Sebastien Goasguen  wrote:
>
> On Mar 3, 2014, at 8:18 PM, Animesh Chaturvedi 
>  wrote:
>
>>
>>
>>> -Original Message-
>>> From: Sebastien Goasguen [mailto:run...@gmail.com]
>>> Sent: Sunday, March 02, 2014 10:13 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: 4.4 Feature Freeze
>>>
>>> My take is that we are slipping on RC and re-voting because we are forcing
>>> code into the release.
>>>
>> [Animesh] That is not right, for 4.3 I had called out feature freeze date 
>> clearly and do not recall new feature added.  IMHO the one challenge as 
>> community that we have which has been raised earlier also is QA contribution 
>> is primarily coming from one organization. Most other folks start taking the 
>> release for a spin only after RC2/RC3 or so and then we see additional 
>> issues and more re-spins.  We really have to get all engaged in testing much 
>> earlier in the cycle. Sudha used to call out for help on QA activity but in 
>> prior releases I don't think she got much volunteers. We have huge technical 
>> debt and that is not going to go away with pointing fingers. If a specific 
>> scenario is benefiting someone as a user/developer of CloudStack and it 
>> turns out is not guarded with automation sufficiently and regresses in a 
>> release shouldn't the person using it also take some responsibility for 
>> safeguarding it with automation?
>>
>
>
> Of course everyone is a stakeholder in making CloudStack a high quality 
> software.
>
> I am not pointing fingers at anyone I am just expressing my perception of 
> what is going on. I have seen several things lately where it seems that we 
> prefer to put half-baked features in a major release rather than wait.
>
> Say we release every 6 months, since releases are far apart this puts stress 
> on the developer to put his feature "in" before feature freeze, perhaps 
> sacrificing quality and testing. If we were to release more often then the 
> stress to "miss" a release would be alleviated.
>
> I'd rather see/know that developers don't rush their features because they 
> know they can see it in less than 4 months then see features being added to a 
> release in fear of missing a cycle.
>
> The issue of QA is another one. Personally I'd like to start testing a 
> release branch once code has stabilized and I'd prefer to see a RM lock down 
> on the release before testing. What we have seen (and I'd be happy to be 
> wrong), is lots of code changes -a lot of times without bug ids- even after 
> an RC was out (even though this got corrected in the latest RC). When there 
> is so much churn on a release so close to an RC being cut it really is not 
> conducive to testing. Maybe the churn is not an issue, but imho I would like 
> to see every commit being with a bug ID and being a direct decision of the RM.
>
> -Sebastien
>



-- 
Daan

[Events] CloudStack Bangalore March Meetup @ InMobi

[iliyas shirol]

Greetings!


We are happy to announce the Apache CloudStack Bangalore March MeetUp.

RSVP @ http://www.meetup.com/CloudStack-Bangalore-Group/events/169340552/

PFB the agenda of the meetup,


   -

   Agenda:

   4.00 - 4.30 PM

   Networking with CloudStackians (have fun !)

   4.30 - 5.15 PM

   Apache CloudStack 4.2 on Different Hypervisors (kvm/xen/ESXi/Hyper-v)
   with One Management Server

   - Shivaprasad Katta, Dell

   5.15 - 6.00 PM

   Adding HyperV in CloudStack

   - Devdeep Singh, Citrix

   6.00 - 6.45 PM

   Creating CentOS Template For CloudStack

   - Shanker Balan, ShapeBlue

Thanks.

-- 
-
Md. Iliyas Shirol
Mobile : +91 9902 977 800
Google : iliyas.shirol@ gmail.com

Re: ALARM - ACS reboots host servers!!!

[Marcus]

Of course, in the event that the NFS *server* is truly out, users may
prefer that no action is taken, everything stays as-is so that when it
comes back things can continue running. The main issue I can think of
with that is that NFS clients may think things were flushed to disk on
the NFS server that were not (if the NFS server hard crashed) if the
NFS server is running async. Then the VM processes will see corruption
and likely go into read-only and need reboot, anyway. The upside is
that unaffected storage might still run vms, and libvirt/host might
(??) recover when the NFS server comes back. There's also not
currently a way (that I'm aware of) for the agent/host side to ask the
mgmt server questions like 'is the server down, or is it just me?',
but some discovery method like that would be required, I think, since
the agent is what drives the HA right now (which also isn't great).

I just thought of one minor improvement to the situation that might
fix CLOUDSTACK-5429. They could potentially use the sysrq triggers to
force reboot.


On Tue, Mar 4, 2014 at 7:45 AM, Wido den Hollander  wrote:
> On 03/04/2014 03:38 PM, Marcus wrote:
>>
>> On Tue, Mar 4, 2014 at 3:34 AM, France  wrote:
>>>
>>> Hi Marcus and others.
>>>
>>> There is no need to kill of the entire hypervisor, if one of the primary
>>> storages fail.
>>> You just need to kill the VMs and probably disable SR on XenServer,
>>> because
>>> all other SRs and VMs have no problems.
>>> if you kill those, then you can safely start them elsewhere. On XenServer
>>> 6.2 you call destroy the VMs which lost access to NFS without any
>>> problems.
>>
>>
>> That's a great idea, but as already mentioned, it doesn't work in
>> practice. You can't kill a VM that is hanging in D state, waiting on
>> storage. I also mentioned that it causes problems for libvirt and much
>> of the other system not using the storage.
>>
>
> Just tuning in here and Marcus is right. If NFS is hanging the processes go
> into status D, both Qemu/KVM and libvirt.
>
> The only remedy at that point to Fence of the host is a reboot, you can't do
> anything with the processes which are blocking.
>
> When you run stuff which only lives in userspace like Ceph with librbd it's
> a different story, but with NFS you are stuck.
>
>
>>>
>>> If you really want to still kill the entire host and it's VMs in one go,
>>> I
>>> would suggest live migrating the VMs which have had not lost their
>>> storage
>>> off first, and then kill those VMs on a stale NFS by doing hard reboot.
>>> Additional time, while migrating working VMs, would even give some grace
>>> time for NFS to maybe recover. :-)
>>
>>
>> You won't be able to live migrate a VM that is stuck in D state, or
>> use libvirt to do so if one of its storage pools is unresponsive,
>> anyway.
>>
>
> Indeed, same issue again. Libivrt COMPLETELY blocks, not just one storage
> pool.
>
>
>>>
>>> Hard reboot to recover from D state of NFS client can also be avoided by
>>> using soft mount options.
>>
>>
>> As mentioned, soft and intr very rarely actually work, in my
>> experience. I wish they did as I truly have come to loathe NFS for it.
>>
>
> Indeed, they almost never work. I've been working with NFS for over 10 years
> now and those damn options have NEVER worked properly.
>
> That's just the downside of having stuff go through kernel space.
>
>
>>>
>>> I run a bunch of Pacemaker/Corosync/Cman/Heartbeat/etc clusters and we
>>> don't
>>> just kill whole nodes but fence services from specific nodes. STONITH is
>>> implemented only when the node looses the quorum.
>>
>>
>> Sure, but how do you fence a KVM host from an NFS server? I don't
>> think we've written a firewall plugin that works to fence hosts from
>> any NFS server. Regardless, what CloudStack does is more of a poor
>> man's clustering, the mgmt server is the locking in the sense that it
>> is managing what's going on, but it's not a real clustering service.
>> Heck, it doesn't even STONITH, it tries to clean shutdown, which fails
>> as well due to hanging NFS (per the mentioned bug, to fix it they'll
>> need IPMI fencing or something like that).
>>
>
> IPMI fencing is something I've been thinking about as well. Would be a great
> benefit for the HA in CloudStack.
>
>
>> I didn't write the code, I'm just saying that I can completely
>> understand why it kills nodes when it deems that their storage has
>> gone belly-up. It's dangerous to leave that D state VM hanging around,
>> and it will until the NFS storage comes back. In a perfect world you'd
>> just stop the VMs that were having the issue, or if there were no VMs
>> you'd just de-register the storage from libvirt, I agree.
>>
>
> de-register won't work either... Libvirt tries a umount which will block as
> well.
>
> Wido
>
>
>>>
>>> Regards,
>>> F.
>>>
>>>
>>> On 3/3/14 5:35 PM, Marcus wrote:


 It's the standard clustering problem. Any software that does any sort
 of avtive clustering is going to fence nodes that have p

Re: CLOUDSTACK-5583: vmopsSnapshot plug-in (XenServer) does not return an error when it should

[Mike Tutkowski]

Hi,

Can you tell me what release you tested this with? I noticed the problem
while developing on CloudStack 4.3.

Thanks!


On Tue, Mar 4, 2014 at 3:43 AM, Mandar Barve wrote:

> Hi,
> I tried to reproduce the issue but couldn't get this to fail for
> insufficient space. I then injected an exception trying to list files from
> a non existent path (added this code in the "try" block). This landed me
> into the exception handling code. It raised correct exception saying "file
> not found" which was captured in the management server vmops log file. It
> was not displayed by the GUI. GUI just reported Error (Are we looking for
> GUI displaying error code?). The plugin code returns "0" immediately after
> the line of code that raises exception but I think this applies only for
> successful execution of the plugin code that reverts the snapshot.
>
>If any exception is raised (e.g. in the reported case here
> insufficient space) then the code should return appropriate error message
> to the caller as I found. In exception handling path return "0" wouldn't
> execute.
>
> I don't see any problem here. Let me know if I am missing anything.
>
> Thanks,
> Mandar
>



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

4.2.1 Simulator - DeployVirtualMachine gives different keypair than specified

[Ian Duffy]

Hi All,

I'm running against the 4.2.1 Simulator.

I'm executing a DeployVirtualMachine command with KeyPair of test example:

client/api?apikey=sZOWCNSEqYmqhZGswOPpAq-snv_YoRzq6ocdb4FDKodSxni7VgI9t3g4K30q_-Y3PAYkQsq-Sp3LJHPQbiSh3w&command=deployVirtualMachine&keypair=test&response=json&serviceofferingid=739292ce-3e12-4643-8ca1-abfdc2b2eb76&templateid=a32d70ee-95e4-11e3-b2e4-d19c9d3e5e1d&zoneid=1e47a2fc-61c7-401c-b90e-416b472ada64

However the final response I get back is as follows:

https://gist.github.com/imduffy15/02653e65085c3d74f6a6

Which shows the keypair name as asdfasdasdasd (which is a valid key)

I assume this is a bug?
Can anyone comment?

Re: ALARM - ACS reboots host servers!!!

[France]

On Mar 4, 2014, at 3:38 PM, Marcus wrote:

> On Tue, Mar 4, 2014 at 3:34 AM, France  wrote:
>> Hi Marcus and others.
>> 
>> There is no need to kill of the entire hypervisor, if one of the primary
>> storages fail.
>> You just need to kill the VMs and probably disable SR on XenServer, because
>> all other SRs and VMs have no problems.
>> if you kill those, then you can safely start them elsewhere. On XenServer
>> 6.2 you call destroy the VMs which lost access to NFS without any problems.
> 
> That's a great idea, but as already mentioned, it doesn't work in
> practice. You can't kill a VM that is hanging in D state, waiting on
> storage. I also mentioned that it causes problems for libvirt and much
> of the other system not using the storage.

You can on XS 6.2 as tried in in real life and reported by others as well.

> 
>> 
>> If you really want to still kill the entire host and it's VMs in one go, I
>> would suggest live migrating the VMs which have had not lost their storage
>> off first, and then kill those VMs on a stale NFS by doing hard reboot.
>> Additional time, while migrating working VMs, would even give some grace
>> time for NFS to maybe recover. :-)
> 
> You won't be able to live migrate a VM that is stuck in D state, or
> use libvirt to do so if one of its storage pools is unresponsive,
> anyway.
> 

I dont want to live migrate VMs in D state, just the working VMs. Those stuck 
can die with hypervisor reboot.


>> 
>> Hard reboot to recover from D state of NFS client can also be avoided by
>> using soft mount options.
> 
> As mentioned, soft and intr very rarely actually work, in my
> experience. I wish they did as I truly have come to loathe NFS for it.
> 
>> 
>> I run a bunch of Pacemaker/Corosync/Cman/Heartbeat/etc clusters and we don't
>> just kill whole nodes but fence services from specific nodes. STONITH is
>> implemented only when the node looses the quorum.
> 
> Sure, but how do you fence a KVM host from an NFS server? I don't
> think we've written a firewall plugin that works to fence hosts from
> any NFS server. Regardless, what CloudStack does is more of a poor
> man's clustering, the mgmt server is the locking in the sense that it
> is managing what's going on, but it's not a real clustering service.
> Heck, it doesn't even STONITH, it tries to clean shutdown, which fails
> as well due to hanging NFS (per the mentioned bug, to fix it they'll
> need IPMI fencing or something like that).

In my case as well as in the case of OP, the hypervisor got rebooted 
successfully.

> 
> I didn't write the code, I'm just saying that I can completely
> understand why it kills nodes when it deems that their storage has
> gone belly-up. It's dangerous to leave that D state VM hanging around,
> and it will until the NFS storage comes back. In a perfect world you'd
> just stop the VMs that were having the issue, or if there were no VMs
> you'd just de-register the storage from libvirt, I agree.

As previously stated on XS 6.2 you can "destroy" VMs with unaccessible NFS 
storage. I do not remember if processes were in the D state or whatever, cause 
i used the GUI, if i remember correctly. I am sure, you can test it yourself 
too.


> 
>> 
>> Regards,
>> F.
>> 
>> 
>> On 3/3/14 5:35 PM, Marcus wrote:
>>> 
>>> It's the standard clustering problem. Any software that does any sort
>>> of avtive clustering is going to fence nodes that have problems, or
>>> should if it cares about your data. If the risk of losing a host due
>>> to a storage pool outage is too great, you could perhaps look at
>>> rearranging your pool-to-host correlations (certain hosts run vms from
>>> certain pools) via clusters. Note that if you register a storage pool
>>> with a cluster, it will register the pool with libvirt when the pool
>>> is not in maintenance, which, when the storage pool goes down will
>>> cause problems for the host even if no VMs from that storage are
>>> running (fetching storage stats for example will cause agent threads
>>> to hang if its NFS), so you'd need to put ceph in its own cluster and
>>> NFS in its own cluster.
>>> 
>>> It's far more dangerous to leave a host in an unknown/bad state. If a
>>> host loses contact with one of your storage nodes, with HA, cloudstack
>>> will want to start the affected VMs elsewhere. If it does so, and your
>>> original host wakes up from it's NFS hang, you suddenly have a VM
>>> running in two locations, corruption ensues. You might think we could
>>> just stop the affected VMs, but NFS tends to make things that touch it
>>> go into D state, even with 'intr' and other parameters, which affects
>>> libvirt and the agent.
>>> 
>>> We could perhaps open a feature request to disable all HA and just
>>> leave things as-is, disallowing operations when there are outages. If
>>> that sounds useful you can create the feature request on
>>> https://issues.apache.org/jira.
>>> 
>>> 
>>> On Mon, Mar 3, 2014 at 5:37 AM, Andrei Mikhailovsky 
>>> wrote:
 
 Koushik, I und

RE: 4.4 Feature Freeze

[Giles Sirett]

I'm coming in late to this debate, but have been watching closely.

I am -1 on moving the freeze date
To put it more generally: I am -1 on ANYTHING that will have a potential impact 
on quality right now.
Whatever anybody says, I can bet that a shorter code freeze (even temporary) 
will have an impact on quality

I am not a developer, but I see the downstream fallout of features being rushed 
in with the users of this software

>From my experience in the field: customers (users)  do not rush to upgrade ACS 
>anyway.  Most of the orgs I know would accept a 3 month delay if they knew the 
>quality was going to be, on average, higher (obviously, we all have that one 
>feature that *we* want and think is low risk - but I'm generalising here)

We've already got a pretty frequent release cycle . This will be frustrating 
for some of you guys I know (understand many people working like crazy to build 
new features) , but we all know the release cycle, we all know the code freeze 
window.

I fully understand that 4.3 has been a pain to get out of the door and is the 
root cause of this situation. If we have less time to test 4.4, we run the risk 
of having the same happen again.

 If that means that 4.4 needs to ship with fewer features. So be it



Kind Regards
Giles

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




-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com]
Sent: 02 March 2014 18:08
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze


On Feb 26, 2014, at 10:44 PM, Sudha Ponnaganti  
wrote:

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

Why the rush ? if it's not done, it's not done and will get in later. Why rush 
to merge code that you know will have bugs ?

>
> Thanks
> /sudha
>
> -Original Message-
> From: John Kinsella [mailto:j...@stratosec.co]
> Sent: Wednesday, February 26, 2014 7:22 PM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
>
> I don't see not moving the freeze date as a penalty.  If a feature doesn't 
> make the current deadline, it moves to the next release, which is still a few 
> months away. For significant issues, it's not uncommon for us to allow them 
> in late.
>
> What we have a stronger need for than shifting a date, by several orders of 
> magnitude, is understanding why the RC process took so long and what we can 
> do in the future to make that not so painful.
>
> For the record I'm +0 on moving the feature freeze date.
>
> John
>
> On Feb 26, 2014, at 7:10 PM, Ram Ganesh  wrote:
>
>> I share it too. Many developers in the community went out of their
>> way to get a cleaner RC and thereby impacting their feature
>> development efforts. We shouldn't be penalizing them with this 2
>> week's feature freeze schedule
>>
>> Thanks,
>> RamG
>>
>>> -Original Message-
>>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>>> Sent: 27 February 2014 03:00
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: 4.4 Feature Freeze
>>>
>>> Mike I share your opinion most of us have been pretty much on 4.3
>>> until now, and pushing out the release seems reasonable. As I called
>>> out in earlier mail the feature proposal date was not called out for
>>> 4.4 and as such giving little extra room seems reasonable.
>>>
>>> Animesh
>>>
 -Original Message-
 From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
 Sent: Wednesday, February 26, 2014 7:29 AM
 To: dev@cloudstack.apache.org
 Subject: Re: 4.4 Feature Freeze

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

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

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


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

> -1 on postponing the feature freeze. We are having this discussion
> after every release, however we agreed to do a 4 month cycle so
> let's stick
 to it.
>
> If there are important features that are currently being developed
> but might not make this cut-off date we should discuss that
> separately, but as a point of principle lets stick to the release
> schedule as
>>> proposed.
>
>
> Cheers,
>
> Hugo
>
>
> On 26 feb. 2014, at 15:23, Tracy Phillips

Review Request 18733: Refactor DbUpgradeUtils

[Miguel Ferreira]

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

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


Repository: cloudstack-git


Description
---

Refactor DbUpgradeUtils

  - Move database access code to new class DatabaseAccessObject. This was 
done to ease the effort of testing, since DbUpgradeUtils has a static API and 
it is harder to mock static things with Mockito.
  - Log exceptions even if ignored.
  - Add unit tests for both DbUpgradeUtils and DatabaseAccessObject.
  - DbUpgradeUtils.dropTableColumnsIfExist(...) no longer throws 
CloudRuntimeException to make it consistent with the other methods in the class.


Diffs
-

  engine/schema/src/com/cloud/upgrade/dao/DatabaseAccessObject.java 
PRE-CREATION 
  engine/schema/src/com/cloud/upgrade/dao/DbUpgradeUtils.java af23b87 
  engine/schema/test/com/cloud/upgrade/dao/DatabaseAccessObjectTest.java 
PRE-CREATION 
  engine/schema/test/com/cloud/upgrade/dao/DbUpgradeUtilsTest.java PRE-CREATION 

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


Testing
---

Ran all unit tests in eclipse.
Ran "mvn clean install".


Thanks,

Miguel Ferreira

Jenkins build is back to normal : cloudstack-4.3-forward-maven-build #125

[jenkins]

See 

Re: 4.4 Feature Freeze

[SuichII, Christopher]

I’d be a fan of using 4.4 as a learning process for the community and an 
attempt to meet our proposed schedule. While I can appreciate the desire to get 
features into 4.4, there appears to be a significant backlog on JIRA and we’ve 
now had two consecutive versions (I’m not sure about 4.1) not meet their 
original release dates. We could use this time to work through the backlog and 
continue to improve our automation, test coverage and release process.

-- 
Chris Suich
chris.su...@netapp.com
NetApp Software Engineer
Data Center Platforms – Cloud Solutions
Citrix, Cisco & Red Hat

On Mar 4, 2014, at 11:07 AM, Giles Sirett  wrote:

> I'm coming in late to this debate, but have been watching closely.
> 
> I am -1 on moving the freeze date
> To put it more generally: I am -1 on ANYTHING that will have a potential 
> impact on quality right now.
> Whatever anybody says, I can bet that a shorter code freeze (even temporary) 
> will have an impact on quality
> 
> I am not a developer, but I see the downstream fallout of features being 
> rushed in with the users of this software
> 
> From my experience in the field: customers (users)  do not rush to upgrade 
> ACS anyway.  Most of the orgs I know would accept a 3 month delay if they 
> knew the quality was going to be, on average, higher (obviously, we all have 
> that one feature that *we* want and think is low risk - but I'm generalising 
> here)
> 
> We've already got a pretty frequent release cycle . This will be frustrating 
> for some of you guys I know (understand many people working like crazy to 
> build new features) , but we all know the release cycle, we all know the code 
> freeze window.
> 
> I fully understand that 4.3 has been a pain to get out of the door and is the 
> root cause of this situation. If we have less time to test 4.4, we run the 
> risk of having the same happen again.
> 
> If that means that 4.4 needs to ship with fewer features. So be it
> 
> 
> 
> Kind Regards
> Giles
> 
> D: +44 20 3603 0541 | M: +44 796 111 2055
> giles.sir...@shapeblue.com
> 
> 
> 
> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: 02 March 2014 18:08
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
> 
> 
> On Feb 26, 2014, at 10:44 PM, Sudha Ponnaganti  
> wrote:
> 
>> +1 to move feature freeze date in this case as 4.3 closure has impact on the 
>> next release cycle.  There are 14 features targeted  for 4.4 and all of them 
>> are in open state as of now.  There are only 2 weeks left to close on coding 
>> and developers would rush to check in the code.   This only results in poor 
>> quality code.
> 
> Why the rush ? if it's not done, it's not done and will get in later. Why 
> rush to merge code that you know will have bugs ?
> 
>> 
>> Thanks
>> /sudha
>> 
>> -Original Message-
>> From: John Kinsella [mailto:j...@stratosec.co]
>> Sent: Wednesday, February 26, 2014 7:22 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>> 
>> I don't see not moving the freeze date as a penalty.  If a feature doesn't 
>> make the current deadline, it moves to the next release, which is still a 
>> few months away. For significant issues, it's not uncommon for us to allow 
>> them in late.
>> 
>> What we have a stronger need for than shifting a date, by several orders of 
>> magnitude, is understanding why the RC process took so long and what we can 
>> do in the future to make that not so painful.
>> 
>> For the record I'm +0 on moving the feature freeze date.
>> 
>> John
>> 
>> On Feb 26, 2014, at 7:10 PM, Ram Ganesh  wrote:
>> 
>>> I share it too. Many developers in the community went out of their
>>> way to get a cleaner RC and thereby impacting their feature
>>> development efforts. We shouldn't be penalizing them with this 2
>>> week's feature freeze schedule
>>> 
>>> Thanks,
>>> RamG
>>> 
 -Original Message-
 From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
 Sent: 27 February 2014 03:00
 To: dev@cloudstack.apache.org
 Subject: RE: 4.4 Feature Freeze
 
 Mike I share your opinion most of us have been pretty much on 4.3
 until now, and pushing out the release seems reasonable. As I called
 out in earlier mail the feature proposal date was not called out for
 4.4 and as such giving little extra room seems reasonable.
 
 Animesh
 
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, February 26, 2014 7:29 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
> 
> I think we're having this discussion after every release because
> we're beginning to realize that a four-month release cycle has not
> been very realistic for us yet.
> 
> The main issue I encounter is our month-long RC cycle where I spend
> a bunch of time validating the RC and (during that timeframe) less
> time developing for t

Re: 4.4 Feature Freeze

[Jayapal Reddy Uradi]

Hi,

The below feature is proposed in dev list but somehow the fix version is not 
set correctly, update it now.
CLOUDSTACK-2692 Add load 
balancing support for multiple ips to nic

Thanks,
Jayapal

On 04-Mar-2014, at 9:37 PM, Giles Sirett 
mailto:giles.sir...@shapeblue.com>>
 wrote:

I'm coming in late to this debate, but have been watching closely.

I am -1 on moving the freeze date
To put it more generally: I am -1 on ANYTHING that will have a potential impact 
on quality right now.
Whatever anybody says, I can bet that a shorter code freeze (even temporary) 
will have an impact on quality

I am not a developer, but I see the downstream fallout of features being rushed 
in with the users of this software

>From my experience in the field: customers (users)  do not rush to upgrade ACS 
>anyway.  Most of the orgs I know would accept a 3 month delay if they knew the 
>quality was going to be, on average, higher (obviously, we all have that one 
>feature that *we* want and think is low risk - but I'm generalising here)

We've already got a pretty frequent release cycle . This will be frustrating 
for some of you guys I know (understand many people working like crazy to build 
new features) , but we all know the release cycle, we all know the code freeze 
window.

I fully understand that 4.3 has been a pain to get out of the door and is the 
root cause of this situation. If we have less time to test 4.4, we run the risk 
of having the same happen again.

If that means that 4.4 needs to ship with fewer features. So be it



Kind Regards
Giles

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




-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com]
Sent: 02 March 2014 18:08
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze


On Feb 26, 2014, at 10:44 PM, Sudha Ponnaganti  
wrote:

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

Why the rush ? if it's not done, it's not done and will get in later. Why rush 
to merge code that you know will have bugs ?


Thanks
/sudha

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

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

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

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

John

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

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

Thanks,
RamG

-Original Message-
From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
Sent: 27 February 2014 03:00
To: dev@cloudstack.apache.org
Subject: RE: 4.4 Feature Freeze

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

Animesh

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: Wednesday, February 26, 2014 7:29 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze

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

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

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


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

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

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


Cheers,

Hugo


On

Re: [PROPOSAL] Ability to add new guest OS

[John Kinsella]

+1 for the feature, but usually I just go for “other paravirtualized (64 bit)” 
(paraphrasing, mistakes mine) nowadays. What would be more useful, IMHO, is to 
better document the what the selection OS type selection choice means for a VM. 
For KVM, it’s a hell of a lot more than SCSI vs IDE root disk...

On Mar 3, 2014, at 12:44 PM, Amogh Vasekar 
mailto:amogh.vase...@citrix.com>> wrote:

Hi,

CloudStack currently does not allow an easy way to add new guest OS types,
for example, a standard way to add say, CentOS 6.5 even though a
hypervisor may support it.
Part of the reason is since the OS to hypervisor-specific platform
mappings are currently hard-coded into the code-base [1][2]
To support such new OS addition, the current way is to manipulate the DB
using upgrade scripts and make the necessary code changes.
This proposal aims to partially mitigate this issue by allowing the
CloudStack admin the ability to add new OS in the list, and update the
mapping to hypervisor-specific platform names, via APIs / UI. For now, the
admin will be responsible for providing the mapping to hypervisor-specific
platform names based on his knowledge, which may be enhanced in future.
For example, based on [1], an admin should be able to add a mapping like :
CentOS 6.5 (64 bit) -> CentsOS 6.5 .

The functional spec can be found at :
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal+-+Ability+t
o+add+new+guest+OS+mappings

Comments / suggestions welcome.

Thanks,
Amogh


[1]
https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/sr
c/com/cloud/hypervisor/kvm/resource/KVMGuestOsMapper.java
[2]
https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/xen/sr
c/com/cloud/hypervisor/xen/resource/CitrixHelper.java


Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Review Request 18735: CLOUDSTACK-4840: Final set of test cases for Multiple IPs per NIC feature

[Ashutosh Kelkar]

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

Review request for cloudstack and Santhosh Edukulla.


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


Repository: cloudstack-git


Description
---

This is the final set of test cases for "Multiple IPs per NIC" feature.


Diffs
-

  test/integration/component/test_multiple_ips_per_nic.py dcbb453 
  tools/marvin/marvin/config/config.cfg 356a291 
  tools/marvin/marvin/integration/lib/base.py 0a7ad94 

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


Testing
---

Yes.
Please ignore the docstrings, I have updated them according to test case, they 
were redundant before.


Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok
Add secondary IP to NIC of a VM ... ok

--
Ran 43 tests in 11415.388s

OK (SKIP=28)


Thanks,

Ashutosh Kelkar

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[Alena Prokharchyk]

Daan, you can¹t extend the response with more parameters as its a generic
SuccessResponse used by many Apis, and you can¹t add anything a particular
call specific to that.

I think we shouldn¹t fix the bug at this point. You can always get the
additional information you need by executing corresponding list* call.

-Alena.

On 3/4/14, 12:05 AM, "Daan Hoogland"  wrote:

>H Alena,
>
>You are right. I was under the impression that response format was
>being extended.
>
>I saw you already reverted. If the response was extended with the
>extra value it would be alright, would it?
>
>On Mon, Mar 3, 2014 at 7:06 PM, Alena Prokharchyk
> wrote:
>> Daan, this fix break API compatibility! All the customers using these
>>API,
>> will end up with broken code on their side. As the response format is
>> changed. Can you please roll it back?
>>
>> Thanks,
>> Alena.
>>
>> On 3/3/14, 2:03 AM, "daan Hoogland"  wrote:
>>
>>>
>>>---
>>>This is an automatically generated e-mail. To reply, visit:
>>>https://reviews.apache.org/r/17591/#review35953
>>>---
>>>
>>>Ship it!
>>>
>>>
>>>ebcaec8632dbd92c071317f3190915244a287afb
>>>
>>>- daan Hoogland
>>>
>>>
>>>On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:

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

 (Updated Jan. 31, 2014, 2:51 p.m.)


 Review request for cloudstack.


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


 Repository: cloudstack-git


 Description
 ---

 CLOUDSTACK-5872: Async response from addAccountToProject doesn't
contain useful information

 Updated the following classes to return a project object after async
jobs complete:
  api/src/com/cloud/projects/ProjectService.java |  6 ++--
  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
  .../src/com/cloud/projects/ProjectManagerImpl.java | 34
+++---
  .../com/cloud/projects/MockProjectManagerImpl.java | 16 +-

 Previously these API commands only returned "success => true" in the
aysnc job result.  Now it returns the project that a user was
added/deleted to.


 Diffs
 -

   api/src/com/cloud/projects/ProjectService.java dc882ef

api/src/org/apache/cloudstack/api/command/user/account/AddAccountToProj
ec
tCmd.java 36df579

api/src/org/apache/cloudstack/api/command/user/account/DeleteAccountFro
mP
rojectCmd.java f6aa36c

api/src/org/apache/cloudstack/api/command/user/project/UpdateProjectInv
it
ationCmd.java dda7b54
   server/src/com/cloud/projects/ProjectManager.java f568146
   server/src/com/cloud/projects/ProjectManagerImpl.java 5a0ed1c
   server/test/com/cloud/projects/MockProjectManagerImpl.java dc377ff

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


 Testing
 ---

 Testing done on master.


 Thanks,

 David Grizzanti


>>>
>>
>
>
>
>-- 
>Daan

RE: 4.4 Feature Freeze

[Paul Angus]

To stick my oar in,

I think that 3 days is too short a time for people to get round to doing 
meaningful testing, particularly for those of us doing it on a purely voluntary 
basis.

Also I got the feeling that we were spinning up new RCs before it was clear 
that all issues with the previous RC had been fixed and committed.

Maybe a -1 has to be accompanied by a Jira ticket marked as a blocker.  People 
should carry on testing an RC after it's vote has been cancelled and adding -1s 
and Jira blockers tickets, to avoid a new RC which is going to be -1ed 
immediately...  Once the blockers are cleared we should be good to go for the 
next RC.




Regards

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

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 04 March 2014 15:55
To: dev
Subject: Re: 4.4 Feature Freeze

Animesh, You are doing a great job as guard on our present release and I don't 
recall features slipping in either. instead those should now be added to the 
master branch. If Sebastien made it sound that way it is probably because of 
something else that is bothering him.

However, Sebastien makes a very good point and I would go further. In my 
opinion we shouldn't be talking about how many months we keep between releases. 
If I make a new feature I want it scrutinized by all the guru's. Once they have 
nothing to nag about anymore it should be in in less then a month. We are a 
long way from that, but having to plan a feature in advance is never going to 
advance quality and instead will always be a constraint on it.

I could make the finger pointing point as well; At Schuberg Philis we are 
dedicating a lot of effort to quality, both by tracking bug findings and by 
setting up an automated test environment. I would prefer to spend this energy 
in making nice features for the next release. There is seven of us now and I 
don't think we spend one seventh of our energy/time in new features over the 
last period. The next release is containing a bunch of features already that 
won't be stable from the get go anyway. let's make a good product before we 
make it greater.

So, can we find common ground on this issue? My take, rather one feature per 
release (each week) with high quality and intensive testing then three features 
with divided attention to the code involved. This is not a proposal, yet. Just 
an illustration of my emotions.

kind regards,
Daan

On Tue, Mar 4, 2014 at 1:45 PM, Sebastien Goasguen  wrote:
>
> On Mar 3, 2014, at 8:18 PM, Animesh Chaturvedi 
>  wrote:
>
>>
>>
>>> -Original Message-
>>> From: Sebastien Goasguen [mailto:run...@gmail.com]
>>> Sent: Sunday, March 02, 2014 10:13 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: 4.4 Feature Freeze
>>>
>>> My take is that we are slipping on RC and re-voting because we are
>>> forcing code into the release.
>>>
>> [Animesh] That is not right, for 4.3 I had called out feature freeze date 
>> clearly and do not recall new feature added.  IMHO the one challenge as 
>> community that we have which has been raised earlier also is QA contribution 
>> is primarily coming from one organization. Most other folks start taking the 
>> release for a spin only after RC2/RC3 or so and then we see additional 
>> issues and more re-spins.  We really have to get all engaged in testing much 
>> earlier in the cycle. Sudha used to call out for help on QA activity but in 
>> prior releases I don't think she got much volunteers. We have huge technical 
>> debt and that is not going to go away with pointing fingers. If a specific 
>> scenario is benefiting someone as a user/developer of CloudStack and it 
>> turns out is not guarded with automation sufficiently and regresses in a 
>> release shouldn't the person using it also take some responsibility for 
>> safeguarding it with automation?
>>
>
>
> Of course everyone is a stakeholder in making CloudStack a high quality 
> software.
>
> I am not pointing fingers at anyone I am just expressing my perception of 
> what is going on. I have seen several things lately where it seems that we 
> prefer to put half-baked features in a major release rather than wait.
>
> Say we release every 6 months, since releases are far apart this puts stress 
> on the developer to put his feature "in" before feature freeze, perhaps 
> sacrificing quality and testing. If we were to release more often then the 
> stress to "miss" a release would be alleviated.
>
> I'd rather see/know that developers don't rush their features because they 
> know they can see it in less than 4 months then see features being added to a 
> release in fear of missing a cycle.
>
> The issue of QA is another one. Personally I'd like to start testing a 
> release branch once code has stabilized and I'd prefer to see a RM lock down 
> on the release before testing. What we have seen (and I'd be happy to be 
> wrong), is lots of code changes -a lo

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

[Alena Prokharchyk]

Antonio, I don¹t have a history about why we return cmdNameResponse
instead of returning actual command name. We might change the method name
in the future.

And yes, please go ahead and create a new method in BaseCmd.

-Alena.

On 3/4/14, 1:02 AM, "Antonio Fornié Casarrubios"
 wrote:

>Alena, I saw it, at first I thought it would be a problem in a certain cmd
>and then I saw it's the same for all of them. Actually
>Cmd#getCommandName()
>should give us what we want here, the command name, right? Why are we
>returning the cmdNameResponse instead?
>
>On top of that, if we continue this way (getting it from the annotation as
>you propose) then we would end up having N places with the same code smell
>(a couple of lines getting the actual cmd name from the annotation), so
>instead I should create a new method in the BaseCmd that does this, so
>that
>these clients (like my code) only have to do: cmd.getActualCmdName()
>
>...but then, have you got a suggestion for how to call this method
>considering that we already have a method getCommandName?
>
>
>
>
>2014-03-04 1:44 GMT+01:00 Alena Prokharchyk
>:
>
>>This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/17888/
>>
>> Antonio, when you log the WARN about incorrect param name, can you
>>please past the actual name of the command? Right now you log the
>>response object name instead:
>>
>> 2014-03-03 16:41:57,806 WARN  [c.c.a.d.ParamGenericValidationWorker]
>>(1574968208@qtp-585372613-2:ctx-0261a262 ctx-9867c49e) Received unknown
>>parameters for command listregionsresponse. Unknown parameters : listall
>> 2014-03-03 16:41:57,843 WARN  [c.c.a.d.ParamGenericValidationWorker]
>>(589128916@qtp-585372613-5:ctx-80f1e7ec ctx-8d796be3) Received unknown
>>parameters for command listprojectsresponse. Unknown parameters :
>>accountid
>>
>>
>> You can get the command name from @APICommand annotation
>>
>>
>> - Alena Prokharchyk
>>
>> On March 4th, 2014, 12:18 a.m. UTC, Antonio Fornie wrote:
>>   Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and
>> Hugo Trippaers.
>> By Antonio Fornie.
>>
>> *Updated March 4, 2014, 12:18 a.m.*
>>  *Repository: * cloudstack-git
>> Description
>>
>> Dispatcher corrections, refactoring and tests. Corrects problems from
>>previous attempts that were reverted by Alena. Most of the changes are
>>the same, but this one is not creating conflicts of Map types for Aync
>>Commands or for parameters as Lists or Maps.
>>
>>   Testing
>>
>> Full build and test plus manually testing many features. Also including
>>CreateTagsCommand that failed in previous commit.
>>
>> All unit and integration tests.
>>
>> Test CS Web UI with the browser going through several use cases.
>>
>> Also use the CS API by sending HTTP requests generated manually
>>including requests for Async Commands with Map parameters and during
>>these tests apart fromtesting correct functionality I also debugged to
>>check that Maps created correctly where they should but also that in the
>>cases where the async command must be persisted and later on retrieved
>>and deserialized by gson everything works ok and does what and where is
>>expected. An example based on the comment by
>>Alena:http://localhost:8096/client/api?command=createTags&resourceids=ids
>>&resourcetype=type&tags[0].key=region&tags[0].value=canada
>> Also other examples
>>likehttp://localhost:8096/client/api?command=createSecondaryStagingStore&;
>>url=httpbla&details[0].key=region&details[0].value=canada&details[1].key=
>>element&details[1].value=fire
>>
>>   Diffs
>>
>>- api/src/org/apache/cloudstack/api/ApiConstants.java (7b7f9ca)
>>- api/src/org/apache/cloudstack/api/BaseCmd.java (0e83cee)
>>- api/src/org/apache/cloudstack/api/BaseListCmd.java (c1a4b4c)
>>- 
>>api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java
>>(b2c6734)
>>- 
>>api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java
>>(cf5d355)
>>- 
>>api/src/org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleV
>>mProfileCmd.java
>>(570e018)
>>- 
>>server/resources/META-INF/cloudstack/core/spring-server-core-misc-context
>>.xml
>>(fd2f5fb)
>>- server/src/com/cloud/api/ApiAsyncJobDispatcher.java (f037f2e)
>>- server/src/com/cloud/api/ApiDispatcher.java (ed95c72)
>>- server/src/com/cloud/api/ApiServer.java (25792fb)
>>- server/src/com/cloud/api/ApiServlet.java (46f7eba)
>>- server/src/com/cloud/api/dispatch/CommandCreationWorker.java
>>(PRE-CREATION)
>>- server/src/com/cloud/api/dispatch/DispatchChain.java (PRE-CREATION)
>>- server/src/com/cloud/api/dispatch/DispatchChainFactory.java
>>(PRE-CREATION)
>>- server/src/com/cloud/api/dispatch/DispatchTask.java (PRE-CREATION)
>>- server/src/com/cloud/api/dispatch/DispatchWorker.java
>>(PRE-CREATION)
>>- server/src/com/cloud/api/dispatch/ParamGenericValidationWorker.java
>>(PRE-CREATION)
>>- server/src/com/cloud/api/dispatch/

RE: 4.4 Feature Freeze

[Animesh Chaturvedi]

> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Tuesday, March 04, 2014 4:45 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
> 
> 
> On Mar 3, 2014, at 8:18 PM, Animesh Chaturvedi
>  wrote:
> 
> >
> >
> >> -Original Message-
> >> From: Sebastien Goasguen [mailto:run...@gmail.com]
> >> Sent: Sunday, March 02, 2014 10:13 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: 4.4 Feature Freeze
> >>
> >> My take is that we are slipping on RC and re-voting because we are
> >> forcing code into the release.
> >>
> > [Animesh] That is not right, for 4.3 I had called out feature freeze date
> clearly and do not recall new feature added.  IMHO the one challenge as
> community that we have which has been raised earlier also is QA
> contribution is primarily coming from one organization. Most other folks
> start taking the release for a spin only after RC2/RC3 or so and then we see
> additional issues and more re-spins.  We really have to get all engaged in
> testing much earlier in the cycle. Sudha used to call out for help on QA
> activity but in prior releases I don't think she got much volunteers. We have
> huge technical debt and that is not going to go away with pointing fingers. If
> a specific scenario is benefiting someone as a user/developer of CloudStack
> and it turns out is not guarded with automation sufficiently and regresses in
> a release shouldn't the person using it also take some responsibility for
> safeguarding it with automation?
> >
> 
> 
> Of course everyone is a stakeholder in making CloudStack a high quality
> software.
> 
> I am not pointing fingers at anyone I am just expressing my perception of
> what is going on. I have seen several things lately where it seems that we
> prefer to put half-baked features in a major release rather than wait.
> 
> Say we release every 6 months, since releases are far apart this puts stress
> on the developer to put his feature "in" before feature freeze, perhaps
> sacrificing quality and testing. If we were to release more often then the
> stress to "miss" a release would be alleviated.
[Animesh] I need some more time to rationalize and put together mu thoughts on 
6 months v/s 4 months. But my first priority is 4.3 so will come to it later
> 
> I'd rather see/know that developers don't rush their features because they
> know they can see it in less than 4 months then see features being added to
> a release in fear of missing a cycle.
> 
> The issue of QA is another one. Personally I'd like to start testing a release
> branch once code has stabilized and I'd prefer to see a RM lock down on the
> release before testing. 
[Animesh] As soon as we did the first RC I had created the forward branch and 
4.3 branch checkins were not allowed
What we have seen (and I'd be happy to be wrong), is
> lots of code changes -a lot of times without bug ids- even after an RC was
> out (even though this got corrected in the latest RC). 
[Animesh] I hate that too, I had called out to many folks that we need a bug ID 
for any cherry-pick.

When there is so much
> churn on a release so close to an RC being cut it really is not conducive to
> testing. Maybe the churn is not an issue, but imho I would like to see every
> commit being with a bug ID and being a direct decision of the RM.
[Animesh] Certainly once I have wrapped up 4.3 I will put a report for each RC 
to help us analyze how can we improve. Even during RCs most feedback came from 
only a few handful of people, may be other community members were testing but 
did not provide feedback but atleast from the data it does looks like testing 
involvement even during RCs is limited. Once we get a -1 on RC I think people 
holdback on testing and then next RC we find something else.
> 
> -Sebastien

Re: Review Request 17790: Domain-Account-User Sync Up Among Multiple Regions

[Daan Hoogland]

This week? should be ok. end of next week is too late!

On Tue, Mar 4, 2014 at 6:17 PM, Alex Ough  wrote:
> Do you think it is ok to wrap up the implementation until the end of this
> week to make this included in 4.4 release?
>
> Thanks
> Alex Ough
>
>
> On Sun, Mar 2, 2014 at 2:10 PM, Daan Hoogland 
> wrote:
>>
>> two weeks from now, but under debate. Let's go with that, though.
>>
>> On Sun, Mar 2, 2014 at 1:17 AM, Alex Ough  wrote:
>> > Can you tell me when the deadline for 4.4 is?
>> >
>> > Thanks
>> > Alex Ough
>> >
>> >
>> > On Sat, Mar 1, 2014 at 2:26 PM, Daan Hoogland 
>> > wrote:
>> >>
>> >> Ha Alex,
>> >>
>> >> branch 4.3 is going to be a problem. We will be able to release this
>> >> with 4.4 if we hurry.
>> >>
>> >> On Fri, Feb 28, 2014 at 4:01 PM, Alex Ough 
>> >> wrote:
>> >> > Hi Daan,
>> >> >
>> >> > 1. Yes, we'll update the request once all the unit tests are
>> >> > completed.
>> >> > 2. And yes, it is a branch from 4.3
>> >> > 3. I'm using the global parameter, called
>> >> > 'region.auto.generation.interval'
>> >> > and the value is 0 (millisec) by default.
>> >> > If you set the value more than 0, it will automatically
>> >> > create/update/remove domains/accounts/users with that interval,
>> >> > which will trigger the scheduled full scan to sync the newly
>> >> > changed
>> >> > resources.
>> >> >
>> >> > Let me know if you need more info.
>> >> > Thanks
>> >> > Alex Ough
>> >> >
>> >> >
>> >> > On Thu, Feb 27, 2014 at 3:50 PM, Daan Hoogland
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> I see, great.
>> >> >>
>> >> >> I will find a moment to apply it and test. It looks good at first
>> >> >> sight.
>> >> >>
>> >> >> Don't forget adding the license header to the new files. Are you
>> >> >> updating the review request with these tests?
>> >> >>
>> >> >> You are using a local branch to implement this on,
>> >> >> 'alexoughsg/Albatross'  is a fork of cloudstack, is it?
>> >> >> Let's discuss merge back and testing.
>> >> >> Do you have a integration test script in Marvin and/or scenarios
>> >> >> that
>> >> >> will ensure continued functionality for the sync feature?
>> >> >>
>> >> >>
>> >> >> thanks,
>> >> >> Daan
>> >> >>
>> >> >> On Thu, Feb 27, 2014 at 9:19 PM, Alex Ough 
>> >> >> wrote:
>> >> >> > Hi Daan,
>> >> >> >
>> >> >> > We started to work on implementing unit tests and checked in some
>> >> >> > of
>> >> >> > them,
>> >> >> > so please review them and let us know if there is any
>> >> >> > comments/suggestions.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > https://github.com/alexoughsg/Albatross/commit/fca94db36054ee35f5da85c69c2471430e0eebfe
>> >> >> >
>> >> >> > Thanks
>> >> >> > Alex Ough
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Feb 13, 2014 at 3:15 PM, Alex Ough 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> We're just about to add unit tests, so I'll add them once
>> >> >> >> completed.
>> >> >> >>
>> >> >> >> Thanks
>> >> >> >> Alex Ough
>> >> >> >>
>> >> >> >>
>> >> >> >> On Thu, Feb 13, 2014 at 3:12 PM, Daan Hoogland
>> >> >> >> 
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> h Alex,
>> >> >> >>>
>> >> >> >>>  looks alright (i did mean with newlines but I don't know if
>> >> >> >>> this
>> >> >> >>> is
>> >> >> >>> actually caught by our checkstyle run) I was wondering if you
>> >> >> >>> have
>> >> >> >>> any
>> >> >> >>> unit
>> >> >> >>> tests for your code. I can see you did take testing seriously
>> >> >> >>> and I
>> >> >> >>> would
>> >> >> >>> like to see this formalized for future reference and repetition
>> >> >> >>> on
>> >> >> >>> updates.
>> >> >> >>> Can you add some stuff in this line?
>> >> >> >>>
>> >> >> >>> thanks,
>> >> >> >>> Daan
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Thu, Feb 13, 2014 at 9:52 PM, Alex Ough
>> >> >> >>> 
>> >> >> >>> wrote:
>> >> >> 
>> >> >>  Hi Daan,
>> >> >>  Does it look good to you?
>> >> >> 
>> >> >>  Thanks
>> >> >>  Alex Ough
>> >> >> 
>> >> >> 
>> >> >>  On Mon, Feb 10, 2014 at 1:07 PM, Alex Ough
>> >> >>  
>> >> >>  wrote:
>> >> >> >
>> >> >> > This is an automatically generated e-mail. To reply, visit:
>> >> >> > https://reviews.apache.org/r/17790/
>> >> >> >
>> >> >> > Review request for cloudstack.
>> >> >> > By Alex Ough.
>> >> >> >
>> >> >> > Updated Feb. 10, 2014, 7:06 p.m.
>> >> >> >
>> >> >> > Changes
>> >> >> >
>> >> >> > Updates for Daan's request.
>> >> >> >
>> >> >> > Repository: cloudstack-git
>> >> >> >
>> >> >> > Description
>> >> >> >
>> >> >> > Currently, under the environment of cloudstack with multiple
>> >> >> > regions,
>> >> >> > each region has its own management server running with a
>> >> >> > separate
>> >> >> > database,
>> >> >> > which will cause data discrepancies when users
>> >> >> > create/update/delete
>> >> >> > domain/account/user data independently in each management
>> >> >> > server.
>> >> >> > So
>> >> >> > to
>> >>

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[Daan Hoogland]

We can not change the response for this api call? so other apis aren't touched?

On Tue, Mar 4, 2014 at 6:31 PM, Alena Prokharchyk
 wrote:
> Daan, you can¹t extend the response with more parameters as its a generic
> SuccessResponse used by many Apis, and you can¹t add anything a particular
> call specific to that.
>
> I think we shouldn¹t fix the bug at this point. You can always get the
> additional information you need by executing corresponding list* call.
>
> -Alena.
>
> On 3/4/14, 12:05 AM, "Daan Hoogland"  wrote:
>
>>H Alena,
>>
>>You are right. I was under the impression that response format was
>>being extended.
>>
>>I saw you already reverted. If the response was extended with the
>>extra value it would be alright, would it?
>>
>>On Mon, Mar 3, 2014 at 7:06 PM, Alena Prokharchyk
>> wrote:
>>> Daan, this fix break API compatibility! All the customers using these
>>>API,
>>> will end up with broken code on their side. As the response format is
>>> changed. Can you please roll it back?
>>>
>>> Thanks,
>>> Alena.
>>>
>>> On 3/3/14, 2:03 AM, "daan Hoogland"  wrote:
>>>

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

Ship it!


ebcaec8632dbd92c071317f3190915244a287afb

- daan Hoogland


On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17591/
> ---
>
> (Updated Jan. 31, 2014, 2:51 p.m.)
>
>
> Review request for cloudstack.
>
>
> Bugs: CLOUDSTACK-5872
> https://issues.apache.org/jira/browse/CLOUDSTACK-5872
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
> CLOUDSTACK-5872: Async response from addAccountToProject doesn't
>contain useful information
>
> Updated the following classes to return a project object after async
>jobs complete:
>  api/src/com/cloud/projects/ProjectService.java |  6 ++--
>  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
>  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
>  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
>  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
>  .../src/com/cloud/projects/ProjectManagerImpl.java | 34
>+++---
>  .../com/cloud/projects/MockProjectManagerImpl.java | 16 +-
>
> Previously these API commands only returned "success => true" in the
>aysnc job result.  Now it returns the project that a user was
>added/deleted to.
>
>
> Diffs
> -
>
>   api/src/com/cloud/projects/ProjectService.java dc882ef
>
>api/src/org/apache/cloudstack/api/command/user/account/AddAccountToProj
>ec
>tCmd.java 36df579
>
>api/src/org/apache/cloudstack/api/command/user/account/DeleteAccountFro
>mP
>rojectCmd.java f6aa36c
>
>api/src/org/apache/cloudstack/api/command/user/project/UpdateProjectInv
>it
>ationCmd.java dda7b54
>   server/src/com/cloud/projects/ProjectManager.java f568146
>   server/src/com/cloud/projects/ProjectManagerImpl.java 5a0ed1c
>   server/test/com/cloud/projects/MockProjectManagerImpl.java dc377ff
>
> Diff: https://reviews.apache.org/r/17591/diff/
>
>
> Testing
> ---
>
> Testing done on master.
>
>
> Thanks,
>
> David Grizzanti
>
>

>>>
>>
>>
>>
>>--
>>Daan
>



-- 
Daan

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[Alena Prokharchyk]

We are not gonna change the response for API calls mentioned in the bug
filed by David. We will just leave Apis the way it is. The original bug
should be closed as WontFix, and I already reverted the commit.

I didn’t quite get your question about other APIs, could you please
elaborate? 

-Alena.

On 3/4/14, 10:28 AM, "Daan Hoogland"  wrote:

>We can not change the response for this api call? so other apis aren't
>touched?
>
>On Tue, Mar 4, 2014 at 6:31 PM, Alena Prokharchyk
> wrote:
>> Daan, you can¹t extend the response with more parameters as its a
>>generic
>> SuccessResponse used by many Apis, and you can¹t add anything a
>>particular
>> call specific to that.
>>
>> I think we shouldn¹t fix the bug at this point. You can always get the
>> additional information you need by executing corresponding list* call.
>>
>> -Alena.
>>
>> On 3/4/14, 12:05 AM, "Daan Hoogland"  wrote:
>>
>>>H Alena,
>>>
>>>You are right. I was under the impression that response format was
>>>being extended.
>>>
>>>I saw you already reverted. If the response was extended with the
>>>extra value it would be alright, would it?
>>>
>>>On Mon, Mar 3, 2014 at 7:06 PM, Alena Prokharchyk
>>> wrote:
 Daan, this fix break API compatibility! All the customers using these
API,
 will end up with broken code on their side. As the response format is
 changed. Can you please roll it back?

 Thanks,
 Alena.

 On 3/3/14, 2:03 AM, "daan Hoogland"  wrote:

>
>---
>This is an automatically generated e-mail. To reply, visit:
>https://reviews.apache.org/r/17591/#review35953
>---
>
>Ship it!
>
>
>ebcaec8632dbd92c071317f3190915244a287afb
>
>- daan Hoogland
>
>
>On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/17591/
>> ---
>>
>> (Updated Jan. 31, 2014, 2:51 p.m.)
>>
>>
>> Review request for cloudstack.
>>
>>
>> Bugs: CLOUDSTACK-5872
>> https://issues.apache.org/jira/browse/CLOUDSTACK-5872
>>
>>
>> Repository: cloudstack-git
>>
>>
>> Description
>> ---
>>
>> CLOUDSTACK-5872: Async response from addAccountToProject doesn't
>>contain useful information
>>
>> Updated the following classes to return a project object after async
>>jobs complete:
>>  api/src/com/cloud/projects/ProjectService.java |  6 ++--
>>  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
>>  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
>>  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
>>  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
>>  .../src/com/cloud/projects/ProjectManagerImpl.java | 34
>>+++---
>>  .../com/cloud/projects/MockProjectManagerImpl.java | 16 +-
>>
>> Previously these API commands only returned "success => true" in the
>>aysnc job result.  Now it returns the project that a user was
>>added/deleted to.
>>
>>
>> Diffs
>> -
>>
>>   api/src/com/cloud/projects/ProjectService.java dc882ef
>>
>>api/src/org/apache/cloudstack/api/command/user/account/AddAccountToPr
>>oj
>>ec
>>tCmd.java 36df579
>>
>>api/src/org/apache/cloudstack/api/command/user/account/DeleteAccountF
>>ro
>>mP
>>rojectCmd.java f6aa36c
>>
>>api/src/org/apache/cloudstack/api/command/user/project/UpdateProjectI
>>nv
>>it
>>ationCmd.java dda7b54
>>   server/src/com/cloud/projects/ProjectManager.java f568146
>>   server/src/com/cloud/projects/ProjectManagerImpl.java 5a0ed1c
>>   server/test/com/cloud/projects/MockProjectManagerImpl.java dc377ff
>>
>> Diff: https://reviews.apache.org/r/17591/diff/
>>
>>
>> Testing
>> ---
>>
>> Testing done on master.
>>
>>
>> Thanks,
>>
>> David Grizzanti
>>
>>
>

>>>
>>>
>>>
>>>--
>>>Daan
>>
>
>
>
>-- 
>Daan

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[Daan Hoogland]

I mean not returning a SuccessResponse but some custom variety to it.

On Tue, Mar 4, 2014 at 7:44 PM, Alena Prokharchyk
 wrote:
> We are not gonna change the response for API calls mentioned in the bug
> filed by David. We will just leave Apis the way it is. The original bug
> should be closed as WontFix, and I already reverted the commit.
>
> I didn't quite get your question about other APIs, could you please
> elaborate?
>
> -Alena.
>
> On 3/4/14, 10:28 AM, "Daan Hoogland"  wrote:
>
>>We can not change the response for this api call? so other apis aren't
>>touched?
>>
>>On Tue, Mar 4, 2014 at 6:31 PM, Alena Prokharchyk
>> wrote:
>>> Daan, you can¹t extend the response with more parameters as its a
>>>generic
>>> SuccessResponse used by many Apis, and you can¹t add anything a
>>>particular
>>> call specific to that.
>>>
>>> I think we shouldn¹t fix the bug at this point. You can always get the
>>> additional information you need by executing corresponding list* call.
>>>
>>> -Alena.
>>>
>>> On 3/4/14, 12:05 AM, "Daan Hoogland"  wrote:
>>>
H Alena,

You are right. I was under the impression that response format was
being extended.

I saw you already reverted. If the response was extended with the
extra value it would be alright, would it?

On Mon, Mar 3, 2014 at 7:06 PM, Alena Prokharchyk
 wrote:
> Daan, this fix break API compatibility! All the customers using these
>API,
> will end up with broken code on their side. As the response format is
> changed. Can you please roll it back?
>
> Thanks,
> Alena.
>
> On 3/3/14, 2:03 AM, "daan Hoogland"  wrote:
>
>>
>>---
>>This is an automatically generated e-mail. To reply, visit:
>>https://reviews.apache.org/r/17591/#review35953
>>---
>>
>>Ship it!
>>
>>
>>ebcaec8632dbd92c071317f3190915244a287afb
>>
>>- daan Hoogland
>>
>>
>>On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:
>>>
>>> ---
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/17591/
>>> ---
>>>
>>> (Updated Jan. 31, 2014, 2:51 p.m.)
>>>
>>>
>>> Review request for cloudstack.
>>>
>>>
>>> Bugs: CLOUDSTACK-5872
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-5872
>>>
>>>
>>> Repository: cloudstack-git
>>>
>>>
>>> Description
>>> ---
>>>
>>> CLOUDSTACK-5872: Async response from addAccountToProject doesn't
>>>contain useful information
>>>
>>> Updated the following classes to return a project object after async
>>>jobs complete:
>>>  api/src/com/cloud/projects/ProjectService.java |  6 ++--
>>>  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
>>>  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
>>>  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
>>>  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
>>>  .../src/com/cloud/projects/ProjectManagerImpl.java | 34
>>>+++---
>>>  .../com/cloud/projects/MockProjectManagerImpl.java | 16 +-
>>>
>>> Previously these API commands only returned "success => true" in the
>>>aysnc job result.  Now it returns the project that a user was
>>>added/deleted to.
>>>
>>>
>>> Diffs
>>> -
>>>
>>>   api/src/com/cloud/projects/ProjectService.java dc882ef
>>>
>>>api/src/org/apache/cloudstack/api/command/user/account/AddAccountToPr
>>>oj
>>>ec
>>>tCmd.java 36df579
>>>
>>>api/src/org/apache/cloudstack/api/command/user/account/DeleteAccountF
>>>ro
>>>mP
>>>rojectCmd.java f6aa36c
>>>
>>>api/src/org/apache/cloudstack/api/command/user/project/UpdateProjectI
>>>nv
>>>it
>>>ationCmd.java dda7b54
>>>   server/src/com/cloud/projects/ProjectManager.java f568146
>>>   server/src/com/cloud/projects/ProjectManagerImpl.java 5a0ed1c
>>>   server/test/com/cloud/projects/MockProjectManagerImpl.java dc377ff
>>>
>>> Diff: https://reviews.apache.org/r/17591/diff/
>>>
>>>
>>> Testing
>>> ---
>>>
>>> Testing done on master.
>>>
>>>
>>> Thanks,
>>>
>>> David Grizzanti
>>>
>>>
>>
>



--
Daan
>>>
>>
>>
>>
>>--
>>Daan
>



-- 
Daan

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[Alena Prokharchyk]

Daan, I don’t see the need for doing that. Take deleteAccountFromProject
API. Every delete command in CloudStack returns the success response;
seeing true/false is more than enough to figure out if the deletion was
successful. We follow this format in every delete* command in CS.

Now take addAccountToProject. This command neither modifies the account,
nor the project. It just creates a relationship between project and the
account, that you can later get by executing listProjectAccounts API.
Although we might have return success/accountObject-ProjectId in the
response instead of just returning the success, I don’t see the big need
for that. But if you insist on fixing it anyway, yes, the right way would
be extending SuccessResponse and use it in this particular API. Although
the response name “success” that we have to preserve, would be a bit
misleading considering that we are gonna return other information besides
just boolean param.


-Alena.


On 3/4/14, 10:48 AM, "Daan Hoogland"  wrote:

>I mean not returning a SuccessResponse but some custom variety to it.
>
>On Tue, Mar 4, 2014 at 7:44 PM, Alena Prokharchyk
> wrote:
>> We are not gonna change the response for API calls mentioned in the bug
>> filed by David. We will just leave Apis the way it is. The original bug
>> should be closed as WontFix, and I already reverted the commit.
>>
>> I didn't quite get your question about other APIs, could you please
>> elaborate?
>>
>> -Alena.
>>
>> On 3/4/14, 10:28 AM, "Daan Hoogland"  wrote:
>>
>>>We can not change the response for this api call? so other apis aren't
>>>touched?
>>>
>>>On Tue, Mar 4, 2014 at 6:31 PM, Alena Prokharchyk
>>> wrote:
 Daan, you can¹t extend the response with more parameters as its a
generic
 SuccessResponse used by many Apis, and you can¹t add anything a
particular
 call specific to that.

 I think we shouldn¹t fix the bug at this point. You can always get the
 additional information you need by executing corresponding list* call.

 -Alena.

 On 3/4/14, 12:05 AM, "Daan Hoogland"  wrote:

>H Alena,
>
>You are right. I was under the impression that response format was
>being extended.
>
>I saw you already reverted. If the response was extended with the
>extra value it would be alright, would it?
>
>On Mon, Mar 3, 2014 at 7:06 PM, Alena Prokharchyk
> wrote:
>> Daan, this fix break API compatibility! All the customers using
>>these
>>API,
>> will end up with broken code on their side. As the response format
>>is
>> changed. Can you please roll it back?
>>
>> Thanks,
>> Alena.
>>
>> On 3/3/14, 2:03 AM, "daan Hoogland"  wrote:
>>
>>>
>>>---
>>>This is an automatically generated e-mail. To reply, visit:
>>>https://reviews.apache.org/r/17591/#review35953
>>>---
>>>
>>>Ship it!
>>>
>>>
>>>ebcaec8632dbd92c071317f3190915244a287afb
>>>
>>>- daan Hoogland
>>>
>>>
>>>On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:

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

 (Updated Jan. 31, 2014, 2:51 p.m.)


 Review request for cloudstack.


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


 Repository: cloudstack-git


 Description
 ---

 CLOUDSTACK-5872: Async response from addAccountToProject doesn't
contain useful information

 Updated the following classes to return a project object after
async
jobs complete:
  api/src/com/cloud/projects/ProjectService.java |  6 ++--
  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
  .../src/com/cloud/projects/ProjectManagerImpl.java | 34
+++---
  .../com/cloud/projects/MockProjectManagerImpl.java | 16
+-

 Previously these API commands only returned "success => true" in
the
aysnc job result.  Now it returns the project that a user was
added/deleted to.


 Diffs
 -

   api/src/com/cloud/projects/ProjectService.java dc882ef

api/src/org/apache/cloudstack/api/command/user/account/AddAccountTo
Pr
oj
ec
>

Re: Review Request 17790: Domain-Account-User Sync Up Among Multiple Regions

[Alex Ough]

Do you think it is ok to wrap up the implementation until the end of this
week to make this included in 4.4 release?

Thanks
Alex Ough


On Sun, Mar 2, 2014 at 2:10 PM, Daan Hoogland wrote:

> two weeks from now, but under debate. Let's go with that, though.
>
> On Sun, Mar 2, 2014 at 1:17 AM, Alex Ough  wrote:
> > Can you tell me when the deadline for 4.4 is?
> >
> > Thanks
> > Alex Ough
> >
> >
> > On Sat, Mar 1, 2014 at 2:26 PM, Daan Hoogland 
> > wrote:
> >>
> >> Ha Alex,
> >>
> >> branch 4.3 is going to be a problem. We will be able to release this
> >> with 4.4 if we hurry.
> >>
> >> On Fri, Feb 28, 2014 at 4:01 PM, Alex Ough 
> wrote:
> >> > Hi Daan,
> >> >
> >> > 1. Yes, we'll update the request once all the unit tests are
> completed.
> >> > 2. And yes, it is a branch from 4.3
> >> > 3. I'm using the global parameter, called
> >> > 'region.auto.generation.interval'
> >> > and the value is 0 (millisec) by default.
> >> > If you set the value more than 0, it will automatically
> >> > create/update/remove domains/accounts/users with that interval,
> >> > which will trigger the scheduled full scan to sync the newly
> changed
> >> > resources.
> >> >
> >> > Let me know if you need more info.
> >> > Thanks
> >> > Alex Ough
> >> >
> >> >
> >> > On Thu, Feb 27, 2014 at 3:50 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> >> > wrote:
> >> >>
> >> >> I see, great.
> >> >>
> >> >> I will find a moment to apply it and test. It looks good at first
> >> >> sight.
> >> >>
> >> >> Don't forget adding the license header to the new files. Are you
> >> >> updating the review request with these tests?
> >> >>
> >> >> You are using a local branch to implement this on,
> >> >> 'alexoughsg/Albatross'  is a fork of cloudstack, is it?
> >> >> Let's discuss merge back and testing.
> >> >> Do you have a integration test script in Marvin and/or scenarios that
> >> >> will ensure continued functionality for the sync feature?
> >> >>
> >> >>
> >> >> thanks,
> >> >> Daan
> >> >>
> >> >> On Thu, Feb 27, 2014 at 9:19 PM, Alex Ough 
> >> >> wrote:
> >> >> > Hi Daan,
> >> >> >
> >> >> > We started to work on implementing unit tests and checked in some
> of
> >> >> > them,
> >> >> > so please review them and let us know if there is any
> >> >> > comments/suggestions.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> https://github.com/alexoughsg/Albatross/commit/fca94db36054ee35f5da85c69c2471430e0eebfe
> >> >> >
> >> >> > Thanks
> >> >> > Alex Ough
> >> >> >
> >> >> >
> >> >> > On Thu, Feb 13, 2014 at 3:15 PM, Alex Ough 
> >> >> > wrote:
> >> >> >>
> >> >> >> We're just about to add unit tests, so I'll add them once
> completed.
> >> >> >>
> >> >> >> Thanks
> >> >> >> Alex Ough
> >> >> >>
> >> >> >>
> >> >> >> On Thu, Feb 13, 2014 at 3:12 PM, Daan Hoogland
> >> >> >> 
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> h Alex,
> >> >> >>>
> >> >> >>>  looks alright (i did mean with newlines but I don't know if this
> >> >> >>> is
> >> >> >>> actually caught by our checkstyle run) I was wondering if you
> have
> >> >> >>> any
> >> >> >>> unit
> >> >> >>> tests for your code. I can see you did take testing seriously
> and I
> >> >> >>> would
> >> >> >>> like to see this formalized for future reference and repetition
> on
> >> >> >>> updates.
> >> >> >>> Can you add some stuff in this line?
> >> >> >>>
> >> >> >>> thanks,
> >> >> >>> Daan
> >> >> >>>
> >> >> >>>
> >> >> >>> On Thu, Feb 13, 2014 at 9:52 PM, Alex Ough <
> alex.o...@sungard.com>
> >> >> >>> wrote:
> >> >> 
> >> >>  Hi Daan,
> >> >>  Does it look good to you?
> >> >> 
> >> >>  Thanks
> >> >>  Alex Ough
> >> >> 
> >> >> 
> >> >>  On Mon, Feb 10, 2014 at 1:07 PM, Alex Ough <
> alex.o...@sungard.com>
> >> >>  wrote:
> >> >> >
> >> >> > This is an automatically generated e-mail. To reply, visit:
> >> >> > https://reviews.apache.org/r/17790/
> >> >> >
> >> >> > Review request for cloudstack.
> >> >> > By Alex Ough.
> >> >> >
> >> >> > Updated Feb. 10, 2014, 7:06 p.m.
> >> >> >
> >> >> > Changes
> >> >> >
> >> >> > Updates for Daan's request.
> >> >> >
> >> >> > Repository: cloudstack-git
> >> >> >
> >> >> > Description
> >> >> >
> >> >> > Currently, under the environment of cloudstack with multiple
> >> >> > regions,
> >> >> > each region has its own management server running with a
> separate
> >> >> > database,
> >> >> > which will cause data discrepancies when users
> >> >> > create/update/delete
> >> >> > domain/account/user data independently in each management
> server.
> >> >> > So
> >> >> > to
> >> >> > support multiple regions and provide one point of entry for
> each
> >> >> > customer,
> >> >> > this implementation duplicates domain/account/user information
> of
> >> >> > customers
> >> >> > in one region to all of the regions independently whenever
> there
> >> >> > is
> >> >> > any
> >> >> > change.
>

Re: [4.4] Feature request: root resize (FAO Marcus)

[Mike Tutkowski]

Just updated the ticket.

Thanks for checking!


On Tue, Mar 4, 2014 at 2:46 AM, Nux!  wrote:

> On 27.02.2014 09:29, Nux! wrote:
>
>> Hi,
>>
>> Having talked about this issue recently, I'd like to request this
>> feature so as to avoid template duplication.
>> Marcus, you said you have a working patch, if you get it to apply to
>> 4.4 I will invest time in testing it.
>>
>> I have opened an issue with rationale, example etc
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6181
>>
>
> Hello Mike & Wido, can you guys check out CLOUDSTACK-6181? Looks like your
> blessings are required for this to go through.
>
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>



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

Re: Review Request 17790: Domain-Account-User Sync Up Among Multiple Regions

[Alex Ough]

Yes, by 3/7.

Thanks
Alex Ough


On Tue, Mar 4, 2014 at 12:30 PM, Daan Hoogland wrote:

> This week? should be ok. end of next week is too late!
>
> On Tue, Mar 4, 2014 at 6:17 PM, Alex Ough  wrote:
> > Do you think it is ok to wrap up the implementation until the end of this
> > week to make this included in 4.4 release?
> >
> > Thanks
> > Alex Ough
> >
> >
> > On Sun, Mar 2, 2014 at 2:10 PM, Daan Hoogland 
> > wrote:
> >>
> >> two weeks from now, but under debate. Let's go with that, though.
> >>
> >> On Sun, Mar 2, 2014 at 1:17 AM, Alex Ough 
> wrote:
> >> > Can you tell me when the deadline for 4.4 is?
> >> >
> >> > Thanks
> >> > Alex Ough
> >> >
> >> >
> >> > On Sat, Mar 1, 2014 at 2:26 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Ha Alex,
> >> >>
> >> >> branch 4.3 is going to be a problem. We will be able to release this
> >> >> with 4.4 if we hurry.
> >> >>
> >> >> On Fri, Feb 28, 2014 at 4:01 PM, Alex Ough 
> >> >> wrote:
> >> >> > Hi Daan,
> >> >> >
> >> >> > 1. Yes, we'll update the request once all the unit tests are
> >> >> > completed.
> >> >> > 2. And yes, it is a branch from 4.3
> >> >> > 3. I'm using the global parameter, called
> >> >> > 'region.auto.generation.interval'
> >> >> > and the value is 0 (millisec) by default.
> >> >> > If you set the value more than 0, it will automatically
> >> >> > create/update/remove domains/accounts/users with that interval,
> >> >> > which will trigger the scheduled full scan to sync the newly
> >> >> > changed
> >> >> > resources.
> >> >> >
> >> >> > Let me know if you need more info.
> >> >> > Thanks
> >> >> > Alex Ough
> >> >> >
> >> >> >
> >> >> > On Thu, Feb 27, 2014 at 3:50 PM, Daan Hoogland
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> I see, great.
> >> >> >>
> >> >> >> I will find a moment to apply it and test. It looks good at first
> >> >> >> sight.
> >> >> >>
> >> >> >> Don't forget adding the license header to the new files. Are you
> >> >> >> updating the review request with these tests?
> >> >> >>
> >> >> >> You are using a local branch to implement this on,
> >> >> >> 'alexoughsg/Albatross'  is a fork of cloudstack, is it?
> >> >> >> Let's discuss merge back and testing.
> >> >> >> Do you have a integration test script in Marvin and/or scenarios
> >> >> >> that
> >> >> >> will ensure continued functionality for the sync feature?
> >> >> >>
> >> >> >>
> >> >> >> thanks,
> >> >> >> Daan
> >> >> >>
> >> >> >> On Thu, Feb 27, 2014 at 9:19 PM, Alex Ough  >
> >> >> >> wrote:
> >> >> >> > Hi Daan,
> >> >> >> >
> >> >> >> > We started to work on implementing unit tests and checked in
> some
> >> >> >> > of
> >> >> >> > them,
> >> >> >> > so please review them and let us know if there is any
> >> >> >> > comments/suggestions.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> https://github.com/alexoughsg/Albatross/commit/fca94db36054ee35f5da85c69c2471430e0eebfe
> >> >> >> >
> >> >> >> > Thanks
> >> >> >> > Alex Ough
> >> >> >> >
> >> >> >> >
> >> >> >> > On Thu, Feb 13, 2014 at 3:15 PM, Alex Ough <
> alex.o...@sungard.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> We're just about to add unit tests, so I'll add them once
> >> >> >> >> completed.
> >> >> >> >>
> >> >> >> >> Thanks
> >> >> >> >> Alex Ough
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Thu, Feb 13, 2014 at 3:12 PM, Daan Hoogland
> >> >> >> >> 
> >> >> >> >> wrote:
> >> >> >> >>>
> >> >> >> >>> h Alex,
> >> >> >> >>>
> >> >> >> >>>  looks alright (i did mean with newlines but I don't know if
> >> >> >> >>> this
> >> >> >> >>> is
> >> >> >> >>> actually caught by our checkstyle run) I was wondering if you
> >> >> >> >>> have
> >> >> >> >>> any
> >> >> >> >>> unit
> >> >> >> >>> tests for your code. I can see you did take testing seriously
> >> >> >> >>> and I
> >> >> >> >>> would
> >> >> >> >>> like to see this formalized for future reference and
> repetition
> >> >> >> >>> on
> >> >> >> >>> updates.
> >> >> >> >>> Can you add some stuff in this line?
> >> >> >> >>>
> >> >> >> >>> thanks,
> >> >> >> >>> Daan
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> On Thu, Feb 13, 2014 at 9:52 PM, Alex Ough
> >> >> >> >>> 
> >> >> >> >>> wrote:
> >> >> >> 
> >> >> >>  Hi Daan,
> >> >> >>  Does it look good to you?
> >> >> >> 
> >> >> >>  Thanks
> >> >> >>  Alex Ough
> >> >> >> 
> >> >> >> 
> >> >> >>  On Mon, Feb 10, 2014 at 1:07 PM, Alex Ough
> >> >> >>  
> >> >> >>  wrote:
> >> >> >> >
> >> >> >> > This is an automatically generated e-mail. To reply, visit:
> >> >> >> > https://reviews.apache.org/r/17790/
> >> >> >> >
> >> >> >> > Review request for cloudstack.
> >> >> >> > By Alex Ough.
> >> >> >> >
> >> >> >> > Updated Feb. 10, 2014, 7:06 p.m.
> >> >> >> >
> >> >> >> > Changes
> >> >> >> >
> >> >> >> > Updates for Daan's request.
> >> >> >> >
> >> >> >> > Repository: cloudstack-git
> >> >> >> >
> >> >> >> > Description
> >>

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[Daan Hoogland]

On Tue, Mar 4, 2014 at 7:57 PM, Alena Prokharchyk
 wrote:
> Although
> the response name "success" that we have to preserve,

So if we fi it this way the reponse should contain

displaytext : any text associated with the success or failure
success : true if operation is executed successfully

and then we could add whatever info we want.

I do feel for your argument that the name would be misleading.

@David you want to press on (we will be planning this for 5.0 instead of 4.4!)

-- 
Daan

SSO

[María Noelia Gil]

Hello, I am studying the operation of single sign-on in CloudStack. Does anyone 
can provide me information about this topic? 

I want to know if you can use SAML, OpenID, ..., and as it should be. 

Thank you.

RE: Removing TAGS

[Alex Huang]

Thanks Dave.  I think that makes it much clearer.  I'm +1 on it, especially 
given that it got pushed in this year.  

--Alex

> -Original Message-
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: Tuesday, March 4, 2014 4:00 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Removing TAGS
> 
> This really isn't 'our' history though. Most of the tags Sebastien referred to
> came in on January 8th[1]. When we moved to the ASF, we removed the
> vast majority of tags and branches as they simply didn't have a lot of context
> here, and increased the already-bewildering confusion most people
> experienced.
> 
> [1] http://mail-archives.apache.org/mod_mbox/cloudstack-
> commits/201401.mbox/%3caacd7ef5168d411ab6c71e382190f89b@git.apache
> .org%3e
> 
> --David
> 
> On Tue, Mar 4, 2014 at 2:48 AM, Daan Hoogland 
> wrote:
> > I am actually -1 on any history falsification or destruction. I have
> > no interest in this particular history but if citrix doesn't mind us
> > seeing it we should leave it as is.
> >
> > regads,
> > Daan
> >
> > On Mon, Mar 3, 2014 at 7:43 PM, Alex Huang 
> wrote:
> >> Sebastien,
> >>
> >> It's a -0 for me.  If it's important to do, sure.
> >>
> >> --Alex
> >>
> >>> -Original Message-
> >>> From: Sebastien Goasguen [mailto:run...@gmail.com]
> >>> Sent: Monday, March 3, 2014 9:54 AM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: Removing TAGS
> >>>
> >>>
> >>> On Mar 3, 2014, at 12:19 PM, Alex Huang 
> wrote:
> >>>
> >>> > What does it achieve?  Tags don't cost anything.  The code came from
> Citrix.
> >>> Removing the TAGS is not going to take that away.
> >>> >
> >>>
> >>> That's true they don't cost a thing, but anyone looking at the tags
> >>> and not knowing the history will get confused between cloudstack and
> >>> cloudplaftorm and will get confused between version numbers.
> >>>
> >>> I actually think it's almost a case of branding and that we need to
> >>> protect the cloudstack brand. At the very least, if you want to keep
> >>> the tags we should rename them to avoid confusion.
> >>>
> >>> -sebastien
> >>>
> >>> > I like having git metadata in case I need to go find something
> >>> > really old or
> >>> understand where the code made its fork.  It doesn't happen often
> >>> but I do like having the information if I need it.
> >>> >
> >>> > --Alex
> >>> >
> >>> >> -Original Message-
> >>> >> From: David Nalley [mailto:da...@gnsa.us]
> >>> >> Sent: Sunday, March 2, 2014 5:41 PM
> >>> >> To: dev@cloudstack.apache.org
> >>> >> Subject: Re: Removing TAGS
> >>> >>
> >>> >> Please do - obviously retain anything that is tied to an ACS
> >>> >> release; but it's a version control system - delete tags boldly.
> >>> >> :)
> >>> >>
> >>> >>
> >>> >> --David
> >>> >>
> >>> >> On Sun, Mar 2, 2014 at 1:26 PM, Sebastien Goasguen
> >>> >> 
> >>> >> wrote:
> >>> >>> Hi,
> >>> >>>
> >>> >>> When I look at the tags on git, there are a bunch of Citrix specific
> tags.
> >>> >>>
> >>> >>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=tags
> >>> >>>
> >>> >>> Can we clean those up ?
> >>> >>>
> >>> >>> I don't see why we need a TAG_CLOUDPLATFORM_2.2.15_GA2
> >>> >>>
> >>> >>> -sebastien
> >>> >>>
> >>> >>>
> >>
> >
> >
> >
> > --
> > Daan

Re: Review Request 18733: Refactor DbUpgradeUtils

[daan Hoogland]

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


tests fail:

Running com.cloud.upgrade.dao.DatabaseAccessObjectTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.139 sec <<< 
FAILURE!
Running com.cloud.upgrade.dao.DbUpgradeUtilsTest
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.306 sec <<< 
FAILURE!

Results :

Tests in error: 
  initializationError(com.cloud.upgrade.dao.DatabaseAccessObjectTest): 
Lcom/cloud/upgrade/dao/DatabaseAccessObject;
  com.cloud.upgrade.dao.DbUpgradeUtilsTest: 
Lcom/cloud/upgrade/dao/DatabaseAccessObject;

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


- daan Hoogland


On March 4, 2014, 4:13 p.m., Miguel Ferreira wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18733/
> ---
> 
> (Updated March 4, 2014, 4:13 p.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Refactor DbUpgradeUtils
> 
>   - Move database access code to new class DatabaseAccessObject. This was 
> done to ease the effort of testing, since DbUpgradeUtils has a static API and 
> it is harder to mock static things with Mockito.
>   - Log exceptions even if ignored.
>   - Add unit tests for both DbUpgradeUtils and DatabaseAccessObject.
>   - DbUpgradeUtils.dropTableColumnsIfExist(...) no longer throws 
> CloudRuntimeException to make it consistent with the other methods in the 
> class.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/DatabaseAccessObject.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/upgrade/dao/DbUpgradeUtils.java af23b87 
>   engine/schema/test/com/cloud/upgrade/dao/DatabaseAccessObjectTest.java 
> PRE-CREATION 
>   engine/schema/test/com/cloud/upgrade/dao/DbUpgradeUtilsTest.java 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/18733/diff/
> 
> 
> Testing
> ---
> 
> Ran all unit tests in eclipse.
> Ran "mvn clean install".
> 
> 
> Thanks,
> 
> Miguel Ferreira
> 
>

RE: Exception adding XenServer host to CS

[Anthony Xu]

>Do people have to run xe-switch-network-backend bridge before upgrading to
>4.4 (if they are using a Basic Zone)?
Correct.

>In my case, since I'm developing and able to start with a fresh DB and 
>XenServer hosts, it looks like I can just run xe-switch-network-backend bridge 
>before I create my zone, right?
Correct,

BTW,  reboot XS host is required to make the change take effect.

Anthony


-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Monday, March 03, 2014 2:52 PM
To: dev@cloudstack.apache.org
Cc: jaya...@apache.org
Subject: Re: Exception adding XenServer host to CS

Hi Anthony,

Thanks for the reply.

It looks like this is a change in 4.4.

Do people have to run xe-switch-network-backend bridge before upgrading to
4.4 (if they are using a Basic Zone)?

In my case, since I'm developing and able to start with a fresh DB and 
XenServer hosts, it looks like I can just run xe-switch-network-backend bridge 
before I create my zone, right?

Thanks!
Mike


On Mon, Mar 3, 2014 at 3:45 PM, Anthony Xu  wrote:

> Hi Mike,
>
> If you are using Security group enabled zone or basic zone, you need 
> to switch XS network mode from OVS to bridge since security group 
> doesn't work on OVS.
>
> xe-switch-network-backend bridge.
>
>
> Anthony
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Monday, March 03, 2014 12:39 PM
> To: dev@cloudstack.apache.org; jaya...@apache.org
> Subject: Re: Exception adding XenServer host to CS
>
> Hi Jayapal,
>
> I was wondering if this commit could be the reason why people can no 
> longer add XenServer hosts to clusters?
>
> 4b3784a98e57bc22bc0a8dd53462d452c322cb8c
>
> In my case, _canBridgeFirewall is false and so an exception is thrown.
>
> Please let me know what you think.
>
> Thanks!
>
> Mike
>
>
> On Mon, Mar 3, 2014 at 12:35 PM, Mike Tutkowski < 
> mike.tutkow...@solidfire.com> wrote:
>
> > It looks like this problem has existed since at least February 5th.
> > I'm currently in the process of building and running the codebase 
> > based on old commits to see where this was introduced.
> >
> >
> > On Mon, Mar 3, 2014 at 11:33 AM, Mike Tutkowski < 
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> Thanks, Sheng!
> >>
> >>
> >> On Mon, Mar 3, 2014 at 11:28 AM, Sheng Yang  wrote:
> >>
> >>> Sorry for just notice your issue. But it's unrelated to my chance.
> >>>
> >>> The scripts I deleted are scripts used to access the VR, not the 
> >>> host... So I don't think it's the cause of your issue. These files 
> >>> has been replaced by executing in the VR directly. I would remove 
> >>> the wrong warnings.
> >>>
> >>> can_bridge_firewall() called vmops plugin rather than the files 
> >>> you listed.
> >>>
> >>> Maybe take a look at /var/log/SMlog would give more details?
> >>>
> >>> --Sheng
> >>>
> >>> On Mon, Mar 3, 2014 at 10:18 AM, Mike Tutkowski 
> >>>  wrote:
> >>> > Hi Sheng,
> >>> >
> >>> > It looks like you removed these scripts on January 16th, 17th, 
> >>> > and
> >>> 20th.
> >>> >
> >>> > Any chance this could be the cause of the bug we're seeing where
> >>> XenServer
> >>> > hosts cannot be added to a cluster?
> >>> >
> >>> > Thanks!
> >>> >
> >>> >
> >>> > On Mon, Mar 3, 2014 at 10:47 AM, Mike Tutkowski < 
> >>> > mike.tutkow...@solidfire.com> wrote:
> >>> >
> >>> >> bumpUpPriority.sh and dhcp_entry.sh were deleted in
> >>> >>
> >>> >> 0cdf0f6f67c99a06fc1b94c2f2a38eff020f3f67
> >>> >>
> >>> >> call_loadbalancer.shh was deleted in
> >>> >>
> >>> >> e88cc488e5a9011f2c199f906bb0dacdb95685d7
> >>> >>
> >>> >> save_password_to_domr.sh was deleted in
> >>> >>
> >>> >> ca81e7b465fb40866fd14d1d1d27a2c42e1a2741
> >>> >>
> >>> >>
> >>> >> On Mon, Mar 3, 2014 at 10:42 AM, Mike Tutkowski < 
> >>> >> mike.tutkow...@solidfire.com> wrote:
> >>> >>
> >>> >>> It looks like, for example, call_firewall.sh was deleted in
> >>> >>>
> >>> >>> 0ea1c7dfc411db0d3710ac2c4fb238111cbec328
> >>> >>>
> >>> >>>
> >>> >>> On Mon, Mar 3, 2014 at 10:27 AM, Mike Tutkowski < 
> >>> >>> mike.tutkow...@solidfire.com> wrote:
> >>> >>>
> >>>  OK, I've had a bit of time to investigate this.
> >>> 
> >>>  I noticed in CitrixResourceBase that can_bridge_firewall 
> >>>  (which
> >>> calls a
> >>>  plug-in on the XenServer host) returns false:
> >>> 
> >>>   if (_securityGroupEnabled) {
> >>> 
> >>>  _canBridgeFirewall = 
> >>>  can_bridge_firewall(conn);
> >>> 
> >>>  if (!_canBridgeFirewall) {
> >>> 
> >>>  String msg = "Failed to configure brige
> >>> firewall";
> >>> 
> >>>  s_logger.warn(msg);
> >>> 
> >>>  s_logger.warn("Check host " + _host.ip +"
> >>>  for
> >>> CSP
> >>>  is installed or not and check network mode for bridge");
> >>> 
> >>>  return new SetupAnswer(cmd, msg);
> >>> 
> >>>    

RE: Exception adding XenServer host to CS

[Paul Angus]

I haven't managed to read every post in this thread, but I think I get the gist 
of what's being asked.

Since XenServer 6.1 openvswitch has become the default stack rather than bridge 
mode.
To enable bridge mode for security groups you need to do the

xe-switch-network-backend bridge

command and also set

net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1

in /etc/sysctl.conf

sed -i -e '/net.bridge.bridge-nf-call-iptables/ 
c\net.bridge.bridge-nf-call-iptables = 1' -e 
'/net.bridge.bridge-nf-call-arptables/ c\net.bridge.bridge-nf-call-arptables = 
1' /etc/sysctl.conf

should do that for you

then reboot



Regards

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

-Original Message-
From: Anthony Xu [mailto:xuefei...@citrix.com]
Sent: 04 March 2014 20:54
To: dev@cloudstack.apache.org
Cc: jaya...@apache.org
Subject: RE: Exception adding XenServer host to CS

>Do people have to run xe-switch-network-backend bridge before upgrading
>to
>4.4 (if they are using a Basic Zone)?
Correct.

>In my case, since I'm developing and able to start with a fresh DB and 
>XenServer hosts, it looks like I can just run xe-switch-network-backend bridge 
>before I create my zone, right?
Correct,

BTW,  reboot XS host is required to make the change take effect.

Anthony


-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: Monday, March 03, 2014 2:52 PM
To: dev@cloudstack.apache.org
Cc: jaya...@apache.org
Subject: Re: Exception adding XenServer host to CS

Hi Anthony,

Thanks for the reply.

It looks like this is a change in 4.4.

Do people have to run xe-switch-network-backend bridge before upgrading to
4.4 (if they are using a Basic Zone)?

In my case, since I'm developing and able to start with a fresh DB and 
XenServer hosts, it looks like I can just run xe-switch-network-backend bridge 
before I create my zone, right?

Thanks!
Mike


On Mon, Mar 3, 2014 at 3:45 PM, Anthony Xu  wrote:

> Hi Mike,
>
> If you are using Security group enabled zone or basic zone, you need
> to switch XS network mode from OVS to bridge since security group
> doesn't work on OVS.
>
> xe-switch-network-backend bridge.
>
>
> Anthony
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Monday, March 03, 2014 12:39 PM
> To: dev@cloudstack.apache.org; jaya...@apache.org
> Subject: Re: Exception adding XenServer host to CS
>
> Hi Jayapal,
>
> I was wondering if this commit could be the reason why people can no
> longer add XenServer hosts to clusters?
>
> 4b3784a98e57bc22bc0a8dd53462d452c322cb8c
>
> In my case, _canBridgeFirewall is false and so an exception is thrown.
>
> Please let me know what you think.
>
> Thanks!
>
> Mike
>
>
> On Mon, Mar 3, 2014 at 12:35 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > It looks like this problem has existed since at least February 5th.
> > I'm currently in the process of building and running the codebase
> > based on old commits to see where this was introduced.
> >
> >
> > On Mon, Mar 3, 2014 at 11:33 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> Thanks, Sheng!
> >>
> >>
> >> On Mon, Mar 3, 2014 at 11:28 AM, Sheng Yang  wrote:
> >>
> >>> Sorry for just notice your issue. But it's unrelated to my chance.
> >>>
> >>> The scripts I deleted are scripts used to access the VR, not the
> >>> host... So I don't think it's the cause of your issue. These files
> >>> has been replaced by executing in the VR directly. I would remove
> >>> the wrong warnings.
> >>>
> >>> can_bridge_firewall() called vmops plugin rather than the files
> >>> you listed.
> >>>
> >>> Maybe take a look at /var/log/SMlog would give more details?
> >>>
> >>> --Sheng
> >>>
> >>> On Mon, Mar 3, 2014 at 10:18 AM, Mike Tutkowski
> >>>  wrote:
> >>> > Hi Sheng,
> >>> >
> >>> > It looks like you removed these scripts on January 16th, 17th,
> >>> > and
> >>> 20th.
> >>> >
> >>> > Any chance this could be the cause of the bug we're seeing where
> >>> XenServer
> >>> > hosts cannot be added to a cluster?
> >>> >
> >>> > Thanks!
> >>> >
> >>> >
> >>> > On Mon, Mar 3, 2014 at 10:47 AM, Mike Tutkowski <
> >>> > mike.tutkow...@solidfire.com> wrote:
> >>> >
> >>> >> bumpUpPriority.sh and dhcp_entry.sh were deleted in
> >>> >>
> >>> >> 0cdf0f6f67c99a06fc1b94c2f2a38eff020f3f67
> >>> >>
> >>> >> call_loadbalancer.shh was deleted in
> >>> >>
> >>> >> e88cc488e5a9011f2c199f906bb0dacdb95685d7
> >>> >>
> >>> >> save_password_to_domr.sh was deleted in
> >>> >>
> >>> >> ca81e7b465fb40866fd14d1d1d27a2c42e1a2741
> >>> >>
> >>> >>
> >>> >> On Mon, Mar 3, 2014 at 10:42 AM, Mike Tutkowski <
> >>> >> mike.tutkow...@solidfire.com> wrote:
> >>> >>
> >>> >>> It looks like, for example, call_firewall.sh was deleted in
> >>> >>>
> >>> >>> 0ea1c7dfc411db0d3710ac2c4fb238111cbec328
> >>> >>>
> >>> >>>
> >>> >>> On Mon, Mar 3, 2014 at 10:27 AM, Mike Tutkowski <

Re: Review Request 18673: Return failure for StartCommand and PrepareForMigrationCommand if storage adaptor fails to connect disks

[Brian Angus]

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

Ship it!


Ship It!

- Brian Angus


On March 3, 2014, 12:09 a.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18673/
> ---
> 
> (Updated March 3, 2014, 12:09 a.m.)
> 
> 
> Review request for cloudstack, Brian Angus and Mike Tutkowski.
> 
> 
> Bugs: cloudstack-6192
> https://issues.apache.org/jira/browse/cloudstack-6192
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> I've noticed that during migrations or vm deployments, if connectPhysicalDisk 
> fails, the system continues with trying to do the start and/or migration. 
> This would cancel vm start if the storage adaptor tells us that the pre-work 
> of connecting the disks has failed.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  e6c750b 
> 
> Diff: https://reviews.apache.org/r/18673/diff/
> 
> 
> Testing
> ---
> 
> Still running
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>

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

[Suresh Balineni]

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

(Updated March 4, 2014, 10:10 p.m.)


Review request for cloudstack.


Changes
---

Hi Alena,

Could you review the change in VpcManagerImpl.java?


Repository: cloudstack-git


Description
---

Internal LB support for Juniper contrail VPC implementation.

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


Diffs
-

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

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


Testing
---

Tested LB VM deployment. Traffic tests are done.


Thanks,

Suresh Balineni

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

[Suresh Balineni]

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

(Updated March 4, 2014, 10:11 p.m.)


Review request for cloudstack.


Changes
---

Hi Alena,

Could you review the change in VpcManagerImpl.java?


Repository: cloudstack-git


Description
---

Internal LB support for Juniper contrail VPC implementation.

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


Diffs
-

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

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


Testing
---

Tested LB VM deployment. Traffic tests are done.


Thanks,

Suresh Balineni

[4.4] Root volume resize for XenServer

[Nux!]

Hello,

Would someone be interested in this for Xenserver? Would be a valuable 
feature for all hypervisors.


https://issues.apache.org/jira/browse/CLOUDSTACK-6181?focusedCommentId=13918796&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13918796 
(point 6)


Lucian


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [4.4] Root volume resize for XenServer

[Mike Tutkowski]

Is this feature currently KVM only?


On Tue, Mar 4, 2014 at 3:11 PM, Nux!  wrote:

> Hello,
>
> Would someone be interested in this for Xenserver? Would be a valuable
> feature for all hypervisors.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-6181?
> focusedCommentId=13918796&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-13918796 (point 6)
>
> Lucian
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>



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

Re: [4.4] Root volume resize for XenServer

[Marcus]

resizeVolume has been extended to work with root disks. If
resizeVolume works on XenServer (which I believe it does), then it
should just work.

Also, if someone looks at the CopyCommand for CitrixResourceBase (or
whatever handles the storage commands for Xen now) that is used to
create new disks from templates, you can just leverage the
VolumeObjectTO's size when you create a root disk, rather than the
template size, and you should have support for the
deployVirtualMachine rootdisksize parameter.

On Tue, Mar 4, 2014 at 3:11 PM, Nux!  wrote:
> Hello,
>
> Would someone be interested in this for Xenserver? Would be a valuable
> feature for all hypervisors.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-6181?focusedCommentId=13918796&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13918796
> (point 6)
>
> Lucian
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro

Re: [4.4] Root volume resize for XenServer

[Marcus]

It is, but not yet merged. We're investigating whether anyone who
codes on the other hypervisors are interested in supporting it for the
release. If not, it will be KVM-only for now.

On Tue, Mar 4, 2014 at 3:15 PM, Mike Tutkowski
 wrote:
> Is this feature currently KVM only?
>
>
> On Tue, Mar 4, 2014 at 3:11 PM, Nux!  wrote:
>
>> Hello,
>>
>> Would someone be interested in this for Xenserver? Would be a valuable
>> feature for all hypervisors.
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6181?
>> focusedCommentId=13918796&page=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-13918796 (point 6)
>>
>> Lucian
>>
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*

Re: [4.4] Root volume resize for XenServer

[Mike Tutkowski]

If no one picks it up for Xen, I should be able to look into it. Problem is
it might have to be after Feature Freeze if that's just in two weeks.


On Tue, Mar 4, 2014 at 3:16 PM, Marcus  wrote:

> It is, but not yet merged. We're investigating whether anyone who
> codes on the other hypervisors are interested in supporting it for the
> release. If not, it will be KVM-only for now.
>
> On Tue, Mar 4, 2014 at 3:15 PM, Mike Tutkowski
>  wrote:
> > Is this feature currently KVM only?
> >
> >
> > On Tue, Mar 4, 2014 at 3:11 PM, Nux!  wrote:
> >
> >> Hello,
> >>
> >> Would someone be interested in this for Xenserver? Would be a valuable
> >> feature for all hypervisors.
> >>
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-6181?
> >> focusedCommentId=13918796&page=com.atlassian.jira.
> >> plugin.system.issuetabpanels:comment-tabpanel#comment-13918796 (point 6)
> >>
> >> Lucian
> >>
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
> >>
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*
>



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

Re: [PROPOSAL][QUESTION] Map parameters in API Commands

[Marcus]

Ok, sounds like there needs to be some work done to make these more
consistent, perhaps. Can you comment on why rootdisksize was made from
a parameter into a part of the details map?

On Tue, Mar 4, 2014 at 3:12 AM, Bharat Kumar  wrote:
> Hi ALL,
> There are many other APIs that use Map like createNetworkOffering,
> updateZone, createTemplate, in most of the cases we do not
> say how to use maps, one way would be to write this in the description or to
> use the same way to access maps of all APIs.
>
> BTW the way to use details in deploy vm API is
> details[0].foo=bar&details[1].baz=12 where foo and baz are keys.
>
> Also  if we want to use the regix protected static final String
> MAP_KEY_PATTERN_EXPRESSION = "^([^\\[^\\]]+)\\[(\\d+)\\]\\.key$";
>protected static final
> String MAP_VALUE_PATTERN_EXPRESSION = "^[^\\[^\\]]+\\[\\d+\\]\\.value$";
>
> wil this work in the following case. I believe service is the key here which
> repeats.
> http://10.147.59.119:8080/client/api?command=createNetworkOffering&response=json&sessionkey=/kGFJDXFmMQU8JZnnC7QFfj3tV8=&name=bharat&displayText=bharat&guestIpType=Isolated&lbType=publicLb&;
> servicecapabilitylist[0].service=SourceNat&servicecapabilitylist[0].capabilitytype=SupportedSourceNatTypes&
> servicecapabilitylist[0].capabilityvalue=peraccount&
> servicecapabilitylist[1].service=lb&servicecapabilitylist[1].capabilitytype=SupportedLbIsolation&
> servicecapabilitylist[1].capabilityvalue=dedicated&availability=Optional&egresspolicy=ALLOW&state=Creating&status=Creating&allocationstate=Creating&supportedServices=Vpn,Dhcp,Dns,Firewall,Lb,UserData,SourceNat,StaticNat,PortForwarding&specifyIpRanges=false&specifyVlan=false&isPersistent=false&conservemode=false&serviceProviderList[0].service=Vpn&serviceProviderList[0].provider=VirtualRouter&serviceProviderList[1].service=Dhcp&serviceProviderList[1].provider=VirtualRouter&serviceProviderList[2].service=Dns&serviceProviderList[2].provider=VirtualRouter&serviceProviderList[3].service=Firewall&serviceProviderList[3].provider=VirtualRouter&serviceProviderList[4].service=Lb&serviceProviderList[4].provider=VirtualRouter&serviceProviderList[5].service=UserData&serviceProviderList[5].provider=VirtualRouter&serviceProviderList[6].service=SourceNat&serviceProviderList[6].provider=JuniperSRX&serviceProviderList[7].service=StaticNat&serviceProviderList[7].provider=JuniperSRX&serviceProviderList[8].service=PortForwarding&serviceProviderList[8].provider=JuniperSRX&egressdefaultpolicy=true&traffictype=GUEST&_=1393925230248
>
>
>
> On 04-Mar-2014, at 2:30 am, Marcus  wrote:
>
> Along these lines, the details parameter in deployVirtualMachine seems
> broken. If I call "details[0].key=foo,details[0].value=bar", it stores
> entries in the database like this:
>
> id | vmid | name | value | display
>
> 12 | 25   |  value | bar   | 1
> 13 | 25   |  key   | foo   | 1
>
> It seems as though this might be correct per Alena's email, but I
> don't understand how this can be reconstructed into foo=bar when
> there's no binding between the two rows. Perhaps details are supposed
> to be passed differently than the resource tags, because if I do
> "details[0].foo=bar&details[1].baz=12", I get:
>
> id | vmid | name | value | display
>
> 12 | 25   |  foo| bar| 1
> 13 | 25   |  baz   | 12 | 1
>
> And indeed there is code utilizing these details already committed
> that expects this format, as deployVirtualMachines getDetails() only
> seems to pass a correct Map with Key, Value if I use
> this format.
>
> On Mon, Mar 3, 2014 at 11:48 AM, Antonio Fornié Casarrubios
>  wrote:
>
> Hi Alena,
>
> Of course, the API will not have any changes. This is not a functional
> change, just some refactoring. The problem is there are many things in CS
> that really need some refactoring otherwise the problem will continue
> growing more and more, but doing the change and above all making sure it
> all works afterwards is not simple.
>
> I will make sure that everything works exactly the same way and that the
> data returned is also the same.
>
> Thanks. Cheers
> Antonio
>
>
> 2014-03-03 18:48 GMT+01:00 Alena Prokharchyk :
>
> Antonio, sure I will review the patch. But please make sure that API
> backwards compatibly is intact, otherwise the fix won¹t be accepted.
>
> -Alena.
>
>
> On 3/2/14, 4:31 PM, "Antonio Fornié Casarrubios"
>  wrote:
>
> Hi Alena,
>
> The reasons for this strange format? I don't know. There doesn't seem to
> be
> one. After asking on my team and in the dev list I thought perhaps you
> could know. It seems we all see it strange and nobody knows why. But of
> course, if it is for reasons I will stop the change.
>
>
>
> And about the DB, you are right, in the DB is not like I said. But you can
> have this in a table row field:
> {0={value=Toronto,key=City}}
> for some tables. I think there are two cases:
>
> 1- params in wich the get method

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[ASF Subversion and Git Services]

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


Commit 444e8f6bb3447a7eeb97f7c5d9b46abba3150072 in cloudstack's branch 
refs/heads/4.3-forward from Alena Prokharchyk
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=444e8f6 ]

CLOUDSTACK-5872: use List DS for storing NicProfiles as public network can have 
more than one nic


- ASF Subversion and Git Services


On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17591/
> ---
> 
> (Updated Jan. 31, 2014, 2:51 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-5872
> https://issues.apache.org/jira/browse/CLOUDSTACK-5872
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain 
> useful information
> 
> Updated the following classes to return a project object after async jobs 
> complete:
>  api/src/com/cloud/projects/ProjectService.java |  6 ++--
>  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
>  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
>  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
>  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
>  .../src/com/cloud/projects/ProjectManagerImpl.java | 34 
> +++---
>  .../com/cloud/projects/MockProjectManagerImpl.java | 16 +-
> 
> Previously these API commands only returned "success => true" in the aysnc 
> job result.  Now it returns the project that a user was added/deleted to.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/projects/ProjectService.java dc882ef 
>   
> api/src/org/apache/cloudstack/api/command/user/account/AddAccountToProjectCmd.java
>  36df579 
>   
> api/src/org/apache/cloudstack/api/command/user/account/DeleteAccountFromProjectCmd.java
>  f6aa36c 
>   
> api/src/org/apache/cloudstack/api/command/user/project/UpdateProjectInvitationCmd.java
>  dda7b54 
>   server/src/com/cloud/projects/ProjectManager.java f568146 
>   server/src/com/cloud/projects/ProjectManagerImpl.java 5a0ed1c 
>   server/test/com/cloud/projects/MockProjectManagerImpl.java dc377ff 
> 
> Diff: https://reviews.apache.org/r/17591/diff/
> 
> 
> Testing
> ---
> 
> Testing done on master.
> 
> 
> Thanks,
> 
> David Grizzanti
> 
>

Review Request 18759: HTTP support for console proxy and making it default

[Amogh Vasekar]

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

Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.


Repository: cloudstack-git


Description
---

Changes to support HTTP mode in Console Proxy, per 
http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
realhostip may go away


Diffs
-

  core/src/com/cloud/info/ConsoleProxyInfo.java 3439f3d 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
 a649bb7 
  
plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
 52cad3b 
  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 3572127 
  server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
a3f837b 
  systemvm/conf/consoleproxy.properties bb452f5 

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


Testing
---

Tested on local environment by 
1. Using HTTP based console proxy
2. HTTPS with realhostip domain
3. HTTPS with custom domain and self-signed cert
4. Secondary storage template download with custom domain and self-signed cert


Thanks,

Amogh Vasekar

Re: Review Request 18759: HTTP support for console proxy and making it default

[Amogh Vasekar]

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

(Updated March 5, 2014, 1:42 a.m.)


Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.


Repository: cloudstack-git


Description (updated)
---

Changes to support HTTP mode in Console Proxy, per 
http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
realhostip may go away

More details here : 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes


Diffs
-

  core/src/com/cloud/info/ConsoleProxyInfo.java 3439f3d 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
 a649bb7 
  
plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
 52cad3b 
  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 3572127 
  server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
a3f837b 
  systemvm/conf/consoleproxy.properties bb452f5 

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


Testing
---

Tested on local environment by 
1. Using HTTP based console proxy
2. HTTPS with realhostip domain
3. HTTPS with custom domain and self-signed cert
4. Secondary storage template download with custom domain and self-signed cert


Thanks,

Amogh Vasekar

Re: [DISCUSS] realhostip.com going away

[Amogh Vasekar]

Hello,

I have created a review request at : https://reviews.apache.org/r/18759/
that partially address the issue. It has a link to the wiki describing the
changes in detail.

Thanks,
Amogh

On 3/3/14 8:58 AM, "John Kinsella"  wrote:

>I talked with some of the Citrix folk over the weekendŠtheir position is
>they think they¹d be doing the community a disfavor by passing the torch,
>so-to-speak, and I agree with them [1].
>
>From what I understand, the patches that are going to be proposed will
>remove HTTPS completely and encrypt over http. That said, I haven¹t seen
>anything yet, so until we see something we¹re guessing. I¹m waiting a few
>more days to see what¹s proposed.
>
>John
>1: I¹m sharing conversations with individuals, so take this as hearsay
>not official comment from Citrix.
>
>On Mar 2, 2014, at 8:15 AM, Paul Angus
>mailto:paul.an...@shapeblue.com>> wrote:
>
>There are a few issues with the current console proxy setup, not least of
>which is the need to have internet access to resolve
>realhostip.com in the first place - so console
>proxy can't work if you don't have internet access on your client.  I
>have configured alternative realhostip.com setups
>for clients - and quite a lot of work goes into creating the
>infrastructure (and certs) to support changing to a user managed
>certificate.
>
>Sooo, is it at all possible to secure communications with the console
>proxy, without having to rely on ANY outside entity?
>
>Testing alone is going to be a pain, if a full ssl cert setup is required
>to use console proxy..
>
>Regards
>
>Paul Angus
>Cloud Architect
>S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
>paul.an...@shapeblue.com
>
>-Original Message-
>From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
>Sent: 28 February 2014 23:05
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] realhostip.com going away
>
>
>
>On 2/28/14 2:03 PM, "Nux!"  wrote:
>
>There's also the problem of the certificate. It comes bundled in ACS as
>far as I can tell.. When does it expire?
>
>notBefore=Feb  3 03:30:40 2012 GMT
>notAfter=Feb  7 05:11:23 2017 GMT
>
>Need Enterprise Grade Support for Apache CloudStack?
>Our CloudStack Infrastructure
>Support offers
>the best 24/7 SLA for CloudStack Environments.
>
>Apache CloudStack Bootcamp training courses
>
>**NEW!** CloudStack 4.2.1
>training
>18th-19th February 2014, Brazil.
>Classroom
>17th-23rd March 2014, Region A. Instructor led,
>On-line
>24th-28th March 2014, Region B. Instructor led,
>On-line
>16th-20th June 2014, Region A. Instructor led,
>On-line
>23rd-27th June 2014, Region B. Instructor led,
>On-line
>
>This email and any attachments to it may be confidential and are intended
>solely for the use of the individual to whom it is addressed. Any views
>or opinions expressed are solely those of the author and do not
>necessarily represent those of Shape Blue Ltd or related companies. If
>you are not the intended recipient of this email, you must neither take
>any action based upon its contents, nor copy or show it to anyone. Please
>contact the sender if you believe you have received this email in error.
>Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>Services India LLP is a company incorporated in India and is operated
>under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>a company incorporated in Brasil and is operated under license from Shape
>Blue Ltd. ShapeBlue is a registered trademark.
>
>Stratosec - Compliance as a Service
>o: 415.315.9385
>@johnlkinsella
>

RE: OVS plugin in CloudStack 4.3.0

[Animesh Chaturvedi]

Tuna I look at your commits in 4.3-forwards and seems the changes are a lot, 
this would have to come in the next release

Thanks
Animesh

> -Original Message-
> From: ng.t...@gmail.com [mailto:ng.t...@gmail.com] On Behalf Of Nguyen
> Anh Tu
> Sent: Monday, February 24, 2014 8:31 AM
> To: dev@cloudstack.apache.org
> Subject: Re: OVS plugin in CloudStack 4.3.0
> 
> On Mon, Feb 24, 2014 at 7:01 PM, Murali Reddy
> wrote:
> 
> > Opened UI bug for 4.3 CLOUDSTACK-6162 if some one can help fixing the
> > UI part.
> >
> 
> Murali,
> 
> We'll get it in the end of February, I promise!
> 
> --Tuna

Build failed in Jenkins: build-master #402

[jenkins]

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on cloudstack-buildslave-centos6-28c in workspace 

Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/cloudstack.git
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
ERROR: Timeout after 400 minutes
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --progress 
https://git-wip-us.apache.org/repos/asf/cloudstack.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: error: RPC failed; result=22, HTTP code = 502
error: fetch-pack died of signal 15

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1086)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:968)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:71)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:197)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:329)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:701)
ERROR: null

Jenkins build is back to normal : build-master #403

[jenkins]

See 

Re: CLOUDSTACK-5583: vmopsSnapshot plug-in (XenServer) does not return an error when it should

[Mandar Barve]

I tested this with CS 4.3.

Thanks,
Mandar


On Tue, Mar 4, 2014 at 9:09 PM, Mike Tutkowski  wrote:

> Hi,
>
> Can you tell me what release you tested this with? I noticed the problem
> while developing on CloudStack 4.3.
>
> Thanks!
>
>
> On Tue, Mar 4, 2014 at 3:43 AM, Mandar Barve wrote:
>
>> Hi,
>> I tried to reproduce the issue but couldn't get this to fail for
>> insufficient space. I then injected an exception trying to list files from
>> a non existent path (added this code in the "try" block). This landed me
>> into the exception handling code. It raised correct exception saying "file
>> not found" which was captured in the management server vmops log file. It
>> was not displayed by the GUI. GUI just reported Error (Are we looking for
>> GUI displaying error code?). The plugin code returns "0" immediately after
>> the line of code that raises exception but I think this applies only for
>> successful execution of the plugin code that reverts the snapshot.
>>
>>If any exception is raised (e.g. in the reported case here
>> insufficient space) then the code should return appropriate error message
>> to the caller as I found. In exception handling path return "0" wouldn't
>> execute.
>>
>> I don't see any problem here. Let me know if I am missing anything.
>>
>> Thanks,
>> Mandar
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *(tm)*
>

RE: Review Request 18683: CLOUDSTACK-6194: Failed to increase Shared network IP Range

[Saksham Srivastava]

Marcus, as a committer can you kindly commit it too.

-Original Message-
From: Marcus Sorensen [mailto:nore...@reviews.apache.org] On Behalf Of Marcus 
Sorensen
Sent: Monday, March 3, 2014 10:09 PM
To: Marcus Sorensen; Sateesh Chodapuneedi
Cc: Saksham Srivastava; cloudstack
Subject: Re: Review Request 18683: CLOUDSTACK-6194: Failed to increase Shared 
network IP Range


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

Ship it!


Ship It!

- Marcus Sorensen


On March 3, 2014, 12:53 p.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18683/
> ---
> 
> (Updated March 3, 2014, 12:53 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Sateesh Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-6194
> https://issues.apache.org/jira/browse/CLOUDSTACK-6194
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> In case the vlan is passed null to the api or doing it from UI, the new 
> changes make vlanId as "vlan://untagged"
> 
> The following code in ConfigurationManagerImpl.java  if (vlans != null 
> && vlans.size() > 0) {
>  VlanVO vlan = vlans.get(0);
>  if (vlanId == null) {
>  vlanId = vlan.getVlanTag();
>  } else if 
> (!NetUtils.isSameIsolationId(vlan.getVlanTag(), vlanId)) {
>  throw new 
> InvalidParameterValueException("there is already one vlan " + 
> vlan.getVlanTag()
> 
> starts throwing exception.
> 
> Fix includes additional check for the modified vlanid.
> The same checks are in NetUtils.isSameIsolationId() for checking untagged.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 
> d2e5aaa
> 
> Diff: https://reviews.apache.org/r/18683/diff/
> 
> 
> Testing
> ---
> 
> Adding new guest IP range passes smoothly.
> Adding new public IP ranges passes smoothly.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request 18683: CLOUDSTACK-6194: Failed to increase Shared network IP Range

[Marcus]

sure, I lose track of who is committer, as many times committers post
to reviewboard as well if the code is unfamiliar.

On Tue, Mar 4, 2014 at 9:46 PM, Saksham Srivastava
 wrote:
> Marcus, as a committer can you kindly commit it too.
>
> -Original Message-
> From: Marcus Sorensen [mailto:nore...@reviews.apache.org] On Behalf Of Marcus 
> Sorensen
> Sent: Monday, March 3, 2014 10:09 PM
> To: Marcus Sorensen; Sateesh Chodapuneedi
> Cc: Saksham Srivastava; cloudstack
> Subject: Re: Review Request 18683: CLOUDSTACK-6194: Failed to increase Shared 
> network IP Range
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18683/#review35970
> ---
>
> Ship it!
>
>
> Ship It!
>
> - Marcus Sorensen
>
>
> On March 3, 2014, 12:53 p.m., Saksham Srivastava wrote:
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/18683/
>> ---
>>
>> (Updated March 3, 2014, 12:53 p.m.)
>>
>>
>> Review request for cloudstack, Marcus Sorensen and Sateesh Chodapuneedi.
>>
>>
>> Bugs: CLOUDSTACK-6194
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6194
>>
>>
>> Repository: cloudstack-git
>>
>>
>> Description
>> ---
>>
>> In case the vlan is passed null to the api or doing it from UI, the new 
>> changes make vlanId as "vlan://untagged"
>>
>> The following code in ConfigurationManagerImpl.java  if (vlans != null
>> && vlans.size() > 0) {
>>  VlanVO vlan = vlans.get(0);
>>  if (vlanId == null) {
>>  vlanId = vlan.getVlanTag();
>>  } else if 
>> (!NetUtils.isSameIsolationId(vlan.getVlanTag(), vlanId)) {
>>  throw new
>> InvalidParameterValueException("there is already one vlan " +
>> vlan.getVlanTag()
>>
>> starts throwing exception.
>>
>> Fix includes additional check for the modified vlanid.
>> The same checks are in NetUtils.isSameIsolationId() for checking untagged.
>>
>>
>> Diffs
>> -
>>
>>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java
>> d2e5aaa
>>
>> Diff: https://reviews.apache.org/r/18683/diff/
>>
>>
>> Testing
>> ---
>>
>> Adding new guest IP range passes smoothly.
>> Adding new public IP ranges passes smoothly.
>>
>>
>> Thanks,
>>
>> Saksham Srivastava
>>
>>
>

Re: Review Request 18683: CLOUDSTACK-6194: Failed to increase Shared network IP Range

[ASF Subversion and Git Services]

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


Commit b8413b9413eb39053c378309195469a4d5d4fec0 in cloudstack's branch 
refs/heads/master from Marcus Sorensen
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b8413b9 ]

CLOUDSTACK-6194: Failed to increase Shared network IP Range

Submitted-by:Saksham Srivastava 


- ASF Subversion and Git Services


On March 3, 2014, 12:53 p.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18683/
> ---
> 
> (Updated March 3, 2014, 12:53 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Sateesh Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-6194
> https://issues.apache.org/jira/browse/CLOUDSTACK-6194
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> In case the vlan is passed null to the api or doing it from UI, the new 
> changes make vlanId as "vlan://untagged"
> 
> The following code in ConfigurationManagerImpl.java
>  if (vlans != null && vlans.size() > 0) {
>  VlanVO vlan = vlans.get(0);
>  if (vlanId == null) {
>  vlanId = vlan.getVlanTag();
>  } else if 
> (!NetUtils.isSameIsolationId(vlan.getVlanTag(), vlanId)) {
>  throw new InvalidParameterValueException("there is 
> already one vlan " + vlan.getVlanTag()
> 
> starts throwing exception.
> 
> Fix includes additional check for the modified vlanid.
> The same checks are in NetUtils.isSameIsolationId() for checking untagged.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java d2e5aaa 
> 
> Diff: https://reviews.apache.org/r/18683/diff/
> 
> 
> Testing
> ---
> 
> Adding new guest IP range passes smoothly.
> Adding new public IP ranges passes smoothly.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request 18683: CLOUDSTACK-6194: Failed to increase Shared network IP Range

[ASF Subversion and Git Services]

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


Commit cd0d16f05a2be02e3de1a327bba9a5acd112e4f2 in cloudstack's branch 
refs/heads/4.3-forward from Marcus Sorensen
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cd0d16f ]

CLOUDSTACK-6194: Failed to increase Shared network IP Range

Submitted-by:Saksham Srivastava 


- ASF Subversion and Git Services


On March 3, 2014, 12:53 p.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18683/
> ---
> 
> (Updated March 3, 2014, 12:53 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Sateesh Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-6194
> https://issues.apache.org/jira/browse/CLOUDSTACK-6194
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> In case the vlan is passed null to the api or doing it from UI, the new 
> changes make vlanId as "vlan://untagged"
> 
> The following code in ConfigurationManagerImpl.java
>  if (vlans != null && vlans.size() > 0) {
>  VlanVO vlan = vlans.get(0);
>  if (vlanId == null) {
>  vlanId = vlan.getVlanTag();
>  } else if 
> (!NetUtils.isSameIsolationId(vlan.getVlanTag(), vlanId)) {
>  throw new InvalidParameterValueException("there is 
> already one vlan " + vlan.getVlanTag()
> 
> starts throwing exception.
> 
> Fix includes additional check for the modified vlanid.
> The same checks are in NetUtils.isSameIsolationId() for checking untagged.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java d2e5aaa 
> 
> Diff: https://reviews.apache.org/r/18683/diff/
> 
> 
> Testing
> ---
> 
> Adding new guest IP range passes smoothly.
> Adding new public IP ranges passes smoothly.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

RE: Review Request 18683: CLOUDSTACK-6194: Failed to increase Shared network IP Range

[Saksham Srivastava]

Thanks, I am still not there :)

-Original Message-
From: Marcus [mailto:shadow...@gmail.com] 
Sent: Wednesday, March 5, 2014 10:48 AM
To: Saksham Srivastava
Cc: dev@cloudstack.apache.org; Sateesh Chodapuneedi
Subject: Re: Review Request 18683: CLOUDSTACK-6194: Failed to increase Shared 
network IP Range

sure, I lose track of who is committer, as many times committers post to 
reviewboard as well if the code is unfamiliar.

On Tue, Mar 4, 2014 at 9:46 PM, Saksham Srivastava 
 wrote:
> Marcus, as a committer can you kindly commit it too.
>
> -Original Message-
> From: Marcus Sorensen [mailto:nore...@reviews.apache.org] On Behalf Of 
> Marcus Sorensen
> Sent: Monday, March 3, 2014 10:09 PM
> To: Marcus Sorensen; Sateesh Chodapuneedi
> Cc: Saksham Srivastava; cloudstack
> Subject: Re: Review Request 18683: CLOUDSTACK-6194: Failed to increase 
> Shared network IP Range
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18683/#review35970
> ---
>
> Ship it!
>
>
> Ship It!
>
> - Marcus Sorensen
>
>
> On March 3, 2014, 12:53 p.m., Saksham Srivastava wrote:
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/18683/
>> ---
>>
>> (Updated March 3, 2014, 12:53 p.m.)
>>
>>
>> Review request for cloudstack, Marcus Sorensen and Sateesh Chodapuneedi.
>>
>>
>> Bugs: CLOUDSTACK-6194
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6194
>>
>>
>> Repository: cloudstack-git
>>
>>
>> Description
>> ---
>>
>> In case the vlan is passed null to the api or doing it from UI, the new 
>> changes make vlanId as "vlan://untagged"
>>
>> The following code in ConfigurationManagerImpl.java  if (vlans != 
>> null && vlans.size() > 0) {
>>  VlanVO vlan = vlans.get(0);
>>  if (vlanId == null) {
>>  vlanId = vlan.getVlanTag();
>>  } else if 
>> (!NetUtils.isSameIsolationId(vlan.getVlanTag(), vlanId)) {
>>  throw new
>> InvalidParameterValueException("there is already one vlan " +
>> vlan.getVlanTag()
>>
>> starts throwing exception.
>>
>> Fix includes additional check for the modified vlanid.
>> The same checks are in NetUtils.isSameIsolationId() for checking untagged.
>>
>>
>> Diffs
>> -
>>
>>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java
>> d2e5aaa
>>
>> Diff: https://reviews.apache.org/r/18683/diff/
>>
>>
>> Testing
>> ---
>>
>> Adding new guest IP range passes smoothly.
>> Adding new public IP ranges passes smoothly.
>>
>>
>> Thanks,
>>
>> Saksham Srivastava
>>
>>
>

Re: [Proposal] Virtual Router service failure alerting

[Harikrishna Patnala]

Hi,
My comments inline.

On 03-Mar-2014, at 1:16 pm, Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>> wrote:

Hi,
What happens if there is an extended disconnect from MS? What is the
rollover strategy for the new log files?
In case of extended disconnect, we record the last received timestamp in our 
DB. When request goes from MS we include timestamp using which alerts after 
that timestamp are returned as response.
The rollover strategy is to maintain logs with maxsize of 10MB and backup count 
to 5.

What is the format of the alarm
sent to the MS?
TimeStamp: RouterName: ServiceName: Message:

How does the MS deduplicate alarms from the VR? How does
the admin see these?
Since we get the alerts based on the last received alert timestamp we do not 
get duplicates and upon receiving alerts from VR we publish the alerts.


Thanks
Harikrishna


On 2/17/14, 1:57 AM, "Harikrishna Patnala"
mailto:harikrishna.patn...@citrix.com>> wrote:

Hi Sheng,
Thank you for the corrections and suggestions. My comments inline.

On 14-Feb-2014, at 1:53 am, Sheng Yang
mailto:sh...@yasker.org>> wrote:

Hi Hari,

+1. Getting log from VR is a long awaited feature.

One correction: VR does have mgmt network nic, but it doesn't have direct
communcation with mgmt server(in the most case except VMware). So polling
is still needed.
[Hari] I did not see the management nic on virtual router in case of
Xenserver. Anyway we need polling :)


And another comment: you can reuse CheckRouterTask() for the purpose. It
already has been used for s2s vpn connection status update and redundant
router checking, and "router.check.interval" would be used as interval for
checking. You can improve and reuse that rather than introduce another
polling thread for VR.
[Hari] Initially I thought of same to piggyback in the existing requests
to VR, but I proposed this just not to change the semantic of
checkRouterTask by including alerts getting request to VR.
If this is fine I¹ll reuse the CheckRouterTask.


How can you define "new alart"? Did the file would be deleted/archived
after poll? Or you simply just looking after a certain point? I guess a
diff works better than search for timestamp. More details in
implementation
would be helpful.
[Hari] Yes Sheng, I agree that diff would be better, but there is a case
where after taking diff, reply from router to MS may fail because of
network failure or some other reasons. In this case we cannot get the
diff back and there is a need of timestamp over here. So would it be
better to use both diff and timestamp. If diff falls to retrieve alerts
we also check using timestamp.
I will update the FS with some implementation details (using both
timestamps and diff) CWIKI is down now.


--Sheng


On Thu, Feb 13, 2014 at 1:56 AM, Harikrishna Patnala <
harikrishna.patn...@citrix.com>
wrote:

Hi,

Currently in CS we can monitor the running services on Virtual Router and
ensure they are running through the lifetime of VR. Upon failure of any
service in VR, monitoring service logs the alerts in VR logs.
These alerts need to be pushed to management server to notify admin.

For this I'd like to introduce the feature Virtual Router service failure
alerting.

[1] https://issues.apache.org/jira/browse/CLOUDSTACK-6090
[2]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Virtual+Router+Serv
ice+Failure+Alerting


Comments/feedback are welcome

Thank you,
Harikrishna

Re: [PROPOSAL] Ability to add new guest OS

[Amogh Vasekar]

Hi,
Responses inline.

Thanks,
Amogh

On 3/4/14 12:00 AM, "Daan Hoogland"  wrote:

>+1 for the feature,
>
>Did you consider systemvms? Or the default vm-template? Or are those
>marked as undeletable or even hardcoded in case the table gets editted
>outside of ACS?
[Amogh] Sorry, I don't think I get the question here. The table would only
map the OS name of systemvm, which is standardized in CloudStack, to the
hypervisor specific OS name.
For the undeletable part, please refer to the next one.
>
>The delete feature is vital. You marked it as open for discussion but
>I don't agree. The admin should delete when he makes a mistake! Or
>when an os has a structural vulnerability!
[Amogh] Sure! I should have been clearer in the doc. I meant to say that
some mappings may be marked as non-editable / non-deletable. These may be
the ones that come bundled in with CloudStack, or a subset of those. This
second point was the one I had in mind with respect to being open for
discussion.
All admin specified mappings should be editable / deletable.
>
>How and when is memory mapping done? Someone is busy instantiating a
>template based on an os which in the meanwhile is being deleted. What
>happens?
[Amogh] This is a good point. The current implementation I have in mind
would use these mappings as the VM details are being created to be sent to
the agent. As such, it should honor the user view of details. Let me get
back with more details on this though.
>
>regards,
>
>On Mon, Mar 3, 2014 at 9:44 PM, Amogh Vasekar 
>wrote:
>> Hi,
>>
>> CloudStack currently does not allow an easy way to add new guest OS
>>types,
>> for example, a standard way to add say, CentOS 6.5 even though a
>> hypervisor may support it.
>> Part of the reason is since the OS to hypervisor-specific platform
>> mappings are currently hard-coded into the code-base [1][2]
>> To support such new OS addition, the current way is to manipulate the DB
>> using upgrade scripts and make the necessary code changes.
>> This proposal aims to partially mitigate this issue by allowing the
>> CloudStack admin the ability to add new OS in the list, and update the
>> mapping to hypervisor-specific platform names, via APIs / UI. For now,
>>the
>> admin will be responsible for providing the mapping to
>>hypervisor-specific
>> platform names based on his knowledge, which may be enhanced in future.
>> For example, based on [1], an admin should be able to add a mapping
>>like :
>> CentOS 6.5 (64 bit) -> CentsOS 6.5 .
>>
>> The functional spec can be found at :
>> 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal+-+Ability
>>+t
>> o+add+new+guest+OS+mappings
>>
>> Comments / suggestions welcome.
>>
>> Thanks,
>> Amogh
>>
>>
>> [1]
>> 
>>https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/
>>sr
>> c/com/cloud/hypervisor/kvm/resource/KVMGuestOsMapper.java
>> [2]
>> 
>>https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/xen/
>>sr
>> c/com/cloud/hypervisor/xen/resource/CitrixHelper.java
>>
>
>
>
>-- 
>Daan

Re: [PROPOSAL] Ability to add new guest OS

[Amogh Vasekar]

On 3/4/14 2:33 AM, "Abhinandan Prateek" 
wrote:

>Is the initial list of supported os coming from Hypervisor

Yes. More specifically, for now the list is coming from :
KVM : http://bit.ly/1kY6msQ
Xen : http://bit.ly/1mUei3f
VMW : http://bit.ly/MMsAlF

Review Request 18763: CLOUDSTACK-6201: createVMSnapshot doesn't check volume state

[Qian Shaohua]

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

Review request for cloudstack, daan Hoogland and Kelven Yang.


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


Repository: cloudstack-git


Description
---

Fix for CLOUDSTACK-6201
Check if volume state is Ready on allocating VM snapshot


Diffs
-

  server/src/com/cloud/vm/snapshot/VMSnapshotManagerImpl.java 9d7a952 

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


Testing
---


Thanks,

Qian Shaohua

Re: Review Request 18759: HTTP support for console proxy and making it default

[John Kinsella]

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


Amogh - thanks for the patch.  Some small issues on this patch. I've got larger 
comments but I'll post them on the "Realhostip.com shutting down on June 30" 
thread.


core/src/com/cloud/info/ConsoleProxyInfo.java


Can you clean up trailing whitespace added in lines like this?



server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java


This doesn't seem relevant to the issue at hand.



systemvm/conf/consoleproxy.properties


Why change the listening port? I don't see what this has to do with moving 
from HTTPS to HTTP...


- John Kinsella


On March 5, 2014, 1:42 a.m., Amogh Vasekar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18759/
> ---
> 
> (Updated March 5, 2014, 1:42 a.m.)
> 
> 
> Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes to support HTTP mode in Console Proxy, per 
> http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
> realhostip may go away
> 
> More details here : 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/info/ConsoleProxyInfo.java 3439f3d 
>   
> engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
>  a649bb7 
>   
> plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
>  52cad3b 
>   server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 3572127 
>   server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
> a3f837b 
>   systemvm/conf/consoleproxy.properties bb452f5 
> 
> Diff: https://reviews.apache.org/r/18759/diff/
> 
> 
> Testing
> ---
> 
> Tested on local environment by 
> 1. Using HTTP based console proxy
> 2. HTTPS with realhostip domain
> 3. HTTPS with custom domain and self-signed cert
> 4. Secondary storage template download with custom domain and self-signed cert
> 
> 
> Thanks,
> 
> Amogh Vasekar
> 
>

RE: [4.3] [Cherry-pick] CLOUDSTACK-6146

[Animesh Chaturvedi]

Done

> -Original Message-
> From: Likitha Shetty
> Sent: Wednesday, February 26, 2014 12:39 AM
> To: dev@cloudstack.apache.org
> Cc: Animesh Chaturvedi
> Subject: [4.3] [Cherry-pick] CLOUDSTACK-6146
> 
> Animesh,
> 
> Can you cherry pick 8cb03ddb2387c7aebf20dc0aa011e41f227e9f68 and
> c652ff45dffaafa1cb0de29103e90fe936382028 from 4.3-forward to 4.3?
> 
> Thanks,
> Likitha

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

[Animesh Chaturvedi]

Done

> -Original Message-
> From: Min Chen
> Sent: Wednesday, February 26, 2014 3:25 PM
> To: dev@cloudstack.apache.org
> Cc: Animesh Chaturvedi
> Subject: Re: [4.3] [Cherry-pick] CLOUDSTACK-6174, CLOUDSTACK-6175
> 
> Animesh,
> 
>   Can you cherry pick the following commits from 4.3-forward to 4.3?
> 
> 4c83f80c809674cb8ff9561d546a6ade25d983f8
> CLOUDSTACK-6174: Provide separate option for Windows Server 2012 R2 as
> an OS type when registering template.
> 
> 
> 
> 94257c0fc85c7178e6ca3146662de08feee2c290
> CLOUDSTACK-6175:s3.singleupload.max.size option not applicable for backup
> snapshot on KVM.
> 
> 
>   Thanks
>   -min
> 
> 

RE: [4.3] [Cherry-pick] CLOUDSTACK-6186

[Animesh Chaturvedi]

Done

> -Original Message-
> From: Nitin Mehta
> Sent: Friday, February 28, 2014 2:45 PM
> To: dev@cloudstack.apache.org
> Cc: Animesh Chaturvedi
> Subject: [4.3] [Cherry-pick] CLOUDSTACK-6186
> 
> Hi Animesh - Can you please cherry pick the following commit from 4.3-
> forward to 4.3?
> 
> commit 258d8e2a0494ec8772d9238511fe5f8c6bf0ea01
> Author: Nitin Mehta 
> Date:   Fri Feb 28 10:42:24 2014 -0800
> 
> CLOUDSTACK-6186: Unable to register private template across all Zones
> - crosszones flag no longer works.
> This was because the code skipped the loop after the first download
> initiation.
> Introduced a set so that if it is already downloaded to the same zone then
> skip it for private template.
> 
> 
> Thanks,
> 
> -Nitin

Re: [DISCUSS] realhostip.com going away

[John Kinsella]

While this patch might address the direct problem, a quick string search of the 
source shows “realhostip.com” in a few more places that 
also need to be cleaned up, including in the db. I haven’t actually applied the 
patch yet, just read over it a few times. Will try to apply/test tomorrow.

I’m going to sleep on this and mull it over a little more, will probably 
comment more tomorrow.

John

On Mar 4, 2014, at 5:43 PM, Amogh Vasekar 
mailto:amogh.vase...@citrix.com>> wrote:

Hello,

I have created a review request at : https://reviews.apache.org/r/18759/
that partially address the issue. It has a link to the wiki describing the
changes in detail.

Thanks,
Amogh

On 3/3/14 8:58 AM, "John Kinsella" 
mailto:j...@stratosec.co>> wrote:

I talked with some of the Citrix folk over the weekendŠtheir position is
they think they¹d be doing the community a disfavor by passing the torch,
so-to-speak, and I agree with them [1].

>From what I understand, the patches that are going to be proposed will
remove HTTPS completely and encrypt over http. That said, I haven¹t seen
anything yet, so until we see something we¹re guessing. I¹m waiting a few
more days to see what¹s proposed.

John
1: I¹m sharing conversations with individuals, so take this as hearsay
not official comment from Citrix.

On Mar 2, 2014, at 8:15 AM, Paul Angus
mailto:paul.an...@shapeblue.com>>
 wrote:

There are a few issues with the current console proxy setup, not least of
which is the need to have internet access to resolve
realhostip.com in the first place 
- so console
proxy can't work if you don't have internet access on your client.  I
have configured alternative 
realhostip.com setups
for clients - and quite a lot of work goes into creating the
infrastructure (and certs) to support changing to a user managed
certificate.

Sooo, is it at all possible to secure communications with the console
proxy, without having to rely on ANY outside entity?

Testing alone is going to be a pain, if a full ssl cert setup is required
to use console proxy..

Regards

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

-Original Message-
From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
Sent: 28 February 2014 23:05
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] realhostip.com going away



On 2/28/14 2:03 PM, "Nux!" mailto:n...@li.nux.ro>> wrote:

There's also the problem of the certificate. It comes bundled in ACS as
far as I can tell.. When does it expire?

notBefore=Feb  3 03:30:40 2012 GMT
notAfter=Feb  7 05:11:23 2017 GMT

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

Apache CloudStack Bootcamp training courses

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

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

Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella



Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella