Re: 4.4 Feature Freeze

[murali reddy]

On Fri, Feb 28, 2014 at 7:39 PM, Hugo Trippaers  wrote:

>
> This is the list of current features targeted for 4.4 according to our
> Jira. Which features would be impacted if we don't move the feature freeze?
>
> [image: New Feature] CLOUDSTACK-6161
> distributed routing and network ACL with OVS plug-in
> Murali Reddy Murali Reddy [image: Major] [image: Open] Open Unresolved
> 24/Feb/14 24/Feb/14
>

This feature proposed for 4.4 would be impacted if feature freeze is not
extended. I will be short of a weeks time to send out a merge request by
10th March.

Re: 4.4 Feature Freeze

[Abhinandan Prateek]

I think there is no consensus on feature freeze date yet ?

Daan,
 Shall we call for a vote on this ?

-abhi

On 03/03/14 6:11 am, "Mike Tutkowski"  wrote:

>I believe March 14th is Feature Freeze and, as such, when the 4.4 branch
>is
>cut.
>
>
>On Sun, Mar 2, 2014 at 11:12 AM, Sebastien Goasguen
>wrote:
>
>>
>> On Feb 28, 2014, at 9:09 AM, Hugo Trippaers  wrote:
>>
>> > i'm all for being flexible, but i find a lot of the arguments used
>>here
>> debatable.
>> >
>> > "It causes developers to rush their development to meet the deadline."
>> This will happen anyway, every time we've extended the deadline we got
>>new
>> features coming in at the last minute. Actually i'm under the impression
>> that when we move the deadline people will actually try to get more
>> features in instead of working on stabilizing existing features.
>> >
>> > "We can't deliver features on the roadmap." There is validity to this
>> point, but on the other hand we already know the entire release schedule
>> way ahead, this feature freeze date should not come as a surprise. But
>>as i
>> mentioned in an earlier mail, lets have this discussion. Post which
>> features might not make it into the release so we can have a discussion
>>if
>> we should slip the release date to get this feature in. I think we all
>>now
>> that there are commercial parties working with this software to build
>> releases and have customers demanding features, but if we don't discuss
>> that on list it's hard for us to take it into account.
>> >
>> > "Feature freeze wasn't called" True, i wasn't even aware that this
>>was a
>> requirement. We should add this to the procedure here
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so
>> release managers know this is expected of them. It should not impact the
>> dates as the dates are already fixed by the release schedule (every 4
>> months)
>> >
>> >
>> > I'm still -1 on extending the feature freeze. I would rather extend
>>the
>> test/stability phase to we have some more time to fix issues before we
>>get
>> into the RC spinning.
>> >
>> >
>> > This is the list of current features targeted for 4.4 according to our
>> Jira. Which features would be impacted if we don't move the feature
>>freeze?
>> >
>> > ASF JIRA
>> > Project: CloudStack
>> > Type: New Feature
>> > Fix Version: 4.4.0
>> > Resolution: Unresolved
>> > Sorted by: Updated descending
>> > 1-15 of 15 as at: 28/Feb/14 15:07
>> > T Key Summary AssigneeReporterP   Status
>>  Resolution  Created Updated Due
>> >   CLOUDSTACK-6181
>> > Root resize
>> > UnassignedNux   Open Unresolved
>>  27/Feb/14   27/Feb/14
>> >   CLOUDSTACK-6161
>> > distributed routing and network ACL with OVS plug-in
>> > Murali Reddy  Murali Reddy  Open
>>Unresolved
>>  24/Feb/14   24/Feb/14
>> >   CLOUDSTACK-6092
>> > Storage OverProvisioning as a Per Primary Basis
>> > Saksham SrivastavaSaksham Srivastava  
>>
>> Open Unresolved  13/Feb/14   20/Feb/14
>> >   CLOUDSTACK-6144
>> > HA for guest VMs running Hyper-V
>> > UnassignedRajesh BattalaOpen
>>Unresolved
>>  20/Feb/14   20/Feb/14
>> >   CLOUDSTACK-6143
>> > Storage Live-Migration support for Hyper-V
>> > UnassignedRajesh BattalaOpen
>>Unresolved
>>  20/Feb/14   20/Feb/14
>> >   CLOUDSTACK-6142
>> > Zone Wide Primary Store in Hyper-V
>> > UnassignedRajesh BattalaOpen
>>Unresolved
>>  20/Feb/14   20/Feb/14
>> >   CLOUDSTACK-6104
>> > PVLAN support for CloudStack deployment over Nexus 1000v in VMware
>> environment
>> > Sateesh Chodapuneedi  Sateesh Chodapuneedi
>>
>> Open Unresolved  14/Feb/14   15/Feb/14
>> >   CLOUDSTACK-6109
>> > Support of iSCSI as primary store in Hyper-V
>> > Rajesh BattalaRajesh BattalaOpen
>> Unresolved  14/Feb/14   14/Feb/14
>> >   CLOUDSTACK-6106
>> > Support of VPC in HyperV
>> > Rajesh BattalaRajesh BattalaOpen
>> Unresolved  14/Feb/14   14/Feb/14
>> >   CLOUDSTACK-6090
>> > Virtual Router Service Failure Alerting
>> > Harikrishna Patnala   Harikrishna Patnala 
>>
>> Open Unresolved  13/Feb/14   13/Feb/14
>> >   CLOUDSTACK-6052
>> > List VM enhancement to support querying with multiple VM IDs
>> > Koushik Das   Koushik Das   Open
>>Unresolved
>>  07/Feb/14   07/Feb/14
>> >   CLOUDSTACK-5569
>> > enhance OVS plug-in to support region level VPC and guest networks
>>that
>> span zones
>> > Murali Reddy  Murali Reddy  Open
>>Unresolved
>>  19/Dec/13   19/Dec/13
>> >   CLOUDSTACK-5568
>> > introduce notion of guest network that spans multiple zones
>> > Murali Reddy  Murali Reddy  Open
>>Unresolved
>>  19/Dec/13   19/Dec/13
>> >   CLOUDSTACK-5567
>> > enable VPC at region level
>> > Murali Reddy  Murali Reddy  Open
>>Unresolved
>>  19/Dec/13   19/Dec/13
>> >   

[4.3] Gobbledygook stats after overprovisioning

[Nux!]

Hi,

I'm on 4.3 rev 4440 (latest RC). After playing around with 
overprovisioning I'm left out with this in the Dashboard:
9.52 TB of (local) storage instead of 3.17 TB (although the individual 
primary storage entry in Infrastructure shows the right thing)

119.95 GHz instead of 60GHz (24 cores * 2.5 GHz)
157.30 GB instead of 80 GB

This is despite setting the overprovisioning back to original settings 
in all places (global, zone and cluster settings)


How could I force a re-read of all resources and have them displayed 
correctly?


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: 4.4 Feature Freeze

[Daan Hoogland]

Abhinandan, first one compromis-proposal, please.

Can we not postpone but allow for this one feature (CLOUDSTACK-6161)
this one time (4.4) to go in after feature freeze. If this is the only
one and we don't consider this jurisprudence we could allow for it.
@Hugo: say what?



On Mon, Mar 3, 2014 at 9:33 AM, Abhinandan Prateek
 wrote:
> I think there is no consensus on feature freeze date yet ?
>
> Daan,
>  Shall we call for a vote on this ?
>
> -abhi
>
> On 03/03/14 6:11 am, "Mike Tutkowski"  wrote:
>
>>I believe March 14th is Feature Freeze and, as such, when the 4.4 branch
>>is
>>cut.
>>
>>
>>On Sun, Mar 2, 2014 at 11:12 AM, Sebastien Goasguen
>>wrote:
>>
>>>
>>> On Feb 28, 2014, at 9:09 AM, Hugo Trippaers  wrote:
>>>
>>> > i'm all for being flexible, but i find a lot of the arguments used
>>>here
>>> debatable.
>>> >
>>> > "It causes developers to rush their development to meet the deadline."
>>> This will happen anyway, every time we've extended the deadline we got
>>>new
>>> features coming in at the last minute. Actually i'm under the impression
>>> that when we move the deadline people will actually try to get more
>>> features in instead of working on stabilizing existing features.
>>> >
>>> > "We can't deliver features on the roadmap." There is validity to this
>>> point, but on the other hand we already know the entire release schedule
>>> way ahead, this feature freeze date should not come as a surprise. But
>>>as i
>>> mentioned in an earlier mail, lets have this discussion. Post which
>>> features might not make it into the release so we can have a discussion
>>>if
>>> we should slip the release date to get this feature in. I think we all
>>>now
>>> that there are commercial parties working with this software to build
>>> releases and have customers demanding features, but if we don't discuss
>>> that on list it's hard for us to take it into account.
>>> >
>>> > "Feature freeze wasn't called" True, i wasn't even aware that this
>>>was a
>>> requirement. We should add this to the procedure here
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so
>>> release managers know this is expected of them. It should not impact the
>>> dates as the dates are already fixed by the release schedule (every 4
>>> months)
>>> >
>>> >
>>> > I'm still -1 on extending the feature freeze. I would rather extend
>>>the
>>> test/stability phase to we have some more time to fix issues before we
>>>get
>>> into the RC spinning.
>>> >
>>> >
>>> > This is the list of current features targeted for 4.4 according to our
>>> Jira. Which features would be impacted if we don't move the feature
>>>freeze?
>>> >
>>> > ASF JIRA
>>> > Project: CloudStack
>>> > Type: New Feature
>>> > Fix Version: 4.4.0
>>> > Resolution: Unresolved
>>> > Sorted by: Updated descending
>>> > 1-15 of 15 as at: 28/Feb/14 15:07
>>> > T Key Summary AssigneeReporterP   Status
>>>  Resolution  Created Updated Due
>>> >   CLOUDSTACK-6181
>>> > Root resize
>>> > UnassignedNux   Open Unresolved
>>>  27/Feb/14   27/Feb/14
>>> >   CLOUDSTACK-6161
>>> > distributed routing and network ACL with OVS plug-in
>>> > Murali Reddy  Murali Reddy  Open
>>>Unresolved
>>>  24/Feb/14   24/Feb/14
>>> >   CLOUDSTACK-6092
>>> > Storage OverProvisioning as a Per Primary Basis
>>> > Saksham SrivastavaSaksham Srivastava  
>>>
>>> Open Unresolved  13/Feb/14   20/Feb/14
>>> >   CLOUDSTACK-6144
>>> > HA for guest VMs running Hyper-V
>>> > UnassignedRajesh BattalaOpen
>>>Unresolved
>>>  20/Feb/14   20/Feb/14
>>> >   CLOUDSTACK-6143
>>> > Storage Live-Migration support for Hyper-V
>>> > UnassignedRajesh BattalaOpen
>>>Unresolved
>>>  20/Feb/14   20/Feb/14
>>> >   CLOUDSTACK-6142
>>> > Zone Wide Primary Store in Hyper-V
>>> > UnassignedRajesh BattalaOpen
>>>Unresolved
>>>  20/Feb/14   20/Feb/14
>>> >   CLOUDSTACK-6104
>>> > PVLAN support for CloudStack deployment over Nexus 1000v in VMware
>>> environment
>>> > Sateesh Chodapuneedi  Sateesh Chodapuneedi
>>>
>>> Open Unresolved  14/Feb/14   15/Feb/14
>>> >   CLOUDSTACK-6109
>>> > Support of iSCSI as primary store in Hyper-V
>>> > Rajesh BattalaRajesh BattalaOpen
>>> Unresolved  14/Feb/14   14/Feb/14
>>> >   CLOUDSTACK-6106
>>> > Support of VPC in HyperV
>>> > Rajesh BattalaRajesh BattalaOpen
>>> Unresolved  14/Feb/14   14/Feb/14
>>> >   CLOUDSTACK-6090
>>> > Virtual Router Service Failure Alerting
>>> > Harikrishna Patnala   Harikrishna Patnala 
>>>
>>> Open Unresolved  13/Feb/14   13/Feb/14
>>> >   CLOUDSTACK-6052
>>> > List VM enhancement to support querying with multiple VM IDs
>>> > Koushik Das   Koushik Das   Open
>>>Unresolved
>>>  07/Feb/14   07/Feb/14
>>> >   CLOUDSTACK-5569
>>> > enhance OVS plug-in to support region level VPC and guest 

Re: ALARM - ACS reboots host servers!!!

[France]

I believe this is a bug too, because VMs not running on the storage, get 
destroyed too:


Issue has been around for a long time, like with all others I reported. 
They do not get fixed:

https://issues.apache.org/jira/browse/CLOUDSTACK-3367

We even lost assignee today.

Regards,
F.

On 3/3/14 6:55 AM, Koushik Das wrote:

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 it's expected to go berserk. I've noticed similar
behaviour in Xenserver pools without ACS.
I'd imagine a "cure" for this would be to use network distributed
"filesystems" like GlusterFS or CEPH.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Review Request 16274: Contrail VRouter Plugin - VPC Implementation, Bug fixes

[daan Hoogland]

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


suresh, this patch does not apply. You should upload it in th menu and not 
attach it. Please disgard if this is no longer applicable, or else rebase and 
update,

Thanks,
Daan

- daan Hoogland


On Dec. 30, 2013, 10:33 p.m., Suresh Balineni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16274/
> ---
> 
> (Updated Dec. 30, 2013, 10:33 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> - Juniper Contrail VRouter VPC Implementation.
> - Network Policy Support added.
> - Contrail Public Network Offerring added. Earlier, Public Network was added 
> when plugin receives event about physical network creation. 
> - Some bug fixes in contrail plugin.
> - Contrail plugin is enabled my added spring context xml file.
> 
> 
> Diffs
> -
> 
> 
> Diff: https://reviews.apache.org/r/16274/diff/
> 
> 
> Testing
> ---
> 
> - Contrail plugin code is completely tested.
> - VPC tests are verified.
> 
> 
> File Attachments
> 
> 
> Contrail VPC Implementation
>   
> https://reviews.apache.org/media/uploaded/files/2013/12/15/206339e2-7695-48b9-8549-f9090d5e24c7__juniper-contrail-vpc-implementation.patch
> 
> 
> Thanks,
> 
> Suresh Balineni
> 
>

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

[Antonio Fornie]

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

(Updated March 3, 2014, 9:01 a.m.)


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


Changes
---

Added cmdeventtype ctxuserid ctxstarteventid ctxaccountid as expected 
parameters, and added Unit Test to check that none of the expected parameters 
detected so far is considered unknown.


Repository: cloudstack-git


Description
---

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


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
  api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
  api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
  api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java 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 ff2b2ea 
  server/src/com/cloud/storage/snapshot/SnapshotSchedulerImpl.java 183a13a 
  server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
  server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
PRE-CREATION 

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


Testing
---

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

All unit and integration tests.

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

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


Thanks,

Antonio Fornie

Re: 4.3 gets the wrong number of CPU sockets

[Harikrishna Patnala]

Hi, 
In case of KVM we read the socket count from the parameter ‘sockets’ in 
NodeInfo class.
Can you check with the command “virsh nodeinfo” ?
How many cores do you have per cpu ?

Thanks
Harikrishna

  
On 02-Mar-2014, at 7:50 pm, Nux!  wrote:

> Hello,
> 
> Which script is responsible for getting the number of CPU sockets of a KVM 
> hypervisor? Right now I have one with 2 CPUs but ACS only shows me 1.
> 
> cat /proc/cpuinfo | grep "physical id" | sort | uniq | wc -l
> 2
> 
> 
> -- 
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

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/#review35950
---


is this still a valid patch? should it be updated?

- daan Hoogland


On Jan. 7, 2014, 4:28 p.m., Axel Delahaye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16688/
> ---
> 
> (Updated Jan. 7, 2014, 4:28 p.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/js/ajaxkeys.js 60c9798 
>   services/console-proxy/server/js/ajaxviewer.js 9643204 
> 
> 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.3 gets the wrong number of CPU sockets

[Nux!]

On 03.03.2014 09:14, Harikrishna Patnala wrote:

Hi,
In case of KVM we read the socket count from the parameter ‘sockets’
in NodeInfo class.
Can you check with the command “virsh nodeinfo” ?
How many cores do you have per cpu ?


Indeed it seems like libvirt issue:

virsh nodeinfo
CPU model:   x86_64
CPU(s):  24
CPU frequency:   2499 MHz
CPU socket(s):   1
Core(s) per socket:  6
Thread(s) per core:  2
NUMA cell(s):2
Memory size: 82469688 KiB

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

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/#review35951
---


is this still valid? It is not applied on master. Should it be?

- 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: 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/#review35952
---


Commit ebcaec8632dbd92c071317f3190915244a287afb in cloudstack's branch 
refs/heads/master from David Grizzanti
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ebcaec8 ]

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

Signed-off-by: Daan Hoogland 


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

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

[daan Hoogland]

---
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/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
> 
>

RE: 4.4 Feature Freeze

[Devdeep Singh]

I was looking into adding support for iSCSI (CLOUDSTACK-6109) and HA of guest 
vms (CLOUDSTACK-6144) for hyper-v. I don't think I'll be able to finish it by 
14th.



Regards,

Devdeep


From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Friday, February 28, 2014 7:40 PM
To: 
Subject: Re: 4.4 Feature Freeze

i'm all for being flexible, but i find a lot of the arguments used here 
debatable.

"It causes developers to rush their development to meet the deadline." This 
will happen anyway, every time we've extended the deadline we got new features 
coming in at the last minute. Actually i'm under the impression that when we 
move the deadline people will actually try to get more features in instead of 
working on stabilizing existing features.

"We can't deliver features on the roadmap." There is validity to this point, 
but on the other hand we already know the entire release schedule way ahead, 
this feature freeze date should not come as a surprise. But as i mentioned in 
an earlier mail, lets have this discussion. Post which features might not make 
it into the release so we can have a discussion if we should slip the release 
date to get this feature in. I think we all now that there are commercial 
parties working with this software to build releases and have customers 
demanding features, but if we don't discuss that on list it's hard for us to 
take it into account.

"Feature freeze wasn't called" True, i wasn't even aware that this was a 
requirement. We should add this to the procedure here 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so release 
managers know this is expected of them. It should not impact the dates as the 
dates are already fixed by the release schedule (every 4 months)


I'm still -1 on extending the feature freeze. I would rather extend the 
test/stability phase to we have some more time to fix issues before we get into 
the RC spinning.


This is the list of current features targeted for 4.4 according to our Jira. 
Which features would be impacted if we don't move the feature freeze?

ASF JIRA
Project: CloudStack
Type: New Feature
Fix Version: 4.4.0
Resolution: Unresolved
Sorted by: Updated descending
1-15 of 15 as at: 28/Feb/14 15:07
TKey Summary Assignee  Reporter  P  
Status  Resolution   Created  Updated  Due
[New Feature]  CLOUDSTACK-6181
Root resize
UnassignedNux [Major] [Open]  Open  Unresolved  
27/Feb/1427/Feb/14
[New Feature]  CLOUDSTACK-6161
distributed routing and network ACL with OVS plug-in
Murali ReddyMurali Reddy  [Major] [Open]  Open  
Unresolved  24/Feb/1424/Feb/14
[New Feature]  CLOUDSTACK-6092
Storage OverProvisioning as a Per Primary Basis
Saksham Srivastava   Saksham Srivastava[Major] [Open]  Open 
 Unresolved  13/Feb/1420/Feb/14
[New Feature]  CLOUDSTACK-6144
HA for guest VMs running Hyper-V
UnassignedRajesh Battala [Major] [Open]  Open  Unresolved   
   20/Feb/1420/Feb/14
[New Feature]  CLOUDSTACK-6143
Storage Live-Migration support for Hyper-V
UnassignedRajesh Battala [Major] [Open]  Open  Unresolved   
   20/Feb/1420/Feb/14
[New Feature]  CLOUDSTACK-6142
Zone Wide Primary Store in Hyper-V
UnassignedRajesh Battala [Major] [Open]  Open  Unresolved   
   20/Feb/1420/Feb/14
[New Feature]  CLOUDSTACK-6104
PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
Sateesh Chodapuneedi  Sateesh Chodapuneedi   [Major] 
[Open]  Open  Unresolved  14/Feb/14  15/Feb/14
[New Feature]  CLOUDSTACK-6109
Support of iSCSI as primary store in Hyper-V
Rajesh Battala   Rajesh Battala [Major] [Open]  Open  
Unresolved  14/Feb/1414/Feb/14
[New Feature]  CLOUDSTACK-6106
Support of VPC in HyperV
Rajesh Battala   Rajesh Battala [Major] [Open]  Open  
Unresolved  14/Feb/1414/Feb/14
[New Feature]  CLOUDSTACK-6090
Virtual Router Service Failure Alerting
Harikrishna Patnala   Harikrishna Patnala [Major] [Open]  Open  
Unresolved  13/Feb/1413/Feb/14
[New Feature]  CLOUDSTACK-6052
List VM enhancement to support querying with multiple VM IDs
Koushik Das  Koushik Das   [Major] [Open]  Open  Unresolved 
 07/Feb/1407/Feb/14
[New Feature]  CLOUDSTACK-5569
enhance OVS plug-in to support region level VPC and guest networks that span 
zones
Murali ReddyMurali Reddy  [Major] [Open]  Open  
Unresolved  19/Dec/1319/Dec/13
[New Feature]  CLOUDSTACK-5568
introduce notion of guest network that spans multiple zones
Murali ReddyMurali Reddy  [Major] [Open]  Open  
Unresolved  19/Dec/13   

Re: [DEVCLOUD2] Internet access on VMs

[Ian Duffy]

Ended up solving this with IP forwarding and iptables.

Modified the devcloud.cfg to use 192.168.56.10 as the gateway.

Enabled IPv4 Forwarding:
sed -i -e 's/#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/g'
/etc/sysctl.conf

Setup appropriate iptables:
-A FORWARD -i eth0 -o xenbr0 -m state --state NEW,RELATED,ESTABLISHED -j
ACCEPT
-A FORWARD -i xenbr0 -o eth0 -j ACCEPT

-A POSTROUTING -o eth0 -j MASQUERADE



On 2 March 2014 23:33, Ian Duffy  wrote:

> Hi All,
>
> I'm trying to setup devcloud using the documentation at
> http://bhaisaab.org/logs/devcloud/ and the puppet manifests at
> https://github.com/apache/cloudstack/tree/master/tools/devcloud/src
>
> I have basebox of debian wheezy running xcp-xapi on virtualbox. I have
> xenbr0 bridged to the host only adapter so my management server(running on
> the host machine) can access the xcp-xapi. I have xenbr1 bridged to a NAT
> interface so the hypervisor has internet.
>
> Going off the marvin configuration devcloud.cfg my setup is as follows:
>
> management server: 192.168.56.1
> hypervisor: 192.168.56.10
> gateway: 192.168.56.1
> internal dns: 192.168.56.1
>
> My two system vms come up without issue and get a 192.168.56.X IP
> addresses for private/public, however neither of them have internet access.
> Their gateways are pointing to 192.168.56.1 which is my host machine.
>
> Is there some trick I'm missing out on? Should my host machine be acting
> as a router for the VMs? Is there some way I can forward their traffic over
> the xenbr1 interface?
>
> In the past I was running on VMWare Fusion and I just enabled their NAT
> functionality on the private adapter which works wonderfully. However I
> want to try getting this working with vagrant.
>
> Thanks,
> Ian
>

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

[Axel Delahaye]

---
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.


Changes
---

Add new item in console proxy menu list : "French AZERTY keyboard" (So now I 
don't replace the Standard (US) keyboard)
Add comment to describe the key before each rule : //[50 = ~]
Fix some key translation : (M,m)


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

  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

Review Request 18679: added a row for simulator in the hypervisor_capabilities

[Rajani Karuturi]

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

Review request for cloudstack, Abhinandan Prateek, Koushik Das, Santhosh 
Edukulla, and Prasanna Santhanam.


Repository: cloudstack-git


Description
---

added a row for simulator in the hypervisor_capabilities. This will be run 
only when deploydb-sumulator is called
This fixes some of the attach volume test cases when run against simulator.


Diffs
-

  developer/pom.xml 5996de7 
  setup/db/hypervisors.simulator.sql PRE-CREATION 

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


Testing
---

tested by running attach volume tests against simulator


Thanks,

Rajani Karuturi

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

[Axel Delahaye]

> On March 3, 2014, 9:23 a.m., daan Hoogland wrote:
> > is this still a valid patch? should it be updated?

I uploaded a new version for 4.2.1 systemvm


- Axel


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


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

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

[Rajani Karuturi]

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

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
 f30bd36 

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 18679: added a row for simulator in the hypervisor_capabilities

[Rajani Karuturi]

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

(Updated March 3, 2014, 11:22 a.m.)


Review request for cloudstack, Abhinandan Prateek, Koushik Das, Santhosh 
Edukulla, and Prasanna Santhanam.


Repository: cloudstack-git


Description
---

added a row for simulator in the hypervisor_capabilities. This will be run 
only when deploydb-sumulator is called
This fixes some of the attach volume test cases when run against simulator.


Diffs
-

  developer/pom.xml 5996de7 
  setup/db/hypervisors.simulator.sql PRE-CREATION 

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


Testing
---

tested by running attach volume tests against simulator


Thanks,

Rajani Karuturi

Re: ALARM - ACS reboots host servers!!!

[Andrei Mikhailovsky]

Pretty poor, I agree. 


IMHO the ACS agent should not be allowed to reboot the host server. This is not 
the type of things you would like to automate as you will eventually end up 
with broken volumes and data loss. 


And you are right of course, like what happened in my case. I currently have 
two vms which used that NFS server for volumes and the rest 50+ vms use ceph. 
As a result of the nfs server reboot all host servers have rebooted causing 50+ 
vms to reset without being properly shutdown. 


I am using ACS 4.2.1 with KVM, so this issue seems to be present on KVM + 
XenServer. 


Andrei 
- Original Message -

From: "France"  
To: us...@cloudstack.apache.org 
Cc: dev@cloudstack.apache.org 
Sent: Monday, 3 March, 2014 8:49:28 AM 
Subject: Re: ALARM - ACS reboots host servers!!! 

I believe this is a bug too, because VMs not running on the storage, get 
destroyed too: 

Issue has been around for a long time, like with all others I reported. 
They do not get fixed: 
https://issues.apache.org/jira/browse/CLOUDSTACK-3367 

We even lost assignee today. 

Regards, 
F. 

On 3/3/14 6:55 AM, Koushik Das wrote: 
> 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 it's expected to go berserk. I've noticed similar 
> behaviour in Xenserver pools without ACS. 
> I'd imagine a "cure" for this would be to use network distributed 
> "filesystems" like GlusterFS or CEPH. 
> 
> Lucian 
> 
> -- 
> Sent from the Delta quadrant using Borg technology! 
> 
> Nux! 
> www.nux.ro 

Re: Review Request 18679: added a row for simulator in the hypervisor_capabilities

[Santhosh Edukulla]

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



setup/db/hypervisors.simulator.sql


All values seems to be default values except id,uuid etc. 
We can leave default values as it is rather setting them explicitly. 
This way, if these default values  gets changed in future, the values will 
be set accordingly instead of user provided values. If we want user provided 
values for this, then we can explicitly specify



setup/db/hypervisors.simulator.sql


Id seems to be auto increment values, we can leave it by default, by chance 
if we have a row with id 22, then this insert will fail.

I believe there is no constraint on uuid for simulator, it can be any 
varchar?


- Santhosh Edukulla


On March 3, 2014, 11:22 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18679/
> ---
> 
> (Updated March 3, 2014, 11:22 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Koushik Das, Santhosh 
> Edukulla, and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> added a row for simulator in the hypervisor_capabilities. This will be 
> run only when deploydb-sumulator is called
> This fixes some of the attach volume test cases when run against 
> simulator.
> 
> 
> Diffs
> -
> 
>   developer/pom.xml 5996de7 
>   setup/db/hypervisors.simulator.sql PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/18679/diff/
> 
> 
> Testing
> ---
> 
> tested by running attach volume tests against simulator
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: ALARM - ACS reboots host servers!!!

[Andrei Mikhailovsky]

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 it's expected to go berserk. I've noticed similar 
 behaviour in Xenserver pools without ACS. 
 I'd imagine a "cure" for this would be to use network distributed 
 "filesystems" like GlusterFS or CEPH. 
 
 Lucian 
 
 -- 
 Sent from the Delta quadrant using Borg technology! 
 
 Nux! 
 www.nux.ro 

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

[Saksham Srivastava]

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

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 18352: CLOUDSTACK-6151: Local data disk with tag goes to the wrong local storage pool

[Saksham Srivastava]

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

(Updated March 3, 2014, 1:57 p.m.)


Review request for cloudstack, Koushik Das and Prachi Damle.


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


Repository: cloudstack-git


Description (updated)
---

Attaching a new disk created from local disk offering with tags, to a VM was 
going to wrong local storage pool.
Cause : In LocalStoragePoolAlocator-
List hostPools = _poolHostDao.listByHostId(plan.getHostId());
It return pools by hostId, but nowhere were the tags being compared.

Added new method findLocalStoragePoolsByHostAndTags() that returns stoage pools 
by hostid and tags both.


Diffs (updated)
-

  
engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
 ea0bad9 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
 59c338e 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
 d35aa44 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
 1f61e8b 
  server/test/resources/createNetworkOffering.xml c6228da 

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


Testing (updated)
---

Tested the folowing scenarios:
attaching local volume with tags
attaching local volume without tags
attaching local volume with different tags
attaching shared volume

Build passes successfully.
Patch applies cleanly.


Thanks,

Saksham Srivastava

[QUESTION]db unavailable recovery

[Daan Hoogland]

H,

is it normal behavior that cloudstack won't reconnect to the db if it
has been down while cloudstack was running? I would expect a
reconnect. Or is there a rationale for not attempting a reconnect?

-- 
Daan

Re: [QUESTION]db unavailable recovery

[Wido den Hollander]

On 03/03/2014 03:29 PM, Daan Hoogland wrote:

H,

is it normal behavior that cloudstack won't reconnect to the db if it
has been down while cloudstack was running? I would expect a
reconnect. Or is there a rationale for not attempting a reconnect?



It doesn't and that's normal. Since CS relies on the DB it simply kills 
itself if it looses connection.


Normally you have multiple Management servers running, so loosing one 
shouldn't be a problem.


There is a old thread about this on the dev@ list explaining it all.

Wido

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

[Sonal Ojha]

I have raised review via review board as well.

On Monday, March 3, 2014, Daan Hoogland  wrote:

> Sonal,
>
> please do this via the review board. This might be inconvenient but it
> gives us nicer trackrecords then mail threads do.
>
> thanks,
> Daan
>
> On Mon, Mar 3, 2014 at 5:24 AM, Sonal Ojha 
> >
> wrote:
> > Hello,
> >
> > I am attaching the final
> > patch(CLOUDSTACK-3272-Changes-to-allow-publishing-of-event.txt) with this
> > mail, it has the changes based on the global config parameters (mentioned
> > below) events would be published or not based on the very parameter.
> >
> > "publish.action.events"
> > "publish.alert.events"
> > "publish.resource.state.events"
> > "publish.usage.events"
> > "publish.async.job.events"
> >
> > Kindly let me know your comments.
> >
> > --
> >
> > Thanks and Regards,
> >
> > Sonal Ojha * Senior Engineer Product Development *  SunGard IT
> Availability
> >
> > Mobile +91-9922412645* E-Mail: sonal.o...@sungard.com 
>
>
>
> --
> Daan
>
>

-- 

Regards,

___

*Sonal Ojha* ● Senior Engineer - Product Developement ● SunGard
Availability Services, India ● Mobile: +91 9922412645●  Email:
sonal.o...@sungard.com ● Website: http://www.sungardas.in/

8 Times Winner – BC Service Provider of the Year – 2011, 2010, 2009, 2006,
2005, 2002, 2000, 1999; Finalist – 2008, 2007, 2004, 2001 ● Excellence in
Infrastructure Management – 2010 ● Outstanding Excellence in Business
Continuity – 2008 ● Business Continuity Provider of the Year (BCM Service)
– 2013 BCI Global Awards ● Business Continuity Provider of the Year (BCM
Product) – 2013 BCI India Awards

*[image: AS_yt]* *[image:
AS_twitter]* *[image:
AS_in]**[image:
AS_gplus]* *[image:
AS_fb]**[image:
AS_ss]* 

Re: [QUESTION]db unavailable recovery

[Erik Weber]

Except if your db is the issue and all your management servers die.

-- 
Erik
3. mars 2014 15:48 skrev "Wido den Hollander"  følgende:

>
>
> On 03/03/2014 03:29 PM, Daan Hoogland wrote:
>
>> H,
>>
>> is it normal behavior that cloudstack won't reconnect to the db if it
>> has been down while cloudstack was running? I would expect a
>> reconnect. Or is there a rationale for not attempting a reconnect?
>>
>>
> It doesn't and that's normal. Since CS relies on the DB it simply kills
> itself if it looses connection.
>
> Normally you have multiple Management servers running, so loosing one
> shouldn't be a problem.
>
> There is a old thread about this on the dev@ list explaining it all.
>
> Wido
>

Review Request 18689: CS-19420: [UI] Fixed invalid filed name (label.dynamically.scalable) on instance details.

[Mihaela Stoica]

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

Review request for cloudstack, Brian Federle and Jessica Wang.


Repository: cloudstack-git


Description
---

CS-19420: [UI] Fixed invalid filed name (label.dynamically.scalable) on 
instance details.


Diffs
-

  ui/dictionary.jsp bf48417 

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


Testing
---


Thanks,

Mihaela Stoica

Re: Review Request 18689: CS-19420: [UI] Fixed invalid field name (label.dynamically.scalable) on instance details.

[Mihaela Stoica]

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

(Updated March 3, 2014, 4:23 p.m.)


Review request for cloudstack, Brian Federle and Jessica Wang.


Summary (updated)
-

CS-19420: [UI] Fixed invalid field name (label.dynamically.scalable) on 
instance details.


Repository: cloudstack-git


Description (updated)
---

CS-19420: [UI] Fixed invalid field name (label.dynamically.scalable) on 
instance details.


Diffs
-

  ui/dictionary.jsp bf48417 

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


Testing
---


Thanks,

Mihaela Stoica

Re: Review Request 18689: CS-19420: [UI] Fixed invalid field name (label.dynamically.scalable) on instance details.

[Mihaela Stoica]

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

(Updated March 3, 2014, 4:27 p.m.)


Review request for cloudstack, Brian Federle and Jessica Wang.


Repository: cloudstack-git


Description
---

CS-19420: [UI] Fixed invalid field name (label.dynamically.scalable) on 
instance details.


Diffs (updated)
-

  ui/dictionary.jsp bf48417 

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


Testing
---


Thanks,

Mihaela Stoica

Re: ALARM - ACS reboots host servers!!!

[Marcus]

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 it's expected to go berserk. I've noticed similar
> behaviour in Xenserver pools without ACS.
> I'd imagine a "cure" for this would be to use network distributed
> "filesystems" like GlusterFS or CEPH.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
>

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

[Marcus Sorensen]

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

Review Request 18695: Fix for CLOUDSTACK-4563: Initial zone wizard UI label issue

[Gabor Apati-Nagy]

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

Review request for cloudstack, Brian Federle and Jessica Wang.


Repository: cloudstack-git


Description
---

This patch fixes CLOUDSTACK-4563, so that the 'Provider' label  will use 
localized text instead of wired-in 'Provider' text.


Diffs
-

  client/WEB-INF/classes/resources/messages.properties f1c166b 
  ui/dictionary.jsp 16ecbab 
  ui/scripts/zoneWizard.js 13630c1 

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


Testing
---


Thanks,

Gabor Apati-Nagy

Re: [4.3] Gobbledygook stats after overprovisioning

[Nux!]

On 03.03.2014 08:39, Nux! wrote:

Hi,

I'm on 4.3 rev 4440 (latest RC). After playing around with
overprovisioning I'm left out with this in the Dashboard:
9.52 TB of (local) storage instead of 3.17 TB (although the
individual primary storage entry in Infrastructure shows the right
thing)
119.95 GHz instead of 60GHz (24 cores * 2.5 GHz)
157.30 GB instead of 80 GB

This is despite setting the overprovisioning back to original
settings in all places (global, zone and cluster settings)

How could I force a re-read of all resources and have them displayed 
correctly?


Here's a picture that would hopefully be more meaningful:
http://img.nux.ro/H9f-Selection_054.png

Anyideas how to reset the values to "normal"?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [DISCUSS] realhostip.com going away

[John Kinsella]

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: [DISCUSS] realhostip.com going away

[Nux!]

On 03.03.2014 16:58, 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.


I think it would be irresponsible of Citrix to close this service 
before there have been 2-3 good releases that no longer need this 
feature, to give people decent time to upgrade.


Even then, assuming Cloudstack has been reasonably popular there will 
be loads of complaints. I'd imagine most of the deployments are quite 
small and the people did not bother to implement or even look up this 
feature, some may not even be aware of it.


imho
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [4.3] Gobbledygook stats after overprovisioning

[Marcus]

What is your overprovisioning set to? The dashboard might be correct,
for example if you have 3.17T and set overprovision to 3 you'll have
9.51T of allocatable space.

On Mon, Mar 3, 2014 at 9:50 AM, Nux!  wrote:
> On 03.03.2014 08:39, Nux! wrote:
>>
>> Hi,
>>
>> I'm on 4.3 rev 4440 (latest RC). After playing around with
>> overprovisioning I'm left out with this in the Dashboard:
>> 9.52 TB of (local) storage instead of 3.17 TB (although the
>> individual primary storage entry in Infrastructure shows the right
>> thing)
>> 119.95 GHz instead of 60GHz (24 cores * 2.5 GHz)
>> 157.30 GB instead of 80 GB
>>
>> This is despite setting the overprovisioning back to original
>> settings in all places (global, zone and cluster settings)
>>
>> How could I force a re-read of all resources and have them displayed
>> correctly?
>
>
> Here's a picture that would hopefully be more meaningful:
> http://img.nux.ro/H9f-Selection_054.png
>
> Anyideas how to reset the values to "normal"?
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro

RE: Removing TAGS

[Alex Huang]

What does it achieve?  Tags don't cost anything.  The code came from Citrix.  
Removing the TAGS is not going to take that away.  

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

Re: [4.3] Gobbledygook stats after overprovisioning

[Nux!]

On 03.03.2014 17:18, Marcus wrote:

What is your overprovisioning set to? The dashboard might be correct,
for example if you have 3.17T and set overprovision to 3 you'll have
9.51T of allocatable space.


Marcus,

That's the thing, I played with overprovisioning, but then set 
everything back to 1.0 rations, CPU, memory and storage! Restarted the 
management server countless times since, no change in the dashboard.


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Exception adding XenServer host to CS

[Mike Tutkowski]

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

}


}


Right before this code, the XenServer server resource tries to copy a bunch
of files to the XenServer host, but several of these files cannot be found
on the CS management server:

WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We cannot
locate
/home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_firewall.sh
WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We cannot
locate
/home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//bumpUpPriority.sh
WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We cannot
locate
/home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//dhcp_entry.sh
WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We cannot
locate
/home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_loadbalancer.sh
WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We cannot
locate
/home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//save_password_to_domr.sh
WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We cannot
locate
/home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../vhd-util

I know that vhd-util has to be manually copied to the CS MS, but what about
the others?


Thanks!


On Fri, Feb 28, 2014 at 11:40 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Thanks, Kelven! Glad it's not just me. :)
>
> When I have a little free time this afternoon, I plan to look into this in
> more detail - unless, of course, a XenServer-focused developer already
> knows what's going on.
>
>
> On Fri, Feb 28, 2014 at 11:37 AM, Kelven Yang wrote:
>
>> I was also trying master this morning and ran into the same problem
>>
>> Kelven
>>
>> On 2/28/14, 10:19 AM, "Mike Tutkowski" 
>> wrote:
>>
>> >Just curious if anyone else has been able to successfully add a XenServer
>> >host to a newly created cloud on master recently?
>> >
>> >
>> >On Thu, Feb 27, 2014 at 10:58 PM, Mike Tutkowski <
>> >mike.tutkow...@solidfire.com> wrote:
>> >
>> >> I've tried this with a couple different XenServer 6.1 hosts...same
>> >>results.
>> >>
>> >> One exception I noticed that was buried was at the top of the log (look
>> >> familiar to anyone?):
>> >>
>> >> ERROR [c.c.a.ApiServer] (1182531138@qtp-1140222894-7:ctx-2111b24c
>> >> ctx-e6ecb4c0) unhandled exception executing api command: addHost
>> >> com.cloud.utils.exception.CloudRuntimeException: Cannot transit agent
>> >> status with event AgentDisconnected for host 1, mangement server id is
>> >> 52231564957,Unable to transition to a new state from Creating via
>> >> AgentDisconnected
>> >> at
>> >>
>>
>> >>com.cloud.agent.manager.AgentManagerImpl.agentStatusTransitTo(AgentManage
>> >>rImpl.java:1343)
>> >> at
>> >>
>>
>> >>com.cloud.resource.ResourceManagerImpl.markHostAsDisconnected(ResourceMan
>> >>agerImpl.java:1693)
>> >> at
>> >>
>>
>> >>com.cloud.resource.ResourceManagerImpl.createHostAndAgentDeferred(Resourc
>> >>eManagerImpl.java:1854)
>> >> at
>> >>
>>
>> >>com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerI
>> >>mpl.java:756)
>> >> at
>> >>
>>
>> >>com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.
>> >>java:571)
>> >>
>> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >> at
>> >>
>>
>> >>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
>> >>:57)
>> >> at
>> >>
>>
>> >>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>> >>mpl.java:43)
>> >> at java.lang.reflect.Method.invoke(Method.java:606)
>> >> at
>> >>
>>
>> >>org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(A
>> >>opUtils.java:317)
>> >> at
>> >>
>>
>> >>org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpo
>> >>int(ReflectiveMethodInvocation.java:183)
>> >>

Re: Exception adding XenServer host to CS

[Mike Tutkowski]

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);
>
> }
>
>
> }
>
>
> Right before this code, the XenServer server resource tries to copy a
> bunch of files to the XenServer host, but several of these files cannot be
> found on the CS management server:
>
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
> cannot locate
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_firewall.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
> cannot locate
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//bumpUpPriority.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
> cannot locate
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//dhcp_entry.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
> cannot locate
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_loadbalancer.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
> cannot locate
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//save_password_to_domr.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
> cannot locate
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../vhd-util
>
> I know that vhd-util has to be manually copied to the CS MS, but what
> about the others?
>
>
> Thanks!
>
>
> On Fri, Feb 28, 2014 at 11:40 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Thanks, Kelven! Glad it's not just me. :)
>>
>> When I have a little free time this afternoon, I plan to look into this
>> in more detail - unless, of course, a XenServer-focused developer already
>> knows what's going on.
>>
>>
>> On Fri, Feb 28, 2014 at 11:37 AM, Kelven Yang wrote:
>>
>>> I was also trying master this morning and ran into the same problem
>>>
>>> Kelven
>>>
>>> On 2/28/14, 10:19 AM, "Mike Tutkowski" 
>>> wrote:
>>>
>>> >Just curious if anyone else has been able to successfully add a
>>> XenServer
>>> >host to a newly created cloud on master recently?
>>> >
>>> >
>>> >On Thu, Feb 27, 2014 at 10:58 PM, Mike Tutkowski <
>>> >mike.tutkow...@solidfire.com> wrote:
>>> >
>>> >> I've tried this with a couple different XenServer 6.1 hosts...same
>>> >>results.
>>> >>
>>> >> One exception I noticed that was buried was at the top of the log
>>> (look
>>> >> familiar to anyone?):
>>> >>
>>> >> ERROR [c.c.a.ApiServer] (1182531138@qtp-1140222894-7:ctx-2111b24c
>>> >> ctx-e6ecb4c0) unhandled exception executing api command: addHost
>>> >> com.cloud.utils.exception.CloudRuntimeException: Cannot transit agent
>>> >> status with event AgentDisconnected for host 1, mangement server id is
>>> >> 52231564957,Unable to transition to a new state from Creating via
>>> >> AgentDisconnected
>>> >> at
>>> >>
>>>
>>> >>com.cloud.agent.manager.AgentManagerImpl.agentStatusTransitTo(AgentManage
>>> >>rImpl.java:1343)
>>> >> at
>>> >>
>>>
>>> >>com.cloud.resource.ResourceManagerImpl.markHostAsDisconnected(ResourceMan
>>> >>agerImpl.java:1693)
>>> >> at
>>> >>
>>>
>>> >>com.cloud.resource.ResourceManagerImpl.createHostAndAgentDeferred(Resourc
>>> >>eManagerImpl.java:1854)
>>> >> at
>>> >>
>>>
>>> >>com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerI
>>> >>mpl.java:756)
>>> >> at
>>> >>
>>>
>>> >>com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.
>>> >>java:571)
>>> >>
>>> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> >> at
>>> >>
>>>
>>> >>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
>>> >>:57)
>>> >> at
>>> >>
>>>
>>> >>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet

Re: Exception adding XenServer host to CS

[Mike Tutkowski]

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);
>>
>> }
>>
>>
>> }
>>
>>
>> Right before this code, the XenServer server resource tries to copy a
>> bunch of files to the XenServer host, but several of these files cannot be
>> found on the CS management server:
>>
>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>> cannot locate
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_firewall.sh
>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>> cannot locate
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//bumpUpPriority.sh
>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>> cannot locate
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//dhcp_entry.sh
>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>> cannot locate
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_loadbalancer.sh
>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>> cannot locate
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//save_password_to_domr.sh
>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>> cannot locate
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../vhd-util
>>
>> I know that vhd-util has to be manually copied to the CS MS, but what
>> about the others?
>>
>>
>> Thanks!
>>
>>
>> On Fri, Feb 28, 2014 at 11:40 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Thanks, Kelven! Glad it's not just me. :)
>>>
>>> When I have a little free time this afternoon, I plan to look into this
>>> in more detail - unless, of course, a XenServer-focused developer already
>>> knows what's going on.
>>>
>>>
>>> On Fri, Feb 28, 2014 at 11:37 AM, Kelven Yang wrote:
>>>
 I was also trying master this morning and ran into the same problem

 Kelven

 On 2/28/14, 10:19 AM, "Mike Tutkowski" 
 wrote:

 >Just curious if anyone else has been able to successfully add a
 XenServer
 >host to a newly created cloud on master recently?
 >
 >
 >On Thu, Feb 27, 2014 at 10:58 PM, Mike Tutkowski <
 >mike.tutkow...@solidfire.com> wrote:
 >
 >> I've tried this with a couple different XenServer 6.1 hosts...same
 >>results.
 >>
 >> One exception I noticed that was buried was at the top of the log
 (look
 >> familiar to anyone?):
 >>
 >> ERROR [c.c.a.ApiServer] (1182531138@qtp-1140222894-7:ctx-2111b24c
 >> ctx-e6ecb4c0) unhandled exception executing api command: addHost
 >> com.cloud.utils.exception.CloudRuntimeException: Cannot transit agent
 >> status with event AgentDisconnected for host 1, mangement server id
 is
 >> 52231564957,Unable to transition to a new state from Creating via
 >> AgentDisconnected
 >> at
 >>

 >>com.cloud.agent.manager.AgentManagerImpl.agentStatusTransitTo(AgentManage
 >>rImpl.java:1343)
 >> at
 >>

 >>com.cloud.resource.ResourceManagerImpl.markHostAsDisconnected(ResourceMan
 >>agerImpl.java:1693)
 >> at
 >>

 >>com.cloud.resource.ResourceManagerImpl.createHostAndAgentDeferred(Resourc
 >>eManagerImpl.java:1854)
 >> at
 >>

 >>com.cloud.resource.Resour

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

[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 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 get method is invoked) and mainly the fact that these get methods that
>fix the map on the fly are copies of each other: instead of fixing the
>structure in one method, the are plenty of methods almost identical
>copying
>and pasting the same lines. Some times the same method twice in the same
>cmd class for two Map params (look CreateNetworkOfferingCmd
>#getServiceCapabilities and #getServiceProviders).
>
>2- params in which the get method returns the map as it is. With the
>strange format. For example,
>Cloudmonkey command
>create networkoffering ... tags[0].key="City" tags[0].value="Toronto"
>
>You store in the table network_offeringstags, field tags, the String:
>{0={value=Toronto,key=City}}
>(including brackets and all)
>
>So knowing all this I guess you agree this should be refactored... unless
>at some point the strange format is needed. But after looking for it
>everywhere I didn't find any place where it was. I already did the change
>and tested most of the cases and it all seems to work.
>
>
>It would be great if once I upload the patch somebody could help me double
>check that it doesn't brake anything, not only reviewing to code. I did
>plenty of tests of many kinds, but I cannot be sure that I am covering
>enough. Further, there seem to be several places where the code expects
>the
>strange format.
>->ConfigurationManagerImpl line 1545
>
>
>Thanks. Cheers
>Antonio
>
>
>2014-02-28 18:44 GMT+01:00 Alena Prokharchyk
>:
>
>>
>>
>>   From: Antonio Fornié Casarrubios 
>> Date: Friday, February 28, 2014 at 2:09 AM
>> To: Rohit Yadav , cloudstack <
>> dev@cloudstack.apache.org>, Alena Prokharchyk <
>> alena.prokharc...@citrix.com>
>> Subject: Re: [PROPOSAL][QUESTION] Map parameters in API Commands
>>
>>   Hi Alena,
>>
>>  I would like to know your opinion on this change. Mainly consists on:
>> 1- Change the way we store the Map params after unpackParams in order to
>> have, for each Map param, a Map instead of Map> Map>.
>>
>>
>>  -Antonio, what was the reason for storing the parameter in the old
>> format to begin with? Where there any case where we actually needed a
>>map
>> of map parameters?
>>
>>
>
>>
>>  2- There are many commands that fix this strange format on demand on
>> their getters, so they do the conversion there. Since I already have the
>> final format I replace these getters with just
>> getTags(){ return this.tags;}
>>
>>  3- Persistence of these Map params. This last change is more tricky and
>> error-prone but the previous two would brake the functionality without
>>it.
>> Actually it doesn't seem that I should change this for all the cases,
>>given
>> that for some commands the current behavior is storing in the DB the
>>Map as
>> it comes, so after the change it will just do the same and thus
>>retrieve it
>> with the right format. So, although in the tables we move from
>> --
>> key | City
>> --
>> value | The Hague
>> --
>>
>>  to
>> --
>> City | The Hague
>> --
>>
>>  then in memory, after DB read, we will just have the proper format
>>again
>> (Map). Is that right?
>>
>>
>>
>>- in what table do you see key name being a field name? I've looked
>>at
>>various *_details tables, as well as resource_tag table, everywhere
>>we have
>>key/value fields where we store key and the value respectfully:
>>
>>  mysql> desc user_Vm_details;
>> 
>>+-+-+--+-+-++
>> | Field   | Type| Null | Key | Default | Extra
>>|
>> 
>>+-+-+--+-+-++
>> | id  | bigint(20) unsigned | NO   | PRI | NULL| auto_increment
>>|
>> | vm_id   | bigint(20) unsigned | NO   | MUL | NULL|
>>|
>> | name| varchar(255)| NO   | | NULL|
>>|
>> | value   | varchar(1024)   | NO   | | NULL|
>>|
>> | display | tinyint(1)  | NO   | | 1   |
>>|
>> 
>>+-+-+--+-+-++
>> 5 rows in set

Re: Removing TAGS

[Sebastien Goasguen]

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

Re: 4.4 Feature Freeze

[Sebastien Goasguen]

On Mar 3, 2014, at 5:34 AM, Devdeep Singh  wrote:

> I was looking into adding support for iSCSI (CLOUDSTACK-6109) and HA of guest 
> vms (CLOUDSTACK-6144) for hyper-v. I don’t think I’ll be able to finish it by 
> 14th.
>  

then it looks like you will have plenty of time to make these rock solid and 
well documented features for 4.5

> Regards,
> Devdeep
>  
>  
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Friday, February 28, 2014 7:40 PM
> To: 
> Subject: Re: 4.4 Feature Freeze
>  
> i’m all for being flexible, but i find a lot of the arguments used here 
> debatable.
>  
> “It causes developers to rush their development to meet the deadline." This 
> will happen anyway, every time we’ve extended the deadline we got new 
> features coming in at the last minute. Actually i’m under the impression that 
> when we move the deadline people will actually try to get more features in 
> instead of working on stabilizing existing features.
>  
> “We can’t deliver features on the roadmap.” There is validity to this point, 
> but on the other hand we already know the entire release schedule way ahead, 
> this feature freeze date should not come as a surprise. But as i mentioned in 
> an earlier mail, lets have this discussion. Post which features might not 
> make it into the release so we can have a discussion if we should slip the 
> release date to get this feature in. I think we all now that there are 
> commercial parties working with this software to build releases and have 
> customers demanding features, but if we don’t discuss that on list it’s hard 
> for us to take it into account.
>  
> “Feature freeze wasn’t called” True, i wasn’t even aware that this was a 
> requirement. We should add this to the procedure here 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so release 
> managers know this is expected of them. It should not impact the dates as the 
> dates are already fixed by the release schedule (every 4 months)
>  
>  
> I’m still -1 on extending the feature freeze. I would rather extend the 
> test/stability phase to we have some more time to fix issues before we get 
> into the RC spinning. 
>  
>  
> This is the list of current features targeted for 4.4 according to our Jira. 
> Which features would be impacted if we don’t move the feature freeze?
>  
> ASF JIRA
> Project: CloudStack
> Type: New Feature
> Fix Version: 4.4.0
> Resolution: Unresolved
> Sorted by: Updated descending
> 1–15 of 15 as at: 28/Feb/14 15:07
> TKey Summary Assignee  Reporter  P
>   Status  Resolution  Created  Updated  Due
>   CLOUDSTACK-6181   
> Root resize
> UnassignedNux  Open  Unresolved  27/Feb/14
> 27/Feb/14 
>   CLOUDSTACK-6161   
> distributed routing and network ACL with OVS plug-in
> Murali ReddyMurali Reddy   Open  Unresolved  
> 24/Feb/14   24/Feb/14 
>   CLOUDSTACK-6092   
> Storage OverProvisioning as a Per Primary Basis
> Saksham Srivastava   Saksham Srivastava Open  Unresolved  
> 13/Feb/14   20/Feb/14   
>   CLOUDSTACK-6144   
> HA for guest VMs running Hyper-V
> UnassignedRajesh Battala  Open  Unresolved  20/Feb/14 
>20/Feb/14 
>   CLOUDSTACK-6143   
> Storage Live-Migration support for Hyper-V
> UnassignedRajesh Battala  Open  Unresolved  20/Feb/14 
>20/Feb/14 
>   CLOUDSTACK-6142   
> Zone Wide Primary Store in Hyper-V
> UnassignedRajesh Battala  Open  Unresolved  20/Feb/14 
>20/Feb/14 
>   CLOUDSTACK-6104   
> PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
> Sateesh Chodapuneedi  Sateesh ChodapuneediOpen
>   Unresolved 14/Feb/14  15/Feb/14 
>   CLOUDSTACK-6109   
> Support of iSCSI as primary store in Hyper-V
> Rajesh Battala   Rajesh Battala  Open  Unresolved 
>  14/Feb/14   14/Feb/14 
>   CLOUDSTACK-6106   
> Support of VPC in HyperV
> Rajesh Battala   Rajesh Battala  Open  Unresolved 
>  14/Feb/14   14/Feb/14 
>   CLOUDSTACK-6090   
> Virtual Router Service Failure Alerting
> Harikrishna Patnala   Harikrishna Patnala  Open  
> Unresolved  13/Feb/14   13/Feb/14   
>   CLOUDSTACK-6052   
> List VM enhancement to support querying with multiple VM IDs
> Koushik Das  Koushik DasOpen  Unresolved  07/Feb/14   
>  07/Feb/14 
>   CLOUDSTACK-5569   
> enhance OVS plug-in to support region level VPC and guest networks that span 
> zones
> Murali ReddyMurali Red

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

[Alena Prokharchyk]

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

Re: Review Request 18689: CS-19420: [UI] Fixed invalid field name (label.dynamically.scalable) on instance details.

[Brian Federle]

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

Ship it!


Ship It!

- Brian Federle


On March 3, 2014, 4:27 p.m., Mihaela Stoica wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18689/
> ---
> 
> (Updated March 3, 2014, 4:27 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle and Jessica Wang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CS-19420: [UI] Fixed invalid field name (label.dynamically.scalable) on 
> instance details.
> 
> 
> Diffs
> -
> 
>   ui/dictionary.jsp bf48417 
> 
> Diff: https://reviews.apache.org/r/18689/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Mihaela Stoica
> 
>

Re: Review Request 18689: CS-19420: [UI] Fixed invalid field name (label.dynamically.scalable) on instance details.

[Brian Federle]

> On March 3, 2014, 6:07 p.m., Brian Federle wrote:
> > Ship It!

Also, note for next time: 'CS-19420' is an invalid bug ID. Please provide a bug 
that was created in the Apache JIRA. I created one for this and will ref the ID 
in the commit. Thanks.


- Brian


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


On March 3, 2014, 4:27 p.m., Mihaela Stoica wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18689/
> ---
> 
> (Updated March 3, 2014, 4:27 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle and Jessica Wang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CS-19420: [UI] Fixed invalid field name (label.dynamically.scalable) on 
> instance details.
> 
> 
> Diffs
> -
> 
>   ui/dictionary.jsp bf48417 
> 
> Diff: https://reviews.apache.org/r/18689/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Mihaela Stoica
> 
>

Re: Exception adding XenServer host to CS

[Mike Tutkowski]

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);
>>>
>>> }
>>>
>>>
>>> }
>>>
>>>
>>> Right before this code, the XenServer server resource tries to copy a
>>> bunch of files to the XenServer host, but several of these files cannot be
>>> found on the CS management server:
>>>
>>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>> cannot locate
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_firewall.sh
>>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>> cannot locate
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//bumpUpPriority.sh
>>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>> cannot locate
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//dhcp_entry.sh
>>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>> cannot locate
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_loadbalancer.sh
>>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>> cannot locate
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//save_password_to_domr.sh
>>> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>> cannot locate
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../vhd-util
>>>
>>> I know that vhd-util has to be manually copied to the CS MS, but what
>>> about the others?
>>>
>>>
>>> Thanks!
>>>
>>>
>>> On Fri, Feb 28, 2014 at 11:40 AM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
 Thanks, Kelven! Glad it's not just me. :)

 When I have a little free time this afternoon, I plan to look into this
 in more detail - unless, of course, a XenServer-focused developer already
 knows what's going on.


 On Fri, Feb 28, 2014 at 11:37 AM, Kelven Yang 
 wrote:

> I was also trying master this morning and ran into the same problem
>
> Kelven
>
> On 2/28/14, 10:19 AM, "Mike Tutkowski" 
> wrote:
>
> >Just curious if anyone else has been able to successfully add a
> XenServer
> >host to a newly created cloud on master recently?
> >
> >
> >On Thu, Feb 27, 2014 at 10:58 PM, Mike Tutkowski <
> >mike.tutkow...@solidfire.com> wrote:
> >
> >> I've tried this with a couple different XenServer 6.1 hosts...same
> >>results.
> >>
> >> One exception I noticed that was buried was at the top of the log
> (look
> >> familiar to anyone?):
> >>
> >> ERROR [c.c.a.ApiServer] (1182531138@qtp-1140222894-7:ctx-2111b24c
> >> ctx-e6ecb4c0) unhandled exception executing api command: addHost
> >> com.cloud.utils.exception.CloudRuntimeException: Cannot transit
> agent
> >> status with event AgentDisconnected for host 1, mangement server id
> is
> >> 52231564957,Unable to transition to a new state from Creating via
> >> AgentDisconnected
> >> at
> >>
>
>>

Re: Review Request 18695: Fix for CLOUDSTACK-4563: Initial zone wizard UI label issue

[Brian Federle]

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

Ship it!


Ship It!

- Brian Federle


On March 3, 2014, 4:44 p.m., Gabor Apati-Nagy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18695/
> ---
> 
> (Updated March 3, 2014, 4:44 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle and Jessica Wang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch fixes CLOUDSTACK-4563, so that the 'Provider' label  will use 
> localized text instead of wired-in 'Provider' text.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties f1c166b 
>   ui/dictionary.jsp 16ecbab 
>   ui/scripts/zoneWizard.js 13630c1 
> 
> Diff: https://reviews.apache.org/r/18695/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabor Apati-Nagy
> 
>

Re: Review Request 18695: Fix for CLOUDSTACK-4563: Initial zone wizard UI label issue

[ASF Subversion and Git Services]

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


Commit 477902379e0fad25a796ad3cbed53bec33737541 in cloudstack's branch 
refs/heads/master from Gabor Apati-Nagy
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4779023 ]

Fix CLOUDSTACK-4563: Initial zone wizard UI label issue


- ASF Subversion and Git Services


On March 3, 2014, 4:44 p.m., Gabor Apati-Nagy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18695/
> ---
> 
> (Updated March 3, 2014, 4:44 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle and Jessica Wang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch fixes CLOUDSTACK-4563, so that the 'Provider' label  will use 
> localized text instead of wired-in 'Provider' text.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties f1c166b 
>   ui/dictionary.jsp 16ecbab 
>   ui/scripts/zoneWizard.js 13630c1 
> 
> Diff: https://reviews.apache.org/r/18695/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabor Apati-Nagy
> 
>

Re: Exception adding XenServer host to CS

[Sheng Yang]

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

 }


 }


 Right before this code, the XenServer server resource tries to copy a
 bunch of files to the XenServer host, but several of these files cannot be
 found on the CS management server:

 WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
 cannot locate
 /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_firewall.sh
 WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
 cannot locate
 /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//bumpUpPriority.sh
 WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
 cannot locate
 /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//dhcp_entry.sh
 WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
 cannot locate
 /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_loadbalancer.sh
 WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
 cannot locate
 /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//save_password_to_domr.sh
 WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
 cannot locate
 /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../vhd-util

 I know that vhd-util has to be manually copied to the CS MS, but what
 about the others?


 Thanks!


 On Fri, Feb 28, 2014 at 11:40 AM, Mike Tutkowski <
 mike.tutkow...@solidfire.com> wrote:

> Thanks, Kelven! Glad it's not just me. :)
>
> When I have a little free time this afternoon, I plan to look into this
> in more detail - unless, of course, a XenServer-focused developer already
> knows what's going on.
>
>
> On Fri, Feb 28, 2014 at 11:37 AM, Kelven Yang 
> wrote:
>
>> I was also trying master this morning and ran into the same problem
>>
>> Kelven
>>
>> On 2/28/14, 10:19 AM, "Mike Tutkowski" 
>> wrote:
>>
>> >Just curious if anyone else has been able to successfully add a
>> XenServer
>> >host to a newly created cloud on master recently?
>> >
>> >
>> >On Thu, Feb 27, 2014 at 10:58 PM, Mike Tutkowski <
>> >mike.tutkow...@solidfire.com> wrote:
>> >
>> >> I've tried this with a couple different XenServer 6.1 h

overridden compute offerings in deployVirtualMachine

[Marcus]

I came across this code in 4.4 recently:

commit e5cfe948186b825d2b28c99ce2915a5ca8498aff
Author: Bharat Kumar 
Date:   Thu Nov 28 12:34:16 2013 +0530

CLOUDSTACK-5160 add a map to specify the custom compute parameters
in the deployvm api.

Signed-off-by: Jayapal 

It looks like you can set certain details to override the compute
offering in deployVirtualMachine. Since these aren't specific API
parameters, however, how are the supported items documented?


-@Parameter(name = ApiConstants.CPU_SPEED,
-   type = CommandType.INTEGER,
-   since = "4.3",
-   description = "optional field to specify the cpu speed
when using dynamic compute offering.")
-private Integer cpuSpeed;
-
-@Parameter(name = ApiConstants.MEMORY,
-   type = CommandType.INTEGER,
-   since = "4.3",
-   description = "optional field to specify the memory
when using dynamic compute offering")
-private Integer memory;
-
-@Parameter(name = ApiConstants.CPU_NUMBER,
-   type = CommandType.INTEGER,
-   since = "4.3",
-   description = "optional field to specify the number of
cpu cores when using dynamic offering.")
-private Integer cpuNumber;
-
-@Parameter(name = ApiConstants.ROOT_DISK_SIZE,
-   type = CommandType.LONG,
-   since = "4.3",
-   description = "optional field to specify the number of
cpu cores when using dynamic offering.")
-private Long rootdisksize;
+@Parameter(name = ApiConstants.CUSTOM_PARAMETERS,
+   type = CommandType.MAP,
+   since= "4.3",
+   description = "used to specify the custom parameters.")
+private  Map customParameters;

Re: Exception adding XenServer host to CS

[Mike Tutkowski]

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);
> 
>  }
> 
> 
>  }
> 
> 
>  Right before this code, the XenServer server resource tries to copy a
>  bunch of files to the XenServer host, but several of these files
> cannot be
>  found on the CS management server:
> 
>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>  cannot locate
> 
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_firewall.sh
>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>  cannot locate
> 
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//bumpUpPriority.sh
>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>  cannot locate
> 
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//dhcp_entry.sh
>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>  cannot locate
> 
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_loadbalancer.sh
>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>  cannot locate
> 
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//save_password_to_domr.sh
>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>  cannot locate
> 
> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../vhd-util
> 
>  I know that vhd-util has to be manually copied to the CS MS, but what
>  about the others?
> 
> 
>  Thanks!
> 
> 
>  On Fri, Feb 28, 2014 at 11:40 AM, Mike Tutkowski <
>  mike.tutkow...@solidfire.com> wrote:
> 
> > Thanks, Kelven! Glad it's not just me. :)
> >
> > When I have a little free time this afternoon, I plan to look into
> this
> > in more detail - unless, of course, a XenServer-focused developer
> already
> > knows what's going on.
> >
> >
> > On Fri, Feb 28, 2014 at 11:37 AM, Kelven Yang <
> kelven.y...@citrix.com>wrote:
> >
> >> I was also trying master this morning and ran into the same problem
> >>
> >> Kelven
> >>
> >> On 2/28/14, 10:19 AM, "Mike Tutkowski" <
> mike

RE: Removing TAGS

[Alex Huang]

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

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

[Antonio Fornié Casarrubios]

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 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 get method is invoked) and mainly the fact that these get methods that
> >fix the map on the fly are copies of each other: instead of fixing the
> >structure in one method, the are plenty of methods almost identical
> >copying
> >and pasting the same lines. Some times the same method twice in the same
> >cmd class for two Map params (look CreateNetworkOfferingCmd
> >#getServiceCapabilities and #getServiceProviders).
> >
> >2- params in which the get method returns the map as it is. With the
> >strange format. For example,
> >Cloudmonkey command
> >create networkoffering ... tags[0].key="City" tags[0].value="Toronto"
> >
> >You store in the table network_offeringstags, field tags, the String:
> >{0={value=Toronto,key=City}}
> >(including brackets and all)
> >
> >So knowing all this I guess you agree this should be refactored... unless
> >at some point the strange format is needed. But after looking for it
> >everywhere I didn't find any place where it was. I already did the change
> >and tested most of the cases and it all seems to work.
> >
> >
> >It would be great if once I upload the patch somebody could help me double
> >check that it doesn't brake anything, not only reviewing to code. I did
> >plenty of tests of many kinds, but I cannot be sure that I am covering
> >enough. Further, there seem to be several places where the code expects
> >the
> >strange format.
> >->ConfigurationManagerImpl line 1545
> >
> >
> >Thanks. Cheers
> >Antonio
> >
> >
> >2014-02-28 18:44 GMT+01:00 Alena Prokharchyk
> >:
> >
> >>
> >>
> >>   From: Antonio Fornié Casarrubios 
> >> Date: Friday, February 28, 2014 at 2:09 AM
> >> To: Rohit Yadav , cloudstack <
> >> dev@cloudstack.apache.org>, Alena Prokharchyk <
> >> alena.prokharc...@citrix.com>
> >> Subject: Re: [PROPOSAL][QUESTION] Map parameters in API Commands
> >>
> >>   Hi Alena,
> >>
> >>  I would like to know your opinion on this change. Mainly consists on:
> >> 1- Change the way we store the Map params after unpackParams in order to
> >> have, for each Map param, a Map instead of Map >> Map>.
> >>
> >>
> >>  -Antonio, what was the reason for storing the parameter in the old
> >> format to begin with? Where there any case where we actually needed a
> >>map
> >> of map parameters?
> >>
> >>
> >
> >>
> >>  2- There are many commands that fix this strange format on demand on
> >> their getters, so they do the conversion there. Since I already have the
> >> final format I replace these getters with just
> >> getTags(){ return this.tags;}
> >>
> >>  3- Persistence of these Map params. This last change is more tricky and
> >> error-prone but the previous two would brake the functionality without
> >>it.
> >> Actually it doesn't seem that I should change this for all the cases,
> >>given
> >> that for some commands the current behavior is storing in the DB the
> >>Map as
> >> it comes, so after the change it will just do the same and thus
> >>retrieve it
> >> with the right format. So, although in the tables we move from
> >> --
> >> key | City
> >> --
> >> value | The Hague
> >> --
> >>
> >>  to
> >> --
> >> City | The Hague
> >> --
> >>
> >>  then in memory, after DB read, we will just have the proper format
> >>again
> >> (Map). Is that right?
> >>
> >>
> >>
> >>- in what table do you see key name being a field name? I've looked
> >>at
> >>various *_details tables, as well as resource_tag table, everywhere
> >>we have

RE: 4.4 Feature Freeze

[Prachi Damle]

Hugo,

Just wanted to inform that myself and Min had proposed 
https://issues.apache.org/jira/browse/CLOUDSTACK-5920
which was not listed below due to wrong ticket type it had.

I updated the type and now it should show in your list.

Thanks,
Prachi


From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Friday, February 28, 2014 6:10 AM
To: 
Subject: Re: 4.4 Feature Freeze

i'm all for being flexible, but i find a lot of the arguments used here 
debatable.

"It causes developers to rush their development to meet the deadline." This 
will happen anyway, every time we've extended the deadline we got new features 
coming in at the last minute. Actually i'm under the impression that when we 
move the deadline people will actually try to get more features in instead of 
working on stabilizing existing features.

"We can't deliver features on the roadmap." There is validity to this point, 
but on the other hand we already know the entire release schedule way ahead, 
this feature freeze date should not come as a surprise. But as i mentioned in 
an earlier mail, lets have this discussion. Post which features might not make 
it into the release so we can have a discussion if we should slip the release 
date to get this feature in. I think we all now that there are commercial 
parties working with this software to build releases and have customers 
demanding features, but if we don't discuss that on list it's hard for us to 
take it into account.

"Feature freeze wasn't called" True, i wasn't even aware that this was a 
requirement. We should add this to the procedure here 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so release 
managers know this is expected of them. It should not impact the dates as the 
dates are already fixed by the release schedule (every 4 months)


I'm still -1 on extending the feature freeze. I would rather extend the 
test/stability phase to we have some more time to fix issues before we get into 
the RC spinning.


This is the list of current features targeted for 4.4 according to our Jira. 
Which features would be impacted if we don't move the feature freeze?

ASF JIRA
Project: CloudStack
Type: New Feature
Fix Version: 4.4.0
Resolution: Unresolved
Sorted by: Updated descending
1-15 of 15 as at: 28/Feb/14 15:07
T  Key Summary Assignee  Reporter  P
  Status  Resolution   Created   UpdatedDue
[New Feature]CLOUDSTACK-6181
Root resize
Unassigned Nux [Major] [Open]  Open  Unresolved  
27/Feb/1427/Feb/14
[New Feature]CLOUDSTACK-6161
distributed routing and network ACL with OVS plug-in
Murali Reddy  Murali Reddy  [Major] [Open]  Open  Unresolved
  24/Feb/1424/Feb/14
[New Feature]CLOUDSTACK-6092
Storage OverProvisioning as a Per Primary Basis
Saksham SrivastavaSaksham Srivastava[Major] [Open]  Open
  Unresolved  13/Feb/1420/Feb/14
[New Feature]CLOUDSTACK-6144
HA for guest VMs running Hyper-V
Unassigned Rajesh Battala [Major] [Open]  Open  Unresolved  
20/Feb/1420/Feb/14
[New Feature]CLOUDSTACK-6143
Storage Live-Migration support for Hyper-V
Unassigned Rajesh Battala [Major] [Open]  Open  Unresolved  
20/Feb/1420/Feb/14
[New Feature]CLOUDSTACK-6142
Zone Wide Primary Store in Hyper-V
Unassigned Rajesh Battala [Major] [Open]  Open  Unresolved  
20/Feb/1420/Feb/14
[New Feature]CLOUDSTACK-6104
PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
Sateesh Chodapuneedi   Sateesh Chodapuneedi   [Major] 
[Open]  Open  Unresolved  14/Feb/1415/Feb/14
[New Feature]CLOUDSTACK-6109
Support of iSCSI as primary store in Hyper-V
Rajesh Battala Rajesh Battala [Major] [Open]  Open  Unresolved  
14/Feb/1414/Feb/14
[New Feature]CLOUDSTACK-6106
Support of VPC in HyperV
Rajesh Battala Rajesh Battala [Major] [Open]  Open  Unresolved  
14/Feb/1414/Feb/14
[New Feature]CLOUDSTACK-6090
Virtual Router Service Failure Alerting
Harikrishna Patnala Harikrishna Patnala [Major] [Open]  Open
  Unresolved  13/Feb/1413/Feb/14
[New Feature]CLOUDSTACK-6052
List VM enhancement to support querying with multiple VM IDs
Koushik Das   Koushik Das   [Major] [Open]  Open  Unresolved
  07/Feb/1407/Feb/14
[New Feature]CLOUDSTACK-5569
enhance OVS plug-in to support region level VPC and guest networks that span 
zones
Murali Reddy  Murali Reddy  [Major] [Open]  Open  Unresolved
  19/Dec/1319/Dec/13
[New Feature]CLOUDSTACK-5568
introduce notion of guest network that spans multiple zones
Murali Reddy  Murali Reddy  [Major]   

[PROPOSAL] Use XS HA to swithc XS master host when master host is down

[Anthony Xu]

Hi All,
I would like to propose using XS HA to switch XS master host when XS master 
host is down

Reason,
We found below issue recently,
https://issues.apache.org/jira/browse/CLOUDSTACK-6177

When XS master is down, CS uses pool-emergency-transition-to-master and 
pool-recover-slaves API to choose a new master, this API is not safe, and 
should be only used in emergent situation, this API may cause XS use a little 
bit old(5 seconds old) version of XS DB, some of object may be missing in the 
old XS DB, which may cause weird behavior, you may not be able to start VM.


Short term solution

CS doesn't do XS master switch any more to avoid this issue.

Impact,

1.  When master host is down, CS loses connect to the whole XS pool(CS 
cluster), CS cannot get VMs info in this cluster, and the whole cluster is not 
operable.

2.  Require admin to recover the XS master host manually, if recovering XS 
master host is not possible, admin can use uses 
pool-emergency-transition-to-master and pool-recover-slaves to recover the 
pool, per the issue I mentioned before , this should be the last resort.

Long term solution

Integrate XS HA, use XS HA to do XS master switch.

1.  It might take  some time to integrate XS HA.

2.  Old free version XS doesn't have XS HA feature, user might need to 
upgrade to XS 6.2( which is free) to get the feature.


I think we can fix this issue in two steps.

1.  Since this issue is very critical, CS should not  do XS master switch 
immediately to avoid this issue.

2.  Integrate XS HA.


Comments, suggestions are highly appreciated!

Best Regards.
Anthony

Re: Exception adding XenServer host to CS

[Mike Tutkowski]

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);
>> 
>>  }
>> 
>> 
>>  }
>> 
>> 
>>  Right before this code, the XenServer server resource tries to copy a
>>  bunch of files to the XenServer host, but several of these files
>> cannot be
>>  found on the CS management server:
>> 
>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>  cannot locate
>> 
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_firewall.sh
>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>  cannot locate
>> 
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//bumpUpPriority.sh
>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>  cannot locate
>> 
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//dhcp_entry.sh
>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>  cannot locate
>> 
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_loadbalancer.sh
>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>  cannot locate
>> 
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//save_password_to_domr.sh
>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>  cannot locate
>> 
>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../vhd-util
>> 
>>  I know that vhd-util has to be manually copied to the CS MS, but what
>>  about the others?
>> 
>> 
>>  Thanks!
>> 
>> 
>>  On Fri, Feb 28, 2014 at 11:40 AM, Mike Tutkowski <
>>  mike.tutkow...@solidfire.com> wrote:
>> 
>> > Thanks, Kelven! Glad it's not just me. :)
>> >
>> > When I have a little free time this afternoon, I plan

Re: Exception adding XenServer host to CS

[Mike Tutkowski]

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);
>>> 
>>>  }
>>> 
>>> 
>>>  }
>>> 
>>> 
>>>  Right before this code, the XenServer server resource tries to copy
>>> a
>>>  bunch of files to the XenServer host, but several of these files
>>> cannot be
>>>  found on the CS management server:
>>> 
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>>  cannot locate
>>> 
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_firewall.sh
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>>  cannot locate
>>> 
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//bumpUpPriority.sh
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>>  cannot locate
>>> 
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//dhcp_entry.sh
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>>  cannot locate
>>> 
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//call_loadbalancer.sh
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>>  cannot locate
>>> 
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../../../../network/domr//save_password_to_domr.sh
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-33a9d930) We
>>>  cannot locate
>>> 
>>> /home/m

Re: KVM

[María Noelia Gil]

Sorry, I have enabled the debug mode. Then I show a message that I found 
interesting: 

2014-03-03 20:24:07,979 DEBUG [kvm.resource.LibvirtComputingResource] 
(main:null) failing to get physical interface from bridge virbr0, did not find 
an eth*, bond*, vlan*, em*, or p*p* in /sys/devices/virtual/net/virbr0/brif

And at the end of the log file shows the following:

2014-03-03 20:24:08,968 DEBUG [cloud.agent.Agent] (Agent-Handler-1:null) 
Startup task created
2014-03-03 20:24:09,051 DEBUG [cloud.agent.Agent] (Agent-Handler-2:null) 
Received response: Seq 0-0:  { Ans: , MgmtId: 268749063393642, via: -1, Ver: 
v1, Flags: 10, 
[{"com.cloud.agent.api.StartupAnswer":{"hostId":0,"pingInterval":60,"result":true,"wait":0}}]
 }
2014-03-03 20:24:09,052 DEBUG [cloud.agent.Agent] (Agent-Handler-2:null) 
Startup task cancelled
2014-03-03 20:24:09,052 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) 
Proccess agent startup answer, agent id = 0
2014-03-03 20:24:09,052 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) Set 
agent id 0
2014-03-03 20:24:09,062 DEBUG [cloud.agent.Agent] (Agent-Handler-2:null) Adding 
a watch list
2014-03-03 20:24:09,062 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) 
Startup Response Received: agent id = 0
2014-03-03 20:24:09,063 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) 
Request:Seq -1--1:  { Cmd , MgmtId: -1, via: -1, Ver: v1, Flags: 111, 
[{"com.cloud.agent.api.ReadyCommand":{"_details":"java.lang.IllegalArgumentException:
 Host ***.***.***.*** sent incorrect data center: default","wait":0}}] }
2014-03-03 20:24:09,064 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) 
Processing command: com.cloud.agent.api.ReadyCommand
2014-03-03 20:24:09,064 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) 
Not ready to connect to mgt server: java.lang.IllegalArgumentException: Host 
***.***.***.*** sent incorrect data center: default
2014-03-03 20:24:09,064 INFO  [cloud.agent.Agent] (AgentShutdownThread:null) 
Stopping the agent: Reason = sig.kill
2014-03-03 20:24:09,065 DEBUG [cloud.agent.Agent] (AgentShutdownThread:null) 
Sending shutdown to management server
2014-03-03 20:24:09,065 DEBUG [kvm.resource.LibvirtComputingResource] 
(UgentTask-1:null) Executing: 
/usr/share/cloudstack-common/scripts/vm/network/security_group.py 
get_rule_logs_for_vms 
2014-03-03 20:24:09,149 DEBUG [kvm.resource.LibvirtComputingResource] 
(UgentTask-1:null) Execution is successful.
2014-03-03 20:24:09,151 DEBUG [cloud.agent.Agent] (UgentTask-1:null) Sending 
ping: Seq 0-1:  { Cmd , MgmtId: -1, via: 0, Ver: v1, Flags: 11, 
[{"com.cloud.agent.api.PingRoutingWithNwGroupsCommand":{"newGroupStates":{},"newStates":{},"_gatewayAccessible":true,"_vnetAccessible":true,"hostType":"Routing","hostId":0,"wait":0}}]
 }

Thanks.

El 03/03/2014, a las 01:09, Marcus  escribió:

> It doesn't look like you've enabled debug, you're only getting WARN
> and INFO messages. Please enable debug.
> 
> On Sun, Mar 2, 2014 at 4:40 PM, María Noelia Gil  
> wrote:
>> When I run "CloudStack-setup-agent" shows the following:
>> 
>> Starting to configure your system:
>> Configure Apparmor ...[OK]
>> Configure Network ... [OK]
>> Configure Libvirt ...
>> [OK]
>> Configure Firewall ...
>> [OK]
>> Configure Nfs ... [OK]
>> Configure cloudAgent ...
>> [OK]
>> CloudStack Agent setup is done!
>> 
>> The log file displays the following.
>> 
>> 2014-03-03 00:32:44,320 INFO  [cloud.agent.AgentShell] (main:null) Agent 
>> started
>> 2014-03-03 00:32:44,321 INFO  [cloud.agent.AgentShell] (main:null) 
>> Implementation Version is 4.2.1
>> 2014-03-03 00:32:44,322 INFO  [cloud.agent.AgentShell] (main:null) 
>> agent.properties found at /etc/cloudstack/agent/agent.properties
>> 2014-03-03 00:32:44,323 INFO  [cloud.agent.AgentShell] (main:null) 
>> Defaulting to using properties file for storage
>> 2014-03-03 00:32:44,324 INFO  [cloud.agent.AgentShell] (main:null) 
>> Defaulting to the constant time backoff algorithm
>> 2014-03-03 00:32:44,326 INFO  [cloud.utils.LogUtils] (main:null) log4j 
>> configuration found at /etc/cloudstack/agent/log4j-cloud.xml
>> 2014-03-03 00:32:44,384 INFO  [cloud.agent.Agent] (main:null) id is 0
>> 2014-03-03 00:32:44,396 INFO  
>> [resource.virtualnetwork.VirtualRoutingResource] (main:null) 
>> VirtualRoutingResource _scriptDir to use: scripts/network/domr/kvm
>> 2014-03-03 00:32:45,020 WARN  [kvm.resource.LibvirtComputingResource] 
>> (main:null) LibVirt version 0.9.10 required for guest cpu mode, but version 
>> 0.9.8 detected, so it will be disabled
>> 2014-03-03 00:32:45,114 INFO  [kvm.resource.LibvirtComputingResource] 
>> (main:null) No libvirt.vif.driver specified. Defaults to BridgeVifDriver.
>> 2014-03-03 00:32:45,145 INFO  [cloud.agent.Agent] (main:null) Agent [id = 0 
>> : type = LibvirtComputingResource : zone = default : pod = default : workers 
>> = 5 : host = localhost : port = 8250
>> 2014-03-03 00:32:45,154 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
>> Con

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

[Alena Prokharchyk]

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


We should revert this fix if it was already committed to the repo. Response 
name format breaks API compatibility.

- Alena Prokharchyk


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

[PROPOSAL] Ability to add new guest OS

[Amogh Vasekar]

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

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/#review36029
---


Commit fd43cf151663c48fe29f97323490d53a7c0f9d5b in cloudstack's branch 
refs/heads/master from Alena Prokharchyk
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fd43cf1 ]

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

This reverts commit ebcaec8632dbd92c071317f3190915244a287afb.
Reverting as it breaks API compatibility


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

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

[Marcus]

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 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 get method is invoked) and mainly the fact that these get methods that
>> >fix the map on the fly are copies of each other: instead of fixing the
>> >structure in one method, the are plenty of methods almost identical
>> >copying
>> >and pasting the same lines. Some times the same method twice in the same
>> >cmd class for two Map params (look CreateNetworkOfferingCmd
>> >#getServiceCapabilities and #getServiceProviders).
>> >
>> >2- params in which the get method returns the map as it is. With the
>> >strange format. For example,
>> >Cloudmonkey command
>> >create networkoffering ... tags[0].key="City" tags[0].value="Toronto"
>> >
>> >You store in the table network_offeringstags, field tags, the String:
>> >{0={value=Toronto,key=City}}
>> >(including brackets and all)
>> >
>> >So knowing all this I guess you agree this should be refactored... unless
>> >at some point the strange format is needed. But after looking for it
>> >everywhere I didn't find any place where it was. I already did the change
>> >and tested most of the cases and it all seems to work.
>> >
>> >
>> >It would be great if once I upload the patch somebody could help me double
>> >check that it doesn't brake anything, not only reviewing to code. I did
>> >plenty of tests of many kinds, but I cannot be sure that I am covering
>> >enough. Further, there seem to be several places where the code expects
>> >the
>> >strange format.
>> >->ConfigurationManagerImpl line 1545
>> >
>> >
>> >Thanks. Cheers
>> >Antonio
>> >
>> >
>> >2014-02-28 18:44 GMT+01:00 Alena Prokharchyk
>> >:
>> >
>> >>
>> >>
>> >>   From: Antonio Fornié Casarrubios 
>> >> Date: Friday, February 28, 2014 at 2:09 AM
>> >> To: Rohit Yadav , cloudstack <
>> >> dev@cloudstack.apache.org>, Alena Prokharchyk <
>> >> alena.prokharc...@citrix.com>
>> >> Subject: Re: [PROPOSAL][QUESTION] Map parameters in API Commands
>> >>
>> >>   Hi Alena,
>> >>
>> >>  I would like to know your opinion on this change. Mainly consists on:
>> >> 1- Change the way we store the Map params after unpackParams in order to
>> >> have, for each Map param, a Map instead of Map> >> Map>.
>> >>
>> >>
>> >>  -Antonio, what was the reason for storing the parameter in the old
>> >> format to begin with? Where there any case where we actually needed a
>> >>map
>> >> of map parameters?
>> >>
>> >>
>> >
>> >>
>> >>  2- There are many c

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

[Alena Prokharchyk]

Adding Bharat to the thread as he was the one who introduced the details
param to the deployVm call.

Bharat, why did you pick this format for storing the vm details? Were you
following the rules from some other calls? If so, what those calls are?

-Alena.

On 3/3/14, 1:00 PM, "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 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 get method is invoked) and mainly the fact that these get methods
>>>that
>>> >fix the map on the fly are copies of each other: instead of fixing the
>>> >structure in one method, the are plenty of methods almost identical
>>> >copying
>>> >and pasting the same lines. Some times the same method twice in the
>>>same
>>> >cmd class for two Map params (look CreateNetworkOfferingCmd
>>> >#getServiceCapabilities and #getServiceProviders).
>>> >
>>> >2- params in which the get method returns the map as it is. With the
>>> >strange format. For example,
>>> >Cloudmonkey command
>>> >create networkoffering ... tags[0].key="City" tags[0].value="Toronto"
>>> >
>>> >You store in the table network_offeringstags, field tags, the String:
>>> >{0={value=Toronto,key=City}}
>>> >(including brackets and all)
>>> >
>>> >So knowing all this I guess you agree this should be refactored...
>>>unless
>>> >at some point the strange format is needed. But after looking for it
>>> >everywhere I didn't find any place where it was. I already did the
>>>change
>>> >and tested most of the cases and it all seems to work.
>>> >
>>> >
>>> >It would be great if once I upload the patch somebody could help me
>>>double
>>> >check that it doesn't brake anything, not only reviewing to code. I
>>>did
>>> >plenty of tests of many kinds, but I cannot be sure that I am covering
>>> >enough. Further, there seem to be several places where the code
>>>expects
>>> >the
>>> >strange format.
>>> >->ConfigurationManagerImpl line 1545
>>> >
>>> >
>>> >Thanks. Cheers
>>> >Antonio
>>> >
>>> >
>>> >2014-02-28 18:44 GMT+01:00 Alena Prokharchyk
>>> >:
>>> >
>>> >>
>>> >>
>>> >>   From: Antonio Fornié Casarrubios 
>>> >> Date: Friday, February 28, 2014 at 2:09 AM
>>> >> To: Rohit Yadav , cloudstack <
>>> >> dev@cloudstack.apache.org>, Alena Prokharchyk <
>>> >> alena.prokharc...@citrix.com>
>>> >> Subject: Re: [PROPOSAL][QUESTION] Map parameters in API Commands
>>> >>
>>> >>   Hi Alena,
>>> >>
>>> >>

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

[Marcus]

FYI I was working on implementing the rootdisksize detail when I ran
into this. The parameter is detected and works fine if I do
'details[0].rootdisksize=2', but this is a special one since its not
persisted in the db, it's only used when allocating the root volume
and then stripped off of the details before they're persisted. That
led me to run further testing and came up with the above.

On Mon, Mar 3, 2014 at 2:06 PM, Alena Prokharchyk
 wrote:
> Adding Bharat to the thread as he was the one who introduced the details
> param to the deployVm call.
>
> Bharat, why did you pick this format for storing the vm details? Were you
> following the rules from some other calls? If so, what those calls are?
>
> -Alena.
>
> On 3/3/14, 1:00 PM, "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 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 get method is invoked) and mainly the fact that these get methods
that
 >fix the map on the fly are copies of each other: instead of fixing the
 >structure in one method, the are plenty of methods almost identical
 >copying
 >and pasting the same lines. Some times the same method twice in the
same
 >cmd class for two Map params (look CreateNetworkOfferingCmd
 >#getServiceCapabilities and #getServiceProviders).
 >
 >2- params in which the get method returns the map as it is. With the
 >strange format. For example,
 >Cloudmonkey command
 >create networkoffering ... tags[0].key="City" tags[0].value="Toronto"
 >
 >You store in the table network_offeringstags, field tags, the String:
 >{0={value=Toronto,key=City}}
 >(including brackets and all)
 >
 >So knowing all this I guess you agree this should be refactored...
unless
 >at some point the strange format is needed. But after looking for it
 >everywhere I didn't find any place where it was. I already did the
change
 >and tested most of the cases and it all seems to work.
 >
 >
 >It would be great if once I upload the patch somebody could help me
double
 >check that it doesn't brake anything, not only reviewing to code. I
did
 >plenty of tests of many kinds, but I cannot be sure that I am covering
 >enough. Further, there seem to be se

master branch DbUtilTest failure

[Prachi Damle]

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?


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\target 
(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\target\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\target\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\target\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.TransactionLegacy
  closeStatementFail(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  closeStatementFail(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  closeResultSet(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  closeResultSet(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  getGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  getGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  closeResultSetFail(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  closeResultSetFail(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  releaseGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  releaseGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  closeNull(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  closeNull(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  closeConnection(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  closeConnection(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  getGlobalLockTimeout(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
  getGlobalLockTimeout(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud

RE: Exception adding XenServer host to CS

[Anthony Xu]

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);
>>> 
>>>  }
>>> 
>>> 
>>>  }
>>> 
>>> 
>>>  Right before this code, the XenServer server resource tries to 
>>>  copy
>>> a
>>>  bunch of files to the XenServer host, but several of these 
>>>  files
>>> cannot be
>>>  found on the CS management server:
>>> 
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] 
>>>  (DirectAgent-1:ctx-33a9d930) We cannot locate
>>> 
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/c
>>> lasses/scripts/vm/hypervisor/xenserver/xenserver60/../../../../netwo
>>> rk/domr//call_firewall.sh
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] 
>>>  (DirectAgent-1:ctx-33a9d930) We cannot locate
>>> 
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/c
>>> lasses/scripts/vm/hypervisor/xenserver/xenserver60/../../../../netwo
>>> rk/domr//bumpUpPriority.sh
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] 
>>>  (DirectAgent-1:ctx-33a9d930) We cannot locate
>>> 
>>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/c
>>> lasses/scripts/vm/hypervisor/xenserver/xenserver60/../../../../netwo
>>> rk/domr//dhcp_entry.sh
>>>  WARN  [c.c.h.x.r.CitrixResourceBase] 
>>>  (DirectAgent-1:ctx-33a9d930) We cannot locate
>>> 
>>> /home/mtutkowski/CloudStack/client/target/generated-we

Re: Exception adding XenServer host to CS

[Mike Tutkowski]

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);
> >>> 
> >>>  }
> >>> 
> >>> 
> >>>  }
> >>> 
> >>> 
> >>>  Right before this code, the XenServer server resource tries to
> >>>  copy
> >>> a
> >>>  bunch of files to the XenServer host, but several of these
> >>>  files
> >>> cannot be
> >>>  found on the CS management server:
> >>> 
> >>>  WARN  [c.c.h.x.r.CitrixResourceBase]
> >>>  (DirectAgent-1:ctx-33a9d930) We cannot locate
> >>> 
> >>> /home/mtutkowski/CloudStack/client/target/generated-webapp/WEB-INF/c
> >>> lasses/scripts/vm/hypervisor/xenserver/xenserver60/../../../../netwo
> >>> rk/domr//call_firewall.sh
> >>>  WARN  [c.c.h.x.r.CitrixResou

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

[Antonio Fornié Casarrubios]

I think that would have been a more correct format from the very beginning
details[0].rootdisksize=2
but right now it is no good, since we should keep them congruent, so it
should be
details[0].key=rootdisksize
details[0].value=2
right? I mean how to pass a map in a request should be always the same.

When the params are parsed from the request in order to set the values into
the fields, nothing is actually checking the tokens "key"  and "value",
just the format bla[0].a=b

But something else that is very strange is that, although in all the Map
parameters we put the data in this strange format, then the
getDetails/getBla methods, some of them convert it to a Map
(there are actually two types of code for this, copied and pasted along
dozens of methods) while others just return it as it is (so the client'd
better know it is getting that format).

So I am concerned about this, because if I apply this change, then all the
getters will return a Map and any client relying on a Map
of Maps will now fail. My change would affect all, because instead of
repeating the code I will just do it once in the unpackParams method.

About the DB, I remembered also the strange format, but after Alena's mail
I couldn't find any example so I assumed I was wrong. But I think we have
at least three ways of storing this:

First:
| key | City |
| value | London |

Second:
| City | London |

And third (ie network_offeringstags.tags)
| {0={value=London,key=City}} |
(in a single table cell)

And BTW, in the example that I found of the First way, it DID read both
rows back in one Map of Maps correctly.


One more thing, can I assume then all the params are coming in the format
details[0].key=rootdisksize
details[0].value=2

Because I want to base the parse in regex (instead of manual parsing like
now) and so far I am using these Patterns
protected static final String MAP_KEY_PATTERN_EXPRESSION =
"^([^\\[^\\]]+)\\[(\\d+)\\]\\.key$";
protected static final String MAP_VALUE_PATTERN_EXPRESSION =
"^[^\\[^\\]]+\\[\\d+\\]\\.value$";
Which is good if we want to verify the "key" and "value" tokens, but it
would fail with the other format you mentioned.

Thanks. Cheers
Antonio



2014-03-03 22:50 GMT+01:00 Marcus :

> FYI I was working on implementing the rootdisksize detail when I ran
> into this. The parameter is detected and works fine if I do
> 'details[0].rootdisksize=2', but this is a special one since its not
> persisted in the db, it's only used when allocating the root volume
> and then stripped off of the details before they're persisted. That
> led me to run further testing and came up with the above.
>
> On Mon, Mar 3, 2014 at 2:06 PM, Alena Prokharchyk
>  wrote:
> > Adding Bharat to the thread as he was the one who introduced the details
> > param to the deployVm call.
> >
> > Bharat, why did you pick this format for storing the vm details? Were you
> > following the rules from some other calls? If so, what those calls are?
> >
> > -Alena.
> >
> > On 3/3/14, 1:00 PM, "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é

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

[Alena Prokharchyk]

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


Dario, the patch fails to apply on the latest master, again some issue with 
AutoScaleManagerImpl. Should be a quick fix from your side?

Applying: Dispatcher corrections, refactoring and tests.
error: patch failed: 
server/src/com/cloud/network/as/AutoScaleManagerImpl.java:448
error: server/src/com/cloud/network/as/AutoScaleManagerImpl.java: patch does 
not apply
Patch failed at 0001 Dispatcher corrections, refactoring and tests.

- Alena Prokharchyk


On March 3, 2014, 9:01 a.m., Antonio Fornie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17888/
> ---
> 
> (Updated March 3, 2014, 9:01 a.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Dispatcher corrections, refactoring and tests. Corrects problems from 
> previous attempts that were reverted by Alena. Most of the changes are the 
> same, but this one is not creating conflicts of Map types for Aync Commands 
> or for parameters as Lists or Maps.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
>   api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
>   api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
>   api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java 
> 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 ff2b2ea 
>   server/src/com/cloud/storage/snapshot/SnapshotSchedulerImpl.java 183a13a 
>   server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
>   server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/17888/diff/
> 
> 
> Testing
> ---
> 
> Full build and test plus manually testing many features. Also including 
> CreateTagsCommand that failed in previous commit.
> 
> All unit and integration tests.
> 
> Test CS Web UI with the browser going through several use cases.
> 
> Also use the CS API by sending HTTP requests generated manually including 
> requests for Async Commands with Map parameters and during these tests apart 
> fromtesting correct functionality I also debugged to check that Maps created 
> correctly where they should but also that in the cases where the async 
> command must be persisted and later on retrieved and deserialized by gson 
> everything works ok and does what and where is expected. An example based on 
> the comment by Alena:
> http://localhost:8096/client/api?command=createTags&resourceids=ids&resourcetype=type&tags[0].key=region&tags[0].value=canada
> Also other examples like
> http://localhost:8096/client/api?command=createSecondaryStagingStore&url=httpbla&details[0].key=region&details[0].value=canada&details[1].key=element&details[1].value=fire
> 
> 
> Thanks,
> 
> Antonio Fornie
> 
>

Re: master branch DbUtilTest failure

[Wido den Hollander]

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\target 
(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\target\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\target\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\target\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.TransactionLegacy
   closeStatementFail(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   closeStatementFail(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   closeResultSet(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   closeResultSet(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   getGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   getGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   closeResultSetFail(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   closeResultSetFail(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   releaseGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   releaseGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   closeNull(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   closeNull(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   closeConnection(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   closeConnection(com.cloud.utils.DbUtilTest): Could not initialize class 
com.cloud.utils.db.TransactionLegacy
   getGlobalLockTimeout(com.clou

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

[Antonio Fornie]

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

(Updated March 3, 2014, 11:26 p.m.)


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


Changes
---

Resolved conflicts with latest master


Repository: cloudstack-git


Description
---

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


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
  api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
  api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
  api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java 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/storage/snapshot/SnapshotSchedulerImpl.java 183a13a 
  server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
  server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
PRE-CREATION 

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


Testing
---

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

All unit and integration tests.

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

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


Thanks,

Antonio Fornie

Noteworthy change to setting up XenServer :)

[Mike Tutkowski]

Hi everyone,

I spent the past day or so trying to figure out with various builds why I
could not add a XenServer host when creating a Basic Zone.

As it turns out, as Anthony noted in another e-mail today in response to my
issue, if you are using a security-group-enabled zone or a basic zone, you
need to switch XenServer's networking mode from OVS to bridge since
security groups don't work on OVS.

The moral of the story is that if you are running in such an environment,
run the following on your XenServer host before trying to add it:

xe-switch-network-backend bridge

It looks like a change went in in early February and since then you could
not successfully add a XenServer host to such a zone unless it was
configured as specified above.

By the way, does anyone know if this is documented?

Thanks,

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

RE: master branch DbUtilTest failure

[Prachi Damle]

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.TransactionLegacy
>closeStatementFail(com.cloud.utils.DbUtilTest): Could not initialize class 
> com.cloud.utils.db.TransactionLegacy
>closeStatementFail(com.cloud.utils.DbUtilTest): Could not initialize class 
> com.cloud.utils.db.TransactionLegacy
>closeResultSet(com.clou

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

[Alena Prokharchyk]

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


Getting compilation error after applying the latest:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) 
on project cloud-server: Compilation failure
[ERROR] 
/Users/alena/repos/dr/cloudstack/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java:[4202,33]
 error: cannot find symbol
[ERROR] -> [Help 1]

- Alena Prokharchyk


On March 3, 2014, 11:26 p.m., Antonio Fornie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17888/
> ---
> 
> (Updated March 3, 2014, 11:26 p.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Dispatcher corrections, refactoring and tests. Corrects problems from 
> previous attempts that were reverted by Alena. Most of the changes are the 
> same, but this one is not creating conflicts of Map types for Aync Commands 
> or for parameters as Lists or Maps.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
>   api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
>   api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
>   api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java 
> 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/storage/snapshot/SnapshotSchedulerImpl.java 183a13a 
>   server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
>   server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/17888/diff/
> 
> 
> Testing
> ---
> 
> Full build and test plus manually testing many features. Also including 
> CreateTagsCommand that failed in previous commit.
> 
> All unit and integration tests.
> 
> Test CS Web UI with the browser going through several use cases.
> 
> Also use the CS API by sending HTTP requests generated manually including 
> requests for Async Commands with Map parameters and during these tests apart 
> fromtesting correct functionality I also debugged to check that Maps created 
> correctly where they should but also that in the cases where the async 
> command must be persisted and later on retrieved and deserialized by gson 
> everything works ok and does what and where is expected. An example based on 
> the comment by Alena:
> http://localhost:8096/client/api?command=createTags&resourceids=ids&resourcetype=type&tags[0].key=region&tags[0].value=canada
> Also other examples like
> http://localhost:8096/client/api?command=createSecondaryStagingStore&url=httpbla&details[0].key=region&details[0].value=canada&details[1].key=element&details[1].value=fire
> 
> 
> Thanks,
> 
> Antonio Fornie
> 
>

Re: Noteworthy change to setting up XenServer :)

[Ahmad Emneina]

definitely documented. 4.2 install guide:

 8.2.7. Install CloudStack XenServer Support Package (CSP)
(Optional)
To enable security groups, elastic load balancing, and elastic IP on
XenServer, download and install the CloudStack XenServer Support Package
(CSP). After installing XenServer, perform the following additional steps
on each XenServer host.


On Mon, Mar 3, 2014 at 3:34 PM, Mike Tutkowski  wrote:

> Hi everyone,
>
> I spent the past day or so trying to figure out with various builds why I
> could not add a XenServer host when creating a Basic Zone.
>
> As it turns out, as Anthony noted in another e-mail today in response to my
> issue, if you are using a security-group-enabled zone or a basic zone, you
> need to switch XenServer's networking mode from OVS to bridge since
> security groups don't work on OVS.
>
> The moral of the story is that if you are running in such an environment,
> run the following on your XenServer host before trying to add it:
>
> xe-switch-network-backend bridge
>
> It looks like a change went in in early February and since then you could
> not successfully add a XenServer host to such a zone unless it was
> configured as specified above.
>
> By the way, does anyone know if this is documented?
>
> Thanks,
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*
>

Re: Noteworthy change to setting up XenServer :)

[Ahmad Emneina]

bummer it now forces that route :) some people just want basic w/o security
groups, where I think it doesnt matter to use the bridged backend.


On Mon, Mar 3, 2014 at 3:38 PM, Ahmad Emneina  wrote:

> definitely documented. 4.2 install guide:
>
>  8.2.7. Install CloudStack XenServer Support Package (CSP)
> (Optional)
> To enable security groups, elastic load balancing, and elastic IP on
> XenServer, download and install the CloudStack XenServer Support Package
> (CSP). After installing XenServer, perform the following additional steps
> on each XenServer host.
>
>
> On Mon, Mar 3, 2014 at 3:34 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Hi everyone,
>>
>> I spent the past day or so trying to figure out with various builds why I
>> could not add a XenServer host when creating a Basic Zone.
>>
>> As it turns out, as Anthony noted in another e-mail today in response to
>> my
>> issue, if you are using a security-group-enabled zone or a basic zone, you
>> need to switch XenServer's networking mode from OVS to bridge since
>> security groups don't work on OVS.
>>
>> The moral of the story is that if you are running in such an environment,
>> run the following on your XenServer host before trying to add it:
>>
>> xe-switch-network-backend bridge
>>
>> It looks like a change went in in early February and since then you could
>> not successfully add a XenServer host to such a zone unless it was
>> configured as specified above.
>>
>> By the way, does anyone know if this is documented?
>>
>> Thanks,
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud
>> *(tm)*
>>
>
>

Re: Noteworthy change to setting up XenServer :)

[Mike Tutkowski]

It was just a surprise to me since I hadn't had a problem with this config
for the past year and then all of a sudden it stopped working.


On Mon, Mar 3, 2014 at 4:39 PM, Ahmad Emneina  wrote:

> bummer it now forces that route :) some people just want basic w/o security
> groups, where I think it doesnt matter to use the bridged backend.
>
>
> On Mon, Mar 3, 2014 at 3:38 PM, Ahmad Emneina  wrote:
>
> > definitely documented. 4.2 install guide:
> >
> >  8.2.7. Install CloudStack XenServer Support Package (CSP)
> > (Optional)
> > To enable security groups, elastic load balancing, and elastic IP on
> > XenServer, download and install the CloudStack XenServer Support Package
> > (CSP). After installing XenServer, perform the following additional steps
> > on each XenServer host.
> >
> >
> > On Mon, Mar 3, 2014 at 3:34 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> Hi everyone,
> >>
> >> I spent the past day or so trying to figure out with various builds why
> I
> >> could not add a XenServer host when creating a Basic Zone.
> >>
> >> As it turns out, as Anthony noted in another e-mail today in response to
> >> my
> >> issue, if you are using a security-group-enabled zone or a basic zone,
> you
> >> need to switch XenServer's networking mode from OVS to bridge since
> >> security groups don't work on OVS.
> >>
> >> The moral of the story is that if you are running in such an
> environment,
> >> run the following on your XenServer host before trying to add it:
> >>
> >> xe-switch-network-backend bridge
> >>
> >> It looks like a change went in in early February and since then you
> could
> >> not successfully add a XenServer host to such a zone unless it was
> >> configured as specified above.
> >>
> >> By the way, does anyone know if this is documented?
> >>
> >> Thanks,
> >>
> >> --
> >> *Mike Tutkowski*
> >> *Senior CloudStack Developer, SolidFire Inc.*
> >> e: mike.tutkow...@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the
> >> cloud
> >> *(tm)*
> >>
> >
> >
>



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

RE: master branch DbUtilTest failure

[Prachi Damle]

I solved it this way:

The problem is with the db.properties checked in with this DbUtiltest.java - It 
is empty

Fix is to

1) Put the right db.properties file under framework/db/test/resources 
2) Set db.cloud.encryption.type=none   [if you don't use encryption, so that 
EncryptionSecretKeyChecker won't look for \etc\cloudstack\management\key)]

Prachi

-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com] 
Sent: Monday, March 03, 2014 3:35 PM
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 initi

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

[Suresh Balineni]

> On March 3, 2014, 9:30 a.m., daan Hoogland wrote:
> > is this still valid? It is not applied on master. Should it be?

This must be applied to master branch.


- Suresh


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


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: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Antonio Fornie]

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

(Updated March 4, 2014, 12:18 a.m.)


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


Changes
---

Fix compilation problem


Repository: cloudstack-git


Description
---

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


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
  api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
  api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
  api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java 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.java 
8404cab 
  server/src/com/cloud/storage/snapshot/SnapshotSchedulerImpl.java 183a13a 
  server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
  server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
PRE-CREATION 

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


Testing
---

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

All unit and integration tests.

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

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


Thanks,

Antonio Fornie

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

[Antonio Fornié Casarrubios]

Fixed. Applied and mvn build works completely


2014-03-04 0:37 GMT+01:00 Alena Prokharchyk :

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17888/
>
> Getting compilation error after applying the latest:
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile 
> (default-compile) on project cloud-server: Compilation failure
> [ERROR] 
> /Users/alena/repos/dr/cloudstack/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java:[4202,33]
>  error: cannot find symbol
> [ERROR] -> [Help 1]
>
>
> - Alena Prokharchyk
>
> On March 3rd, 2014, 11:26 p.m. UTC, Antonio Fornie wrote:
>   Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and
> Hugo Trippaers.
> By Antonio Fornie.
>
> *Updated March 3, 2014, 11:26 p.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/storage/snapshot/SnapshotSchedulerImpl.java
>(183a13a)
>- server/test/com/cloud/api/ApiDispatcherTest.java (7314a57)
>- server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java
>(PRE-CREATION)
>- server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java
>(PRE-CREATION)
>- server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java
>(PRE-CREATION)
>- server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java
>(PRE-CREATION)
>- server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java
>(PRE-CREATION)
>
> View Diff 
>

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

[Marcus]

Personally, I feel like the rootdisksize itself should be a
fully-fledged api parameter, especially where we use it to create the
instance but don't actually persist it in the user_vm_details
database. I began doing that and then noticed that such a parameter
was actually removed with Bharat's details patch.

I'd like to get this ironed out to wrap up the root-resize branch.

On Mon, Mar 3, 2014 at 2:06 PM, Alena Prokharchyk
 wrote:
> Adding Bharat to the thread as he was the one who introduced the details
> param to the deployVm call.
>
> Bharat, why did you pick this format for storing the vm details? Were you
> following the rules from some other calls? If so, what those calls are?
>
> -Alena.
>
> On 3/3/14, 1:00 PM, "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 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 get method is invoked) and mainly the fact that these get methods
that
 >fix the map on the fly are copies of each other: instead of fixing the
 >structure in one method, the are plenty of methods almost identical
 >copying
 >and pasting the same lines. Some times the same method twice in the
same
 >cmd class for two Map params (look CreateNetworkOfferingCmd
 >#getServiceCapabilities and #getServiceProviders).
 >
 >2- params in which the get method returns the map as it is. With the
 >strange format. For example,
 >Cloudmonkey command
 >create networkoffering ... tags[0].key="City" tags[0].value="Toronto"
 >
 >You store in the table network_offeringstags, field tags, the String:
 >{0={value=Toronto,key=City}}
 >(including brackets and all)
 >
 >So knowing all this I guess you agree this should be refactored...
unless
 >at some point the strange format is needed. But after looking for it
 >everywhere I didn't find any place where it was. I already did the
change
 >and tested most of the cases and it all seems to work.
 >
 >
 >It would be great if once I upload the patch somebody could help me
double
 >check that it doesn't brake anything, not only reviewing to code. I
did
 >plenty of tests of many kinds, but I cannot be sure that I am covering
 >enough. Further, there seem to be several places w

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

[Alena Prokharchyk]

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


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 4, 2014, 12:18 a.m., Antonio Fornie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17888/
> ---
> 
> (Updated March 4, 2014, 12:18 a.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Dispatcher corrections, refactoring and tests. Corrects problems from 
> previous attempts that were reverted by Alena. Most of the changes are the 
> same, but this one is not creating conflicts of Map types for Aync Commands 
> or for parameters as Lists or Maps.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
>   api/src/org/apache/cloudstack/api/BaseCmd.java 0e83cee 
>   api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
>   api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java 
> 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.java 
> 8404cab 
>   server/src/com/cloud/storage/snapshot/SnapshotSchedulerImpl.java 183a13a 
>   server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
>   server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/17888/diff/
> 
> 
> Testing
> ---
> 
> Full build and test plus manually testing many features. Also including 
> CreateTagsCommand that failed in previous commit.
> 
> All unit and integration tests.
> 
> Test CS Web UI with the browser going through several use cases.
> 
> Also use the CS API by sending HTTP requests generated manually including 
> requests for Async Commands with Map parameters and during these tests apart 
> fromtesting correct functionality I also debugged to check that Maps created 
> correctly where they should but also that in the cases where the async 
> command must be persisted and later on retrieved and deserialized by gson 
> everything works ok and does what and where is expected. An example based on 
> the comment by Alena:
> http://localhost:8096/client/api?command=createTags&resourceids=ids&resourcetype=type&tags[0].key=region&tags[0].value=canada
> Also other examples like
> http://localhost:8096/client/api?command=createSecondaryStagingStore&url=httpbla&details[0].key=reg

RE: 4.4 Feature Freeze

[Animesh Chaturvedi]

> -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? 

Re: cloudstack @ github

[David Nalley]

In short - no.

The list of folks who have admin rights to that repo are infra folks;
largely a subset of root@, plus one or two others who actively manage
the system.

If you need something done, you can file Jira asking for specific
things to be done; but you won't receive admin rights.

--David

On Sun, Mar 2, 2014 at 3:20 PM, Daan Hoogland  wrote:
> can I get admin rights to https://github.com/apache/cloudstack, please?
>
> thanks,
> --
> Daan

RE: 4.4 Feature Freeze

[Animesh Chaturvedi]

From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Friday, February 28, 2014 6:10 AM
To: 
Subject: Re: 4.4 Feature Freeze

i'm all for being flexible, but i find a lot of the arguments used here 
debatable.

"It causes developers to rush their development to meet the deadline." This 
will happen anyway, every time we've extended the deadline we got new features 
coming in at the last minute. Actually i'm under the impression that when we 
move the deadline people will actually try to get more features in instead of 
working on stabilizing existing features.
[Animesh] Keep a feature freeze deadline closer don't extend it too far out. 
That's what we did for 4.3 when 4.2 took longer then planned.

"We can't deliver features on the roadmap." There is validity to this point, 
but on the other hand we already know the entire release schedule way ahead, 
this feature freeze date should not come as a surprise. But as i mentioned in 
an earlier mail, lets have this discussion. Post which features might not make 
it into the release so we can have a discussion if we should slip the release 
date to get this feature in. I think we all now that there are commercial 
parties working with this software to build releases and have customers 
demanding features, but if we don't discuss that on list it's hard for us to 
take it into account.
[Animesh] I agree with you but I think the PROPOSAL expectation is to have FS 
ready, with most folks working on 4.3 they did not have sufficient time to 
finish it up.

"Feature freeze wasn't called" True, i wasn't even aware that this was a 
requirement. We should add this to the procedure here 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so release 
managers know this is expected of them. It should not impact the dates as the 
dates are already fixed by the release schedule (every 4 months)



I'm still -1 on extending the feature freeze. I would rather extend the 
test/stability phase to we have some more time to fix issues before we get into 
the RC spinning.
[Animesh] Hugo one thing I do want to call out which David and I discussed 
today offline was if several of these features do not make into 4.4 many of 
these folks will move onto working on these in master and as a community we 
will not have the full focus on 4.4 as we should have for the current release. 
IMHO 2 weeks is a reasonable compromise after all of these folks were working 
hard on 4.3.


This is the list of current features targeted for 4.4 according to our Jira. 
Which features would be impacted if we don't move the feature freeze?

ASF JIRA
Project: CloudStack
Type: New Feature
Fix Version: 4.4.0
Resolution: Unresolved
Sorted by: Updated descending
1-15 of 15 as at: 28/Feb/14 15:07
TKey SummaryAssignee Reporter  P  
Status  Resolution  Created   Updated  Due
[New Feature]   CLOUDSTACK-6181
Root resize
UnassignedNux [Major]  [Open]  Open   Unresolved 
27/Feb/1427/Feb/14
[New Feature]   CLOUDSTACK-6161
distributed routing and network ACL with OVS plug-in
Murali ReddyMurali Reddy [Major]  [Open]  Open   
Unresolved 24/Feb/14  24/Feb/14
[New Feature]   CLOUDSTACK-6092
Storage OverProvisioning as a Per Primary Basis
Saksham Srivastava  Saksham Srivastava   [Major]  [Open]  Open  
 Unresolved  13/Feb/1420/Feb/14
[New Feature]   CLOUDSTACK-6144
HA for guest VMs running Hyper-V
UnassignedRajesh Battala [Major]  [Open]  Open   Unresolved 
20/Feb/14  20/Feb/14
[New Feature]   CLOUDSTACK-6143
Storage Live-Migration support for Hyper-V
UnassignedRajesh Battala [Major]  [Open]  Open   Unresolved 
20/Feb/14  20/Feb/14
[New Feature]   CLOUDSTACK-6142
Zone Wide Primary Store in Hyper-V
UnassignedRajesh Battala [Major]  [Open]  Open   Unresolved 
20/Feb/14  20/Feb/14
[New Feature]   CLOUDSTACK-6104
PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
Sateesh Chodapuneedi  Sateesh Chodapuneedi   [Major]  
[Open]  Open  Unresolved 14/Feb/1415/Feb/14
[New Feature]   CLOUDSTACK-6109
Support of iSCSI as primary store in Hyper-V
Rajesh Battala   Rajesh Battala [Major]  [Open]  Open   
Unresolved 14/Feb/14  14/Feb/14
[New Feature]   CLOUDSTACK-6106
Support of VPC in HyperV
Rajesh Battala   Rajesh Battala [Major]  [Open]  Open   
Unresolved 14/Feb/14  14/Feb/14
[New Feature]   CLOUDSTACK-6090
Virtual Router Service Failure Alerting
Harikrishna Patnala  Harikrishna Patnala[Major]  [Open]  Open   
Unresolved  13/Feb/1413/Feb/14
[New Feature]   CLOUDSTACK-6052
List VM enhancement to support querying with mult

Current system VM template for XenServer

[Mike Tutkowski]

Hi,

I've jumped back onto 4.4 after having been on 4.3 the past few weeks and
am having some trouble in 4.4 getting the agents in the SSVM and CPVM to
start (both VMs show as being in the Up state in the GUI, but both agents
are not listed as being in the Up state).

Can someone tell me if this template is what I should be currently using on
master for XenServer?

http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2

Thanks!

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

4.3 createVMSnapshot doesn't check volume state

[Qian Shaohua]

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

Re: 4.4 Feature Freeze

[Abhinandan Prateek]

Daan,
  
   Since you are the 4.4 RM we will respect your decision.

-abhi

On 03/03/14 2:11 pm, "Daan Hoogland"  wrote:

>Abhinandan, first one compromis-proposal, please.
>
>Can we not postpone but allow for this one feature (CLOUDSTACK-6161)
>this one time (4.4) to go in after feature freeze. If this is the only
>one and we don't consider this jurisprudence we could allow for it.
>@Hugo: say what?
>
>
>
>On Mon, Mar 3, 2014 at 9:33 AM, Abhinandan Prateek
> wrote:
>> I think there is no consensus on feature freeze date yet ?
>>
>> Daan,
>>  Shall we call for a vote on this ?
>>
>> -abhi
>>
>> On 03/03/14 6:11 am, "Mike Tutkowski" 
>>wrote:
>>
>>>I believe March 14th is Feature Freeze and, as such, when the 4.4 branch
>>>is
>>>cut.
>>>
>>>
>>>On Sun, Mar 2, 2014 at 11:12 AM, Sebastien Goasguen
>>>wrote:
>>>

 On Feb 28, 2014, at 9:09 AM, Hugo Trippaers  wrote:

 > i'm all for being flexible, but i find a lot of the arguments used
here
 debatable.
 >
 > "It causes developers to rush their development to meet the
deadline."
 This will happen anyway, every time we've extended the deadline we got
new
 features coming in at the last minute. Actually i'm under the
impression
 that when we move the deadline people will actually try to get more
 features in instead of working on stabilizing existing features.
 >
 > "We can't deliver features on the roadmap." There is validity to
this
 point, but on the other hand we already know the entire release
schedule
 way ahead, this feature freeze date should not come as a surprise. But
as i
 mentioned in an earlier mail, lets have this discussion. Post which
 features might not make it into the release so we can have a
discussion
if
 we should slip the release date to get this feature in. I think we all
now
 that there are commercial parties working with this software to build
 releases and have customers demanding features, but if we don't
discuss
 that on list it's hard for us to take it into account.
 >
 > "Feature freeze wasn't called" True, i wasn't even aware that this
was a
 requirement. We should add this to the procedure here
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so
 release managers know this is expected of them. It should not impact
the
 dates as the dates are already fixed by the release schedule (every 4
 months)
 >
 >
 > I'm still -1 on extending the feature freeze. I would rather extend
the
 test/stability phase to we have some more time to fix issues before we
get
 into the RC spinning.
 >
 >
 > This is the list of current features targeted for 4.4 according to
our
 Jira. Which features would be impacted if we don't move the feature
freeze?
 >
 > ASF JIRA
 > Project: CloudStack
 > Type: New Feature
 > Fix Version: 4.4.0
 > Resolution: Unresolved
 > Sorted by: Updated descending
 > 1-15 of 15 as at: 28/Feb/14 15:07
 > T Key Summary AssigneeReporterP   Status
  Resolution  Created Updated Due
 >   CLOUDSTACK-6181
 > Root resize
 > UnassignedNux   Open Unresolved
  27/Feb/14   27/Feb/14
 >   CLOUDSTACK-6161
 > distributed routing and network ACL with OVS plug-in
 > Murali Reddy  Murali Reddy  Open
Unresolved
  24/Feb/14   24/Feb/14
 >   CLOUDSTACK-6092
 > Storage OverProvisioning as a Per Primary Basis
 > Saksham SrivastavaSaksham Srivastava  

 Open Unresolved  13/Feb/14   20/Feb/14
 >   CLOUDSTACK-6144
 > HA for guest VMs running Hyper-V
 > UnassignedRajesh BattalaOpen
Unresolved
  20/Feb/14   20/Feb/14
 >   CLOUDSTACK-6143
 > Storage Live-Migration support for Hyper-V
 > UnassignedRajesh BattalaOpen
Unresolved
  20/Feb/14   20/Feb/14
 >   CLOUDSTACK-6142
 > Zone Wide Primary Store in Hyper-V
 > UnassignedRajesh BattalaOpen
Unresolved
  20/Feb/14   20/Feb/14
 >   CLOUDSTACK-6104
 > PVLAN support for CloudStack deployment over Nexus 1000v in VMware
 environment
 > Sateesh Chodapuneedi  Sateesh Chodapuneedi

 Open Unresolved  14/Feb/14   15/Feb/14
 >   CLOUDSTACK-6109
 > Support of iSCSI as primary store in Hyper-V
 > Rajesh BattalaRajesh Battala   
Open
 Unresolved  14/Feb/14   14/Feb/14
 >   CLOUDSTACK-6106
 > Support of VPC in HyperV
 > Rajesh BattalaRajesh Battala   
Open
 Unresolved  14/Feb/14   14/Feb/14
 >   CLOUDSTACK-6090
 > Virtual Router Service Failure Alerting
 > Harikrishna Patnala   Harikrishna Patnala 

 Open Unresolved  13/Feb/14

RE: 4.4 Feature Freeze

[Damoder Reddy]

This list is not containing CLOUDSTACK-6105



Looks like I did not set Fix Versions Properly for this ticket..


Thanks & Regards
Damodar/

From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Friday, February 28, 2014 7:40 PM
To: 
Subject: Re: 4.4 Feature Freeze

i'm all for being flexible, but i find a lot of the arguments used here 
debatable.

"It causes developers to rush their development to meet the deadline." This 
will happen anyway, every time we've extended the deadline we got new features 
coming in at the last minute. Actually i'm under the impression that when we 
move the deadline people will actually try to get more features in instead of 
working on stabilizing existing features.

"We can't deliver features on the roadmap." There is validity to this point, 
but on the other hand we already know the entire release schedule way ahead, 
this feature freeze date should not come as a surprise. But as i mentioned in 
an earlier mail, lets have this discussion. Post which features might not make 
it into the release so we can have a discussion if we should slip the release 
date to get this feature in. I think we all now that there are commercial 
parties working with this software to build releases and have customers 
demanding features, but if we don't discuss that on list it's hard for us to 
take it into account.

"Feature freeze wasn't called" True, i wasn't even aware that this was a 
requirement. We should add this to the procedure here 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so release 
managers know this is expected of them. It should not impact the dates as the 
dates are already fixed by the release schedule (every 4 months)


I'm still -1 on extending the feature freeze. I would rather extend the 
test/stability phase to we have some more time to fix issues before we get into 
the RC spinning.


This is the list of current features targeted for 4.4 according to our Jira. 
Which features would be impacted if we don't move the feature freeze?

ASF JIRA
Project: CloudStack
Type: New Feature
Fix Version: 4.4.0
Resolution: Unresolved
Sorted by: Updated descending
1-15 of 15 as at: 28/Feb/14 15:07
T  Key Summary Assignee  Reporter  P
  Status  Resolution   Created   UpdatedDue
[New Feature]CLOUDSTACK-6181
Root resize
Unassigned Nux [Major] [Open]  Open  Unresolved  
27/Feb/1427/Feb/14
[New Feature]CLOUDSTACK-6161
distributed routing and network ACL with OVS plug-in
Murali Reddy  Murali Reddy  [Major] [Open]  Open  Unresolved
  24/Feb/1424/Feb/14
[New Feature]CLOUDSTACK-6092
Storage OverProvisioning as a Per Primary Basis
Saksham SrivastavaSaksham Srivastava[Major] [Open]  Open
  Unresolved  13/Feb/1420/Feb/14
[New Feature]CLOUDSTACK-6144
HA for guest VMs running Hyper-V
Unassigned Rajesh Battala [Major] [Open]  Open  Unresolved  
20/Feb/1420/Feb/14
[New Feature]CLOUDSTACK-6143
Storage Live-Migration support for Hyper-V
Unassigned Rajesh Battala [Major] [Open]  Open  Unresolved  
20/Feb/1420/Feb/14
[New Feature]CLOUDSTACK-6142
Zone Wide Primary Store in Hyper-V
Unassigned Rajesh Battala [Major] [Open]  Open  Unresolved  
20/Feb/1420/Feb/14
[New Feature]CLOUDSTACK-6104
PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
Sateesh Chodapuneedi   Sateesh Chodapuneedi   [Major] 
[Open]  Open  Unresolved  14/Feb/1415/Feb/14
[New Feature]CLOUDSTACK-6109
Support of iSCSI as primary store in Hyper-V
Rajesh Battala Rajesh Battala [Major] [Open]  Open  Unresolved  
14/Feb/1414/Feb/14
[New Feature]CLOUDSTACK-6106
Support of VPC in HyperV
Rajesh Battala Rajesh Battala [Major] [Open]  Open  Unresolved  
14/Feb/1414/Feb/14
[New Feature]CLOUDSTACK-6090
Virtual Router Service Failure Alerting
Harikrishna Patnala Harikrishna Patnala [Major] [Open]  Open
  Unresolved  13/Feb/1413/Feb/14
[New Feature]CLOUDSTACK-6052
List VM enhancement to support querying with multiple VM IDs
Koushik Das   Koushik Das   [Major] [Open]  Open  Unresolved
  07/Feb/1407/Feb/14
[New Feature]CLOUDSTACK-5569
enhance OVS plug-in to support region level VPC and guest networks that span 
zones
Murali Reddy  Murali Reddy  [Major] [Open]  Open  Unresolved
  19/Dec/1319/Dec/13
[New Feature]CLOUDSTACK-5568
introduce notion of guest network that spans multiple zones
Murali Reddy  Murali Reddy  [Major] [Open]  Open  Unresolved
  19/Dec/1319/Dec/13
[New Feature]CLOUDSTACK-5567
enable

Re: Unable to deploy vm

[Tejas Gadaria]

Thanks Sanjeev,

It's working fine.

Regards,
Tejas


On Mon, Mar 3, 2014 at 11:27 AM, Sanjeev Neelarapu <
sanjeev.neelar...@citrix.com> wrote:

> Hi Tejas,
>
> It is recommended to use a clean secondary storage for storing all the
> artificats, otherwise CS might overwrite since it follows standard
> directory structure for storing templates. So please clean your storage
> before adding it to CS.
>
> Thanks,
> Sanjeev
>
> -Original Message-
> From: Tejas Gadaria [mailto:refond.g...@gmail.com]
> Sent: Friday, February 28, 2014 10:54 AM
> To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
> Subject: Re: Unable to deploy vm
>
> Hi,
>
> Please ignore previous mail,
> I think I misunderstood & deleted stale sysetmvm.iso. Still I am facing
> same error .
>
> So Under "Templates" do I need to delete all guest vm templates?
> do I need to delete " CentOS 5.3(64bit) no GUI (vSphere)" ?
>
> Regards,
> Tejas
>
>
>
> On Thu, Feb 27, 2014 at 2:53 PM, Tejas Gadaria  >wrote:
>
> > Hi Sailaja & Sanjeev,
> >
> > Thanks for replay,
> >
> > It  worked for me. My network it very slow so I could not verify at
> > this time.
> > But yeah it's not throwing error at that point.
> >
> > Regards,
> > Tejas
> >
> >
> >
> >
> > On Thu, Feb 27, 2014 at 11:56 AM, Sailaja Mada  >wrote:
> >
> >> Hi,
> >>
> >> Root cause and workaround are listed in the bug details @
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-1403?focusedCommentI
> >> d=13588714&page=com.atlassian.jira.plugin.system.issuetabpanels:comme
> >> nt-tabpanel#comment-13588714
> >>
> >>
> >> =
> >> ===
> >> Analysis & Root cause:-
> >> Due to connection issues the first attempt to download template from
> >> secondary storage failed while importing OVA template.
> >> This left a stale template object in the datacenter. Next attempt to
> >> download the template has returned success as only existance of
> >> template with the specific uuid is checked. No more attempts made to
> >> setup the template again.
> >> The answer shows template size as 0. Atleast at this point the
> >> corruption in template should have been detected.
> >> The answer from logs is -
> >> [{"storage.PrimaryStorageDownloadAnswer":{"installPath":"e372770297f7
> >> 3702b26a7898d041f3f8","templateSize":0,"result":true,"wait":0}}]
> >> }
> >> Any subsequent VM deployment would look to create a volume from this
> >> template which fails as expected. After a successful import of OVA on
> >> primary storage, a snapshot is taken to create a base snapshot from
> >> which volumes are created. But due to IOException encountered while
> >> uploading the file to URL this snapshot attempt was not made.
> >>
> >> Fix:-
> >> Handle IOException while uploading template to primary storage URL
> >> and cleanup stale template. Working on unit testing now.
> >>
> >> We have work around for this issue. Delete the stale template that
> >> was created in datacenter due to failed PrimaryStorageDownloadCommand.
> >> Subsequently a template would be setup again freshly.
> >>
> >> =
> >> ===
> >>
> >>
> >> Thanks,
> >> Sailaja.M
> >>
> >> -Original Message-
> >> From: Tejas Gadaria [mailto:refond.g...@gmail.com]
> >> Sent: 27 February 2014 10:35
> >> To: us...@cloudstack.apache.org
> >> Subject: Re: Unable to deploy vm
> >>
> >> Hi,
> >> thanks for replay,
> >>
> >> Is there any workaround for this ?
> >> OR
> >> how can I update 4.0.2 to 4.1.0 ?
> >>
> >> Regards,
> >> Tejas
> >>
> >>
> >> On Wed, Feb 26, 2014 at 2:55 PM, Sailaja Mada
> >>  >> >wrote:
> >>
> >> > Hi,
> >> >
> >> > Error log seems to be same as the bug @
> >> > https://issues.apache.org/jira/browse/CLOUDSTACK-1403 - This got
> >> > fixed in
> >> > 4.1.0 .
> >> >
> >> > Thanks,
> >> > Sailaja.M
> >> >
> >> >
> >> > -Original Message-
> >> > From: Tejas Gadaria [mailto:refond.g...@gmail.com]
> >> > Sent: 26 February 2014 13:21
> >> > To: us...@cloudstack.apache.org
> >> > Subject: Unable to deploy vm
> >> >
> >> > Hi,
> >> >
> >> > I am using CS 4.0.3 with vmware hypervisor.
> >> >
> >> > SSVM and CPVM is running both public and private IP are pinging
> >> > from management server.
> >> >
> >> > while trying to deploy vm from template, it.s giving ,
> >> >
> >> > 2014-02-26 12:50:18,182 ERROR [vmware.resource.VmwareResource]
> >> > (DirectAgent-418:10.129.150.22) Unable to find template base
> >> > snapshot, invalid template
> >> > 2014-02-26 12:50:18,182 ERROR [vmware.resource.VmwareResource]
> >> > (DirectAgent-418:10.129.150.22) CreateCommand failed due to Exception:
> >> > java.lang.Exception
> >> > Message: Unable to find template base snapshot, invalid template
> >> >
> >> > java.lang.Exception: Unable to find template base snapshot, invalid
> >> > template
> >> > at
> >> >
> >> >
> >> com.cloud.hypervisor.vmware

Re: Review Request 18677: CLOUDSTACK-3272

[Sonal Ojha]

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


- Sonal Ojha


On March 3, 2014, 5:58 a.m., Sonal Ojha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18677/
> ---
> 
> (Updated March 3, 2014, 5:58 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> At present, there are multiple event types that are generated by CS, action 
> events,usage events, resource state change events and alerts. Current problem 
> is
> all the events gets published on the event bus when event bus is enabled. 
> Intent is to introduce global setting config parameters to specify which 
> category of events to be published or not be published on the event bus.
> 
> 
> Diffs
> -
> 
>   
> plugins/event-bus/rabbitmq/src/org/apache/cloudstack/mom/rabbitmq/RabbitMQEventBus.java
>  478c8d7 
>   server/src/com/cloud/configuration/Config.java 2d55f46 
>   server/src/com/cloud/test/DatabaseConfig.java 9370218 
> 
> Diff: https://reviews.apache.org/r/18677/diff/
> 
> 
> Testing
> ---
> 
> Successfully tested publishing / not publishing of various events based on 
> the global parameter publish.*.events.
> 
> 
> Thanks,
> 
> Sonal Ojha
> 
>

Re: Review Request 18677: CLOUDSTACK-3272

[Sonal Ojha]

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

(Updated March 4, 2014, 5:51 a.m.)


Review request for cloudstack, Chiradeep Vittal and Murali Reddy.


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


Repository: cloudstack-git


Description
---

At present, there are multiple event types that are generated by CS, action 
events,usage events, resource state change events and alerts. Current problem is
all the events gets published on the event bus when event bus is enabled. 
Intent is to introduce global setting config parameters to specify which 
category of events to be published or not be published on the event bus.


Diffs
-

  
plugins/event-bus/rabbitmq/src/org/apache/cloudstack/mom/rabbitmq/RabbitMQEventBus.java
 478c8d7 
  server/src/com/cloud/configuration/Config.java 2d55f46 
  server/src/com/cloud/test/DatabaseConfig.java 9370218 

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


Testing
---

Successfully tested publishing / not publishing of various events based on the 
global parameter publish.*.events.


Thanks,

Sonal Ojha

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

[Rajani Karuturi]

---
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.


Changes
---

updated the patch for master


Repository: cloudstack-git


Description
---

in the smoke tests, this will fix test_03_delete_iso when run against a 
simulator


Diffs (updated)
-

  
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: CLOUDSTACK-5663

[Saurav Lahiri]

Parth,
Can you shed some light on how this issue can be recreated. As mentioned
earlier it looks like it is going through the non shared network code path,
why this has happened is not very clear.

Thanks
Saurav


On Wed, Feb 26, 2014 at 5:00 PM, Saurav Lahiri wrote:

> Thank you very much. I will follow up on this with Parth.
>
>
> Saurav
>
>
> On Tue, Feb 25, 2014 at 11:50 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
>> Thank you, Dave.
>>
>> Saurav, I¹ve assigned the bug to you.
>>
>> -Alena.
>>
>> On 2/25/14, 10:15 AM, "David Nalley"  wrote:
>>
>> >> As for the bug, you need to be added to the Jira users DB in order to
>> >> become an assignee. Whoever administers Jira, can you please do it?
>> >>
>> >
>> >
>> >Done
>> >
>> >--David
>>
>>
>>
>