Review Request 13626: CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server Introducing the option dhcp-client-update fails if

[bharat kumar]

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

Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.


Bugs: Cloudstack-4321


Repository: cloudstack-git


Description
---

CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual 
machines(clients) to update its hostnames with a  DNS server
Introducing the option dhcp-client-update fails if the version dnsmasq is 
not above 2.6 (like in burbak template).
Added a check for the version. will add this option in the config file only 
if the version is 2.6 and above.


Diffs
-

  patches/systemvm/debian/config/etc/init.d/cloud-early-config 736234c 

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


Testing
---

tested on 4.2.
with the burbank template by running updated cloud-early-config manually.


Thanks,

bharat kumar

Re: Easiest Way...

[Venkata SwamyBabu Budumuru]

Hi Maurice,

This piece is now automatically done by CloudStack 4.2 release. There is a
feature called "secondary Ips / multiple Ips per NIC". You can have a look
at the code to see what you need to exactly configure.

On 17/08/13 12:05 AM, "Maurice Lawler"  wrote:

>Greetings,
>
>What is the easiest way to manipulate a script to allow a instance to get
>a second IP address? I know it would require some fiddling with ebtables.
>
>Please provide some additional information, and method to permit this
>please.
>
>- Maurice

Re: Review Request 13626: CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server Introducing the option dhcp-client-update fail

[bharat kumar]

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

(Updated Aug. 17, 2013, 8:06 a.m.)


Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.


Changes
---

removed a typo from the commit message.


Bugs: Cloudstack-4321


Repository: cloudstack-git


Description
---

CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual 
machines(clients) to update its hostnames with a  DNS server
Introducing the option dhcp-client-update fails if the version dnsmasq is 
not above 2.6 (like in burbak template).
Added a check for the version. will add this option in the config file only 
if the version is 2.6 and above.


Diffs (updated)
-

  patches/systemvm/debian/config/etc/init.d/cloud-early-config 736234c 

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


Testing
---

tested on 4.2.
with the burbank template by running updated cloud-early-config manually.


Thanks,

bharat kumar

Re: Review Request 13626: CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server Introducing the option dhcp-client-update fail

[Abhinandan Prateek]

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


This will fail for higher version than 2.6

- Abhinandan Prateek


On Aug. 17, 2013, 8:06 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13626/
> ---
> 
> (Updated Aug. 17, 2013, 8:06 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.
> 
> 
> Bugs: Cloudstack-4321
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual 
> machines(clients) to update its hostnames with a  DNS server
> Introducing the option dhcp-client-update fails if the version dnsmasq is 
> not above 2.6 (like in burbak template).
> Added a check for the version. will add this option in the config file 
> only if the version is 2.6 and above.
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/etc/init.d/cloud-early-config 736234c 
> 
> Diff: https://reviews.apache.org/r/13626/diff/
> 
> 
> Testing
> ---
> 
> tested on 4.2.
> with the burbank template by running updated cloud-early-config manually.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 13615: [Autoscale] Account deletion doesn't delete all autoscaled LB rules created by the account

[Murali Reddy]

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

Ship it!


4.2 a03c5f5b1bb3e45b5b2a8365b0c09d48778e426a
master bb26b854fb89ef71c5183e2c23ef17898d9d

- Murali Reddy


On Aug. 16, 2013, 12:39 p.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13615/
> ---
> 
> (Updated Aug. 16, 2013, 12:39 p.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Ram Ganesh.
> 
> 
> Bugs: CLOUDSTACK-4237
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Issue:
> for an account if there are multiple LB rules and Autoscale Policies, when 
> Account is deleted. All the LBrules, Autoscale polices are not getting delete 
> in Netscaler resource. But in CS db they are getting cleared.
> 
> Root Cause:
> ===
> while processing the LBConfigcmd in NSResource, after processing the first 
> Autoscale cmd, no other rules are getting processed as its returning from 
> loop.
> 
> Fix:
>  
> 
> Fixed the issue to process all the autoscale config rules in the 
> LBConfigCommand.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  4020059 
> 
> Diff: https://reviews.apache.org/r/13615/diff/
> 
> 
> Testing
> ---
> 
> 1. created a testA account and created network with NS as LB provider and 
> Acquired 3 ip's
> 2. on each IP configured multiple Autoscale polices and normal LB rules.
> 3. Verified on NS there are total 4 vservers and 3 services ( 2 autoscale and 
> 2 cloud service)
> 4. deleted one LB rule. LB rule got delete successfully and the same is 
> removed from NS.
> 5. deleted the account, network got deleted as part of it all the rules got 
> revoked and sent to NSResource to execute them. 
> All the servers, lb vservers got remove successfully.
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

Review Request 13627: Fix for CLOUDSTACK-3441

[Koushik Das]

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

Review request for cloudstack, Alex Huang, Abhinandan Prateek, Chiradeep 
Vittal, and Murali Reddy.


Bugs: CLOUDSTACK-3441


Repository: cloudstack-git


Description
---

CLOUDSTACK-3441: [Load Test] High delays between VM being allocated to Pod and 
network implementation causing delays in VM deployment

The locking code in implement/shutdown network code was not efficient. Even in 
order to check the current state of the network lock was getting acquired which 
is not required. This resulted in delays in deploy VM as can be seen from 
attached logs where the code waited on the lock just to check if network is 
implemented.

As part of the fix moved out code that is checking if the network is already 
implemented or shutdowned outside the lock.


Diffs
-

  server/src/com/cloud/network/NetworkManagerImpl.java 68b1b4f 

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


Testing
---


Thanks,

Koushik Das

Re: Review Request 13627: Fix for CLOUDSTACK-3441

[Koushik Das]

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

(Updated Aug. 17, 2013, 9:32 a.m.)


Review request for cloudstack, Alex Huang, Abhinandan Prateek, Chiradeep 
Vittal, and Murali Reddy.


Bugs: CLOUDSTACK-3441


Repository: cloudstack-git


Description
---

CLOUDSTACK-3441: [Load Test] High delays between VM being allocated to Pod and 
network implementation causing delays in VM deployment

The locking code in implement/shutdown network code was not efficient. Even in 
order to check the current state of the network lock was getting acquired which 
is not required. This resulted in delays in deploy VM as can be seen from 
attached logs where the code waited on the lock just to check if network is 
implemented.

As part of the fix moved out code that is checking if the network is already 
implemented or shutdowned outside the lock.


Diffs (updated)
-

  server/src/com/cloud/network/NetworkManagerImpl.java 68b1b4f 

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


Testing
---


Thanks,

Koushik Das

Re: Review Request 13626: CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server Introducing the option dhcp-client-update fail

[Jayapal Reddy]

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



patches/systemvm/debian/config/etc/init.d/cloud-early-config


grep for 'version 2.6'.
Split the 2.6 and compare 2 and 6

In router currently it is showing 2.62

Dnsmasq version 2.62  Copyright (c) 2000-2012 Simon Kelley


- Jayapal Reddy


On Aug. 17, 2013, 8:06 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13626/
> ---
> 
> (Updated Aug. 17, 2013, 8:06 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.
> 
> 
> Bugs: Cloudstack-4321
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual 
> machines(clients) to update its hostnames with a  DNS server
> Introducing the option dhcp-client-update fails if the version dnsmasq is 
> not above 2.6 (like in burbak template).
> Added a check for the version. will add this option in the config file 
> only if the version is 2.6 and above.
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/etc/init.d/cloud-early-config 736234c 
> 
> Diff: https://reviews.apache.org/r/13626/diff/
> 
> 
> Testing
> ---
> 
> tested on 4.2.
> with the burbank template by running updated cloud-early-config manually.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 13626: CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server Introducing the option dhcp-client-update fail

[bharat kumar]

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

(Updated Aug. 17, 2013, 11:35 a.m.)


Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.


Changes
---

revised the code to accommodate versions greater than 2


Bugs: Cloudstack-4321


Repository: cloudstack-git


Description
---

CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual 
machines(clients) to update its hostnames with a  DNS server
Introducing the option dhcp-client-update fails if the version dnsmasq is 
not above 2.6 (like in burbak template).
Added a check for the version. will add this option in the config file only 
if the version is 2.6 and above.


Diffs (updated)
-

  patches/systemvm/debian/config/etc/init.d/cloud-early-config 736234c 

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


Testing
---

tested on 4.2.
with the burbank template by running updated cloud-early-config manually.


Thanks,

bharat kumar

Re: Review Request 13626: CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server Introducing the option dhcp-client-update fail

[Jayapal Reddy]

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

Ship it!


Ship It!

- Jayapal Reddy


On Aug. 17, 2013, 11:35 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13626/
> ---
> 
> (Updated Aug. 17, 2013, 11:35 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.
> 
> 
> Bugs: Cloudstack-4321
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual 
> machines(clients) to update its hostnames with a  DNS server
> Introducing the option dhcp-client-update fails if the version dnsmasq is 
> not above 2.6 (like in burbak template).
> Added a check for the version. will add this option in the config file 
> only if the version is 2.6 and above.
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/etc/init.d/cloud-early-config 736234c 
> 
> Diff: https://reviews.apache.org/r/13626/diff/
> 
> 
> Testing
> ---
> 
> tested on 4.2.
> with the burbank template by running updated cloud-early-config manually.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

RE: Review Request 13615: [Autoscale] Account deletion doesn't delete all autoscaled LB rules created by the account

[Rajesh Battala]

Thanks Murali for reviewing and pushing the patch to repo.

Thanks
Rajesh Battala

From: Murali Reddy [mailto:nore...@reviews.apache.org] On Behalf Of Murali Reddy
Sent: Saturday, August 17, 2013 2:33 PM
To: Ram Ganesh; Murali Reddy
Cc: Rajesh Battala; cloudstack
Subject: Re: Review Request 13615: [Autoscale] Account deletion doesn't delete 
all autoscaled LB rules created by the account

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



Ship it!

4.2 a03c5f5b1bb3e45b5b2a8365b0c09d48778e426a

master bb26b854fb89ef71c5183e2c23ef17898d9d


- Murali Reddy


On August 16th, 2013, 12:39 p.m. UTC, Rajesh Battala wrote:
Review request for cloudstack, Murali Reddy and Ram Ganesh.
By Rajesh Battala.

Updated Aug. 16, 2013, 12:39 p.m.
Bugs: CLOUDSTACK-4237
Repository: cloudstack-git
Description

Issue:

for an account if there are multiple LB rules and Autoscale Policies, when 
Account is deleted. All the LBrules, Autoscale polices are not getting delete 
in Netscaler resource. But in CS db they are getting cleared.



Root Cause:

===

while processing the LBConfigcmd in NSResource, after processing the first 
Autoscale cmd, no other rules are getting processed as its returning from loop.



Fix:





Fixed the issue to process all the autoscale config rules in the 
LBConfigCommand.


Testing

1. created a testA account and created network with NS as LB provider and 
Acquired 3 ip's

2. on each IP configured multiple Autoscale polices and normal LB rules.

3. Verified on NS there are total 4 vservers and 3 services ( 2 autoscale and 2 
cloud service)

4. deleted one LB rule. LB rule got delete successfully and the same is removed 
from NS.

5. deleted the account, network got deleted as part of it all the rules got 
revoked and sent to NSResource to execute them.

All the servers, lb vservers got remove successfully.


Diffs

  *   
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
 (4020059)

View Diff

Re: Admin Password

[SuichII, Christopher]

If you look in /developer/developer-prefill.sql, you'll find the 
default password already encrypted. Just copy that and set it as the password 
for the admin account with mysql at the command line.

If you need help with that, just let me know and I can write the SQL command 
for you.

-Chris

On Aug 16, 2013, at 5:19 PM, Maurice Lawler  wrote:

>> 
>> 
>> Riddle me this…
>> 
>> I am unsure as to what the issue is, I installed CS 4.1.1 and created a 
>> secondary user, logged out of the Admin portion logged into the regular user 
>> and now the admin password does not work. How would one change the password 
>> via the database or another method ?
>> 
>> - Maurice
> 

Re: Admin Password

[Maurice Lawler]

Got it! Thanks, Chris! :-)

"SuichII, Christopher"  wrote:

>If you look in /developer/developer-prefill.sql, you'll find the 
>default password already encrypted. Just copy that and set it as the password 
>for the admin account with mysql at the command line.
>
>If you need help with that, just let me know and I can write the SQL command 
>for you.
>
>-Chris
>
>On Aug 16, 2013, at 5:19 PM, Maurice Lawler  wrote:
>
>>> 
>>> 
>>> Riddle me this…
>>> 
>>> I am unsure as to what the issue is, I installed CS 4.1.1 and created a 
>>> secondary user, logged out of the Admin portion logged into the regular 
>>> user and now the admin password does not work. How would one change the 
>>> password via the database or another method ?
>>> 
>>> - Maurice
>> 
>

Production Agent Disconnect

[Marty Sweet]

Hi Guys,

I have just had a VMHost randomly disconnect in production and subsequently
take down some VMs.
I have attached the logs (happened to be running agent trace on this node),
but it would seem that the agent (or management?) waited 25 seconds before
erroring, and then the cloudstack agent froze until 1800.
I assume the agent syslog stack traces were caused by force closes of VMs,
no other nodes were affected during this time period.

While the host was in disconnect mode, I could connect to a VM which was
running on that host, although Cloudstack was already reporting that is was
down.
 Would it be a good idea to ping VM's (their allocated IPs before
attempting to start them on other nodes - especially in a HA setup)?

If someone could look at the logs and let me know if there is something
obvious it would be most appreciated, I have included the management bond
for reference that the link didn't go down.

Thanks in advance,
Marty
Aug 17 17:40:11 aurora dnsmasq-dhcp[6150]: DHCP packet received on brbond0-152 
which has no address
Aug 17 17:40:11 aurora dnsmasq-dhcp[6150]: DHCP packet received on brbond0-152 
which has no address
Aug 17 17:41:53 aurora puppet-agent[9852]: Finished catalog run in 7.21 seconds
Aug 17 17:59:01 aurora kernel: [522967.085451] INFO: task kvm:8402 blocked for 
more than 120 seconds.
Aug 17 17:59:01 aurora kernel: [522967.085788] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 17 17:59:01 aurora kernel: [522967.086214] kvm D 
8180cbe0 0  8402  1 0x
Aug 17 17:59:01 aurora kernel: [522967.086219]  881cf3c43cd8 
0082 881cf3c43cb8 81080cd8
Aug 17 17:59:01 aurora kernel: [522967.086226]  881cf3c43fd8 
881cf3c43fd8 881cf3c43fd8 000139c0
Aug 17 17:59:01 aurora kernel: [522967.086230]  881f92dc9700 
881c0cdfdc00 0282 883f912d0a80
Aug 17 17:59:01 aurora kernel: [522967.086235] Call Trace:
Aug 17 17:59:01 aurora kernel: [522967.086244]  [] ? 
__wake_up_common+0x58/0x90
Aug 17 17:59:01 aurora kernel: [522967.086250]  [] 
schedule+0x29/0x70
Aug 17 17:59:01 aurora kernel: [522967.086255]  [] 
exit_mm+0x85/0x130
Aug 17 17:59:01 aurora kernel: [522967.086259]  [] 
do_exit+0x171/0x480
Aug 17 17:59:01 aurora kernel: [522967.086264]  [] ? 
__dequeue_signal+0x6a/0xb0
Aug 17 17:59:01 aurora kernel: [522967.086267]  [] 
do_group_exit+0x44/0xa0
Aug 17 17:59:01 aurora kernel: [522967.086271]  [] 
get_signal_to_deliver+0x22b/0x440
Aug 17 17:59:01 aurora kernel: [522967.086277]  [] 
do_signal+0x29/0x130
Aug 17 17:59:01 aurora kernel: [522967.086282]  [] ? 
do_futex+0x7c/0x1b0
Aug 17 17:59:01 aurora kernel: [522967.086288]  [] ? 
do_vfs_ioctl+0x8a/0x340
Aug 17 17:59:01 aurora kernel: [522967.086291]  [] ? 
sys_futex+0x147/0x1a0
Aug 17 17:59:01 aurora kernel: [522967.086295]  [] 
do_notify_resume+0x90/0xd0
Aug 17 17:59:01 aurora kernel: [522967.086300]  [] 
int_signal+0x12/0x17
Aug 17 17:59:01 aurora kernel: [522967.086303] INFO: task kvm:8403 blocked for 
more than 120 seconds.
Aug 17 17:59:01 aurora kernel: [522967.086625] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 17 17:59:01 aurora kernel: [522967.087050] kvm D 
8180cbe0 0  8403  1 0x
Aug 17 17:59:01 aurora kernel: [522967.087053]  881f7913bcd8 
0082  ffe0
Aug 17 17:59:01 aurora kernel: [522967.087058]  881f7913bfd8 
881f7913bfd8 881f7913bfd8 000139c0
Aug 17 17:59:01 aurora kernel: [522967.087062]  881f92db1700 
881c0cdf8000 881c0cdf8000 883f912d0a80
Aug 17 17:59:01 aurora kernel: [522967.087067] Call Trace:
Aug 17 17:59:01 aurora kernel: [522967.087071]  [] 
schedule+0x29/0x70
Aug 17 17:59:01 aurora kernel: [522967.087074]  [] 
exit_mm+0x85/0x130
Aug 17 17:59:01 aurora kernel: [522967.087077]  [] 
do_exit+0x171/0x480
Aug 17 17:59:01 aurora kernel: [522967.087081]  [] ? 
__dequeue_signal+0x6a/0xb0
Aug 17 17:59:01 aurora kernel: [522967.087084]  [] 
do_group_exit+0x44/0xa0
Aug 17 17:59:01 aurora kernel: [522967.087088]  [] 
get_signal_to_deliver+0x22b/0x440
Aug 17 17:59:01 aurora kernel: [522967.087092]  [] 
do_signal+0x29/0x130
Aug 17 17:59:01 aurora kernel: [522967.087095]  [] ? 
do_futex+0x7c/0x1b0
Aug 17 17:59:01 aurora kernel: [522967.087099]  [] ? 
do_vfs_ioctl+0x8a/0x340
Aug 17 17:59:01 aurora kernel: [522967.087102]  [] ? 
sys_futex+0x147/0x1a0
Aug 17 17:59:01 aurora kernel: [522967.087106]  [] 
do_notify_resume+0x90/0xd0
Aug 17 17:59:01 aurora kernel: [522967.087109]  [] 
int_signal+0x12/0x17
Aug 17 17:59:01 aurora kernel: [522967.087112] INFO: task kvm:17450 blocked for 
more than 120 seconds.
Aug 17 17:59:01 aurora kernel: [522967.087436] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 17 17:59:01 aurora kernel: [522967.098800] kvm D 
8180cbe0 0 17450  1 0x
Aug 17 17:59:01 aurora kernel

Re: Production Agent Disconnect

[Marty Sweet]

Following this up, I just found the following errors on my management
server. Very odd as they are resolved within the same second, ping.interval
= 5, ping.timeout (multiplier) = 2

Thanks again,
Marty

Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentMonitor] (Thread-6:) Found the following agents behind
on ping: [40, 27, 37, 38, 29, 39]
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-15:) Investigating why
host 40 has disconnected with event PingTimeout
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-8:) Investigating why host
27 has disconnected with event PingTimeout
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-4:) Investigating why host
37 has disconnected with event PingTimeout
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-5:) Investigating why host
38 has disconnected with event PingTimeout
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-16:) Investigating why
host 29 has disconnected with event PingTimeout
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-9:) Investigating why host
39 has disconnected with event PingTimeout
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-5:) The state determined
is Up
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-5:) Agent is determined to
be up and running
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-4:) The state determined
is Up
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-4:) Agent is determined to
be up and running
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-8:) The state determined
is Up
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-8:) Agent is determined to
be up and running
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-15:) The state determined
is Up
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-15:) Agent is determined
to be up and running
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-16:) The state determined
is Up
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-16:) Agent is determined
to be up and running
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-9:) The state determined
is Up
Aug 17 19:04:24 discovery jsvc.exec[31061]: INFO
 [agent.manager.AgentManagerImpl] (AgentTaskPool-9:) Agent is determined to
be up and running



On Sat, Aug 17, 2013 at 6:58 PM, Marty Sweet  wrote:

> Hi Guys,
>
> I have just had a VMHost randomly disconnect in production and
> subsequently take down some VMs.
> I have attached the logs (happened to be running agent trace on this
> node), but it would seem that the agent (or management?) waited 25 seconds
> before erroring, and then the cloudstack agent froze until 1800.
> I assume the agent syslog stack traces were caused by force closes of VMs,
> no other nodes were affected during this time period.
>
> While the host was in disconnect mode, I could connect to a VM which was
> running on that host, although Cloudstack was already reporting that is was
> down.
>  Would it be a good idea to ping VM's (their allocated IPs before
> attempting to start them on other nodes - especially in a HA setup)?
>
> If someone could look at the logs and let me know if there is something
> obvious it would be most appreciated, I have included the management bond
> for reference that the link didn't go down.
>
> Thanks in advance,
> Marty
>

Re: Easiest Way...

[Maurice Lawler]

Oh, in 4.2 -- will this only be available in advanced networking? Or both basic 
& advanced?

- Maurice


On Aug 17, 2013, at 3:56 AM, Venkata SwamyBabu Budumuru 
 wrote:

> Hi Maurice,
> 
> This piece is now automatically done by CloudStack 4.2 release. There is a
> feature called "secondary Ips / multiple Ips per NIC". You can have a look
> at the code to see what you need to exactly configure.
> 
> On 17/08/13 12:05 AM, "Maurice Lawler"  wrote:
> 
>> Greetings,
>> 
>> What is the easiest way to manipulate a script to allow a instance to get
>> a second IP address? I know it would require some fiddling with ebtables.
>> 
>> Please provide some additional information, and method to permit this
>> please.
>> 
>> - Maurice
> 

Re: [DISCUSS] Comments on html docs and apidocs

[Jessica Tomechak]

The problem with the comment feature on the old site wasn't simple neglect.
People posted mostly support questions, which should have been sent to the
-users list or the commercial support dept (both commercial and OSS users
shared the site).

The old site did have the capability to fwd comments to anyone's email
in-bin. The people cc'd may have neglected these emails, or may have
responded directly to the person without posting followups to the docs site
(in which case it would appear to someone like Sebastien that the commenter
was never helped).

The commenters were mostly people who seemingly weren't aware of the
already existing channels for getting technical help. Hardly anyone posted
any comments or questions about the docs themselves.

So, if we add this, it might turn out we just need to cc all the comments
to the -users and -dev lists, or wherever "help me!" questions should
ordinarily go.

Jessica T.


On Fri, Aug 16, 2013 at 4:37 AM, Radhika Puthiyetath <
radhika.puthiyet...@citrix.com> wrote:

> Personally, I liked the interface. One of my previous employers, an Open
> Source org, employed this system for the documentation site.
>
> If we have some mechanism in place to receive the comments in the Inbox of
> the author, even more awesome !
>
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, February 26, 2013 7:33 PM
> To: cloudstack-...@incubator.apache.org
> Subject: Re: [DISCUSS] Comments on html docs and apidocs
>
> On Tue, Feb 26, 2013 at 08:50:04AM -0500, Sebastien Goasguen wrote:
> >
> > On Feb 26, 2013, at 3:00 AM, David Nalley  wrote:
> >
> > > Hi folks,
> > >
> > > At the Barcamp before ApacheCon someone showed off the
> > > comments.apache.org system.
> > > Essentially it allows you to embed discussion threads in otherwise
> > > static documentation. Disqus is a similar commercial tool.
> > >
> > > I quickly generated the 4.1 APIDocs after adding the comment snippet
> > > to the base (and yes it will need some polish)
> > >
> > > You can try this out on the root admin api calls here (none of the
> > > domain admin or user api calls pages have the code):
> > > http://people.apache.org/~ke4qqq/apidocs
> > >
> > > In Example:
> > > http://people.apache.org/~ke4qqq/apidocs/root_admin/listNetworkOffer
> > > ings.html
> > >
> > > You can leave comments etc.
> > >
> > > We had a similar system on the old docs.cloudstack.org - and I was
> > > personally not a fan - people left messages/questions/etc; and
> > > received little or no response. This system has the ability to
> > > notify a mailing list (I know, another way of generating email :) )
> > > of each comment. And I'd personally be the first person to rip this
> > > out if it's neglected. Often times though, annotating existing
> > > documentation can be helpful. I'd consider this on the html docs on
> > > incubator.apache.org/cloudstack/docs as well if it works well on the
> > > API stuff.
> > >
> > > Thoughts?
> > > Do you think we can keep up with the comments? Push folks asking
> > > questions to the user list, cultivate the content, etc?
> >
> > Anyway to send the comments to JIRA on dedicated tickets for each api
> call ?
> >
>
> That might make this tolerable IMO.  I'm personally not interested in
> seeing a forum-style interface.  We are already managing too many
> interactions right now, and another one worries me.
>
> -chip
>

RE: regarding issues related ceph integration with cloudstack

[Animesh Chaturvedi]

Wido

Can you review and resolve 
https://issues.apache.org/jira/browse/CLOUDSTACK-4249 by Monday 8/19 morning 
PST in preparation for the RC

Animesh

> -Original Message-
> From: Wido den Hollander [mailto:w...@widodh.nl]
> Sent: Tuesday, August 13, 2013 12:34 PM
> To: dev@cloudstack.apache.org
> Subject: Re: regarding issues related ceph integration with cloudstack
> 
> Hi,
> 
> Thanks for the testing! I'll try to pick those up this week. Seems all
> like minor issue which can be resolved rather quickly.
> 
> Really appreciate the testing of the Ceph integration :)
> 
> Wido
> 
> On 08/13/2013 09:17 PM, Suresh Sadhu wrote:
> > HI All,
> >
> > I have noticed following issues during initial sanity testing .can
> > someone look into it. Volume migration recently addressed so not
> >   performed migration cases ,as I have used last week build for my
> > testing
> >
> > General observation about performance is :First time actions (like
> > first vm deployement, first time snapshot is )taking more time apprx 5
> > to 7 min)
> >
> > Description: Bug
> > 
> >
> >
> >
> > CLOUDSTACK-4304
> > 
> >
> >
> >
> > ceph:fail to attach a volume created from snapshot to same Instance
> > 
> >
> >
> >
> > /Unassigned/
> >
> >
> >
> > sadhu suresh
> > 
> >
> >
> >
> > Description: Major
> >
> >
> >
> > Description: OpenOpen
> >
> >
> >
> > /Unresolved/
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> >
> >
> > /Actions/
> >  > dOperations?atl_token=A5KQ-2QAV-T4JA-FDED%7C92a89310cd3662fb398c819927
> > 64c9026e7db73f%7Clin>
> >
> > Description: Bug
> > 
> >
> >
> >
> > CLOUDSTACK-4301
> > 
> >
> >
> >
> > ceph:KVM:create volume from snapshot failing with Runtime exception
> > 
> >
> >
> >
> > /Unassigned/
> >
> >
> >
> > sadhu suresh
> > 
> >
> >
> >
> > Description: Critical
> >
> >
> >
> > Description: OpenOpen
> >
> >
> >
> > /Unresolved/
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> >
> >
> > /Actions/
> >  > dOperations?atl_token=A5KQ-2QAV-T4JA-FDED%7C92a89310cd3662fb398c819927
> > 64c9026e7db73f%7Clin>
> >
> > Description: Bug
> > 
> >
> >
> >
> > CLOUDSTACK-4297
> > 
> >
> >
> >
> > ceph:request to add support for zonewide prmary storage.
> > 
> >
> >
> >
> > /Unassigned/
> >
> >
> >
> > sadhu suresh
> > 
> >
> >
> >
> > Description: Major
> >
> >
> >
> > Description: OpenOpen
> >
> >
> >
> > /Unresolved/
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> >
> >
> > /Actions/
> >  > dOperations?atl_token=A5KQ-2QAV-T4JA-FDED%7C92a89310cd3662fb398c819927
> > 64c9026e7db73f%7Clin>
> >
> > Description: Bug
> > 
> >
> >
> >
> > CLOUDSTACK-4292
> > 
> >
> >
> >
> > ceph:destroyedvm failed with ArrayIndexexception while expunging
> > 
> >
> >
> >
> > /Unassigned/
> >
> >
> >
> > sadhu suresh
> > 
> >
> >
> >
> > Description: Critical
> >
> >
> >
> > Description: OpenOpen
> >
> >
> >
> > /Unresolved/
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> >
> >
> > /Actions/
> >  > dOperations?atl_token=A5KQ-2QAV-T4JA-FDED%7C92a89310cd3662fb398c819927
> > 64c9026e7db73f%7Clin>
> >
> > Description: Bug
> > 
> >
> >
> >
> > CLOUDSTACK-4278
> > 
> >
> >
> >
> > ceph:volumeresize failed with Internal error(Nullpointer exception)
> > 
> >
> >
> >
> > /Unassigned/
> >
> >
> >
> > sadhu suresh
> > 
> >
> >
> >
> > Description: Major
> >
> >
> >
> > Description: OpenOpen
> >
> >
> >
> > /Unresolved/
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> > 13/Aug/13
> >
> >
> >
> >
> >
> > /Actions/
> > 

Re: Building Documents with publican

[Jessica Tomechak]

The specific problem this time is building from the en-US directory. You
need to be in the directory above that before issuing the publican build
command. That is: the directory where all the *.cfg files are located.
That's why Publican complained it couldn't find the .cfg file.

Most recent Publican user guide:

http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Users_Guide/

An older one: (not sure what version of Publican ACS is using):

http://jfearn.fedorapeople.org/en-US/Publican/2.0/html/Users_Guide/

I hope this information is helpful.

Jessica T.


On Thu, Aug 15, 2013 at 9:58 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I'm new to Publican, as well.
>
> When I run the following:
>
> c:\docs\en-US>publican build --formats=test --langs=en-US
>
> I get the following error message:
>
> Config file not found: publican.cfg. at script/publican line 689
>
> Unfortunately I don't know much about Publican. I'm just trying to document
> the storage plug-in I developed for 4.2. :)
>
> Any thoughts on this one?
>
> Thanks!
>
>
> On Thu, Aug 15, 2013 at 12:31 AM, Prasanna Santhanam 
> wrote:
>
> > On jenkins this is what is used:
> >
> > cp -R /usr/share/publican/Common_Content Common_Content
> > cp -R docs/publican-cloudstack Common_Content/cloudstack
> > (cd docs && publican build --config=publican-adminguide.cfg --formats
> > html,pdf --langs en-US --common_content=./Common_Content)
> > for format in html ; do tar cjf
> > "cloudstack-adminguide-en-US-$format.tar.bz2" -C
> "docs/tmp/en-US/$format" .
> > ; done
> > cp docs/tmp/en-US/pdf/* .
> >
> >
> > On Thu, Aug 15, 2013 at 07:22:32AM +0100, Marty Sweet wrote:
> > > Hi Jessica,
> > >
> > > Should I try to fix these errors? I can't see any build tests on
> Jenkins
> > > which are failing but that does seem to be looking at another source,
> > where
> > > is this picked up from?
> > >
> > > Thanks,
> > > Marty
> > >
> > > On Wednesday, August 14, 2013, Jessica Tomechak wrote:
> > >
> > > > Marty,
> > > > These errors are caused by files being included in the docs twice as
> > well
> > > > as links pointing to destinations that aren't included in the same
> > book. I
> > > > have a page on this in the project wiki.
> > > >
> > > >
> > > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Publican+Troubleshooting+Guide
> > > >
> > > > In the end, the root cause is people adding/changing things in the
> docs
> > > > repo without doing a test build locally in publican first.
> > > >
> > > > Jessica T.
> > > > 
> > > > From: Marty Sweet [msweet@gmail.com ]
> > > > Sent: Wednesday, August 14, 2013 11:18 AM
> > > > To: dev@cloudstack.apache.org 
> > > > Subject: Building Documents with publican
> > > >
> > > > Hi,
> > > >
> > > > I am trying to build the documentation from the latest git pull.
> After
> > > > running the following, lots of processing file entries appear, then
> the
> > > > following errors:
> > > >
> > > > marty@devbox:~/workspace/cloudstack/docs$ publican build --formats
> > html
> > > > --langs en-US
> > > > --common_content=/home/marty/workspace/cloudstack/Common_Content
> > > > Setting up en-US
> > > > Processing file tmp/en-US/xml/Common_Content/Conventions.xml ->
> > > > tmp/en-US/xml/Common_Content/Conventions.xml
> > > > Processing file tmp/en-US/xml/Common_Content/Feedback.xml ->
> > > > tmp/en-US/xml/Common_Content/Feedback.xml
> > > > Processing file tmp/en-US/xml_tmp/xenserver-topology-req.xml ->
> > > > tmp/en-US/xml/xenserver-topology-req.xml
> > > > Processing file tmp/en-US/xml_tmp/zone-add.xml ->
> > > > tmp/en-US/xml/zone-add.xml
> > > >
> > > > Beginning work on en-US
> > > > Validation failed:
> > > > hypervisor-support-for-primarystorage.xml:6: validity error : ID
> > > > hypervisor-support-for-primarystorage already defined
> > > > add-remove-nic.xml:31: validity error : ID prereq-addnic already
> > defined
> > > > api-throttling.xml:6: validity error : ID api-throttling already
> > defined
> > > > api-throttling.xml:30: validity error : ID api-throttling-configure
> > already
> > > > defined
> > > > api-throttling.xml:61: validity error : ID api-throttling-limitations
> > > > already defined
> > > > globally-configured-limits.xml:6: validity error : ID
> > > > globally-configured-limits already defined
> > > > configure-package-repository.xml:28: validity error : IDREF attribute
> > > > linkend references an unknown ID "sect-source-builddebs"
> > > > management-server-install-multi-node.xml:30: validity error : IDREF
> > > > attribute linkend references an unknown ID "sect-source-builddebs"
> > > > using-netscaler-load-balancers.xml:41: validity error : IDREF
> attribute
> > > > linkend references an unknown ID "external-guest-lb-integration"
> > > > configure-package-repository.xml:28: validity error : IDREF attribute
> > > > linkend references an unknown ID "sect-source-buildrpm"
> > > > management-server-install-multi-node.xml:30: validity error : ID

Re: Building Documents with publican

[Mike Tutkowski]

Thanks...I was able to fix the problems I had and was able to commit my
changes.


On Sat, Aug 17, 2013 at 3:34 PM, Jessica Tomechak <
jessica.tomec...@gmail.com> wrote:

> The specific problem this time is building from the en-US directory. You
> need to be in the directory above that before issuing the publican build
> command. That is: the directory where all the *.cfg files are located.
> That's why Publican complained it couldn't find the .cfg file.
>
> Most recent Publican user guide:
>
> http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Users_Guide/
>
> An older one: (not sure what version of Publican ACS is using):
>
> http://jfearn.fedorapeople.org/en-US/Publican/2.0/html/Users_Guide/
>
> I hope this information is helpful.
>
> Jessica T.
>
>
> On Thu, Aug 15, 2013 at 9:58 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > I'm new to Publican, as well.
> >
> > When I run the following:
> >
> > c:\docs\en-US>publican build --formats=test --langs=en-US
> >
> > I get the following error message:
> >
> > Config file not found: publican.cfg. at script/publican line 689
> >
> > Unfortunately I don't know much about Publican. I'm just trying to
> document
> > the storage plug-in I developed for 4.2. :)
> >
> > Any thoughts on this one?
> >
> > Thanks!
> >
> >
> > On Thu, Aug 15, 2013 at 12:31 AM, Prasanna Santhanam 
> > wrote:
> >
> > > On jenkins this is what is used:
> > >
> > > cp -R /usr/share/publican/Common_Content Common_Content
> > > cp -R docs/publican-cloudstack Common_Content/cloudstack
> > > (cd docs && publican build --config=publican-adminguide.cfg --formats
> > > html,pdf --langs en-US --common_content=./Common_Content)
> > > for format in html ; do tar cjf
> > > "cloudstack-adminguide-en-US-$format.tar.bz2" -C
> > "docs/tmp/en-US/$format" .
> > > ; done
> > > cp docs/tmp/en-US/pdf/* .
> > >
> > >
> > > On Thu, Aug 15, 2013 at 07:22:32AM +0100, Marty Sweet wrote:
> > > > Hi Jessica,
> > > >
> > > > Should I try to fix these errors? I can't see any build tests on
> > Jenkins
> > > > which are failing but that does seem to be looking at another source,
> > > where
> > > > is this picked up from?
> > > >
> > > > Thanks,
> > > > Marty
> > > >
> > > > On Wednesday, August 14, 2013, Jessica Tomechak wrote:
> > > >
> > > > > Marty,
> > > > > These errors are caused by files being included in the docs twice
> as
> > > well
> > > > > as links pointing to destinations that aren't included in the same
> > > book. I
> > > > > have a page on this in the project wiki.
> > > > >
> > > > >
> > > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Publican+Troubleshooting+Guide
> > > > >
> > > > > In the end, the root cause is people adding/changing things in the
> > docs
> > > > > repo without doing a test build locally in publican first.
> > > > >
> > > > > Jessica T.
> > > > > 
> > > > > From: Marty Sweet [msweet@gmail.com ]
> > > > > Sent: Wednesday, August 14, 2013 11:18 AM
> > > > > To: dev@cloudstack.apache.org 
> > > > > Subject: Building Documents with publican
> > > > >
> > > > > Hi,
> > > > >
> > > > > I am trying to build the documentation from the latest git pull.
> > After
> > > > > running the following, lots of processing file entries appear, then
> > the
> > > > > following errors:
> > > > >
> > > > > marty@devbox:~/workspace/cloudstack/docs$ publican build --formats
> > > html
> > > > > --langs en-US
> > > > > --common_content=/home/marty/workspace/cloudstack/Common_Content
> > > > > Setting up en-US
> > > > > Processing file tmp/en-US/xml/Common_Content/Conventions.xml ->
> > > > > tmp/en-US/xml/Common_Content/Conventions.xml
> > > > > Processing file tmp/en-US/xml/Common_Content/Feedback.xml ->
> > > > > tmp/en-US/xml/Common_Content/Feedback.xml
> > > > > Processing file tmp/en-US/xml_tmp/xenserver-topology-req.xml ->
> > > > > tmp/en-US/xml/xenserver-topology-req.xml
> > > > > Processing file tmp/en-US/xml_tmp/zone-add.xml ->
> > > > > tmp/en-US/xml/zone-add.xml
> > > > >
> > > > > Beginning work on en-US
> > > > > Validation failed:
> > > > > hypervisor-support-for-primarystorage.xml:6: validity error : ID
> > > > > hypervisor-support-for-primarystorage already defined
> > > > > add-remove-nic.xml:31: validity error : ID prereq-addnic already
> > > defined
> > > > > api-throttling.xml:6: validity error : ID api-throttling already
> > > defined
> > > > > api-throttling.xml:30: validity error : ID api-throttling-configure
> > > already
> > > > > defined
> > > > > api-throttling.xml:61: validity error : ID
> api-throttling-limitations
> > > > > already defined
> > > > > globally-configured-limits.xml:6: validity error : ID
> > > > > globally-configured-limits already defined
> > > > > configure-package-repository.xml:28: validity error : IDREF
> attribute
> > > > > linkend references an unknown ID "sect-source-builddebs"
> > > > > management-server-install-multi-node.xml:30: validity error : IDREF
> > > > 

RE: [Doc] Default Password Encoding Mechanism, SHA256Salt, Doc for Review

[Vijayendra Bhamidipati]

Hi Radhika,

A few corrections need to be made:

1)

"A new configurable list called UserPasswordEncoders to allow you to separately 
configure the order of preference for encoding and authentication schemes."

Please change the above line to:

"Two new configurable lists have been introduced - userPasswordEncoders to 
allow you to configure the order of preference for encoding passwords, and 
userAuthenticators to allow you to configure the order in which authentication 
schemes are invoked to validate user passwords".


2)
"Additionally, plain text user authenticator has been changed to use SHA256SALT 
as the default encoding algorithm because it is more secure compared to MD5 
hashing."

Please change the above line to:

"Additionally, the plain text user authenticator has been modified not to 
convert supplied passwords to their md5 sums before checking them with the db 
entries."


3)
When I had checked in the code for this feature as part of commit # 
2dbdc46337be375940441ac4b41f95f25bbbf21d, I had defined the above lists in 
applicationContext.xml, instead of having them separately defined in both 
componentContext.xml and nonossComponentContext.xml - but they've been moved 
back into these files, so now the explanation should explicitly state that if 
nonoss components like vmware environments are to be deployed, the 
userPasswordEncoders and userAuthenticators lists need to be modified in the 
nonossComponentContext.xml file, or otherwise, for oss environments like 
XenServer or KVM etc, the ComponentContext.xml file. Please add a sentence or 
two to this effect after this sentence: "The order of authentication schemes is 
determined by the UserAuthenticators property in the same files." Please also 
add that it is recommended to make uniform changes across both files. Please 
also make changes to the other sentences that refer to either of these files, 
accordingly.


Rest all looks good.


Thanks!
Regards,
Vijay.

From: Radhika Puthiyetath
Sent: Thursday, August 08, 2013 1:52 AM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org; Vijayendra 
Bhamidipati; Sudha Ponnaganti
Subject: [Doc] Default Password Encoding Mechanism, SHA256Salt, Doc for Review

Hi,

Default Password Encoding Mechanism, SHA256Salt, Doc is ready for review. The 
doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-1815.

Please provide your feedback.


Regards
-Radhika

Re: Easiest Way...

[Venkata SwamyBabu Budumuru]

It is available for both advanced and basic.

On 18/08/13 12:55 AM, "Maurice Lawler"  wrote:

>Oh, in 4.2 -- will this only be available in advanced networking? Or both
>basic & advanced?
>
>- Maurice
>
>
>On Aug 17, 2013, at 3:56 AM, Venkata SwamyBabu Budumuru
> wrote:
>
>> Hi Maurice,
>> 
>> This piece is now automatically done by CloudStack 4.2 release. There
>>is a
>> feature called "secondary Ips / multiple Ips per NIC". You can have a
>>look
>> at the code to see what you need to exactly configure.
>> 
>> On 17/08/13 12:05 AM, "Maurice Lawler"  wrote:
>> 
>>> Greetings,
>>> 
>>> What is the easiest way to manipulate a script to allow a instance to
>>>get
>>> a second IP address? I know it would require some fiddling with
>>>ebtables.
>>> 
>>> Please provide some additional information, and method to permit this
>>> please.
>>> 
>>> - Maurice
>> 
>

[ACS42] Issues tht need to bre resolved for RC on Monday 8/19

[Animesh Chaturvedi]

This is the list of unresolved blocker and critical that need to be addressed 
for ACS 4.2 RC on Monday


| Assignee | Issue ID: Summary  

|
| Bharat Kumar | CLOUDSTACK-4132 : current dnsmasq config does not 
allow guest virtual machines(clients) to update its hostnames with a DNS server 
 |
| Devdeep Singh| CLOUDSTACK-4372 : [XenServer] Commands info which are 
executed via xenserver are not logged in SMlog  
 |
| Jayapal Reddy| CLOUDSTACK-4176 : [XenServer] Nic not unplugged after 
all IPs are released
 |
| Kelven Yang  | CLOUDSTACK-4357 : [Automation] Failed to create 
snapshot in vmware, failed with SOAP Exception  
   |
| Kelven Yang  | CLOUDSTACK-4358 : [Automation] [vmware] Few VM 
deployment failed with IndexOutOfBoundsException at 
"VolumeManagerImpl.java:2534"   |
| Kelven Yang  | CLOUDSTACK-4376 : [Automation] [vmware] Failed to 
deploy VPC router in parallel deployment scenario   
 |
| Kelven Yang  | CLOUDSTACK-4363 : [VMware]Migration of data volume is 
throwing NPE
 |
| Koushik Das  | CLOUDSTACK-3441 : [Load Test] High delays between VM 
being allocated to Pod and network implementation causing delays in VM 
deployment |
| Koushik Das  | CLOUDSTACK-4350 : [Performance Testing] Adding hosts 
take much longer time than baselines
  |
| Mice Xia | CLOUDSTACK-3234 : [VM_Snapshot] Starting VM fails if 
VM snapshot is created from the VM  
  |
| Prachi Damle | CLOUDSTACK-4378 : [Automation] [Regression] Affinity 
group test cases failed during VM deployment
  |
| Radhika Nair | CLOUDSTACK-3765 : [packaging][document] unable to 
upgrade cp 4.2 build on centos5.5   
 |
| Rajesh Battala   | CLOUDSTACK-4237 : [Autoscale] Account deletion doesn't 
delete all autoscaled LB rules created by the account   
|
| Rayees Namathponnan  | CLOUDSTACK-4370 : [packaging]unable to upgrade cp 4.2 
build on centos5.5  
 |
| Sateesh Chodapuneedi | CLOUDSTACK-4294 : After upgrade of CloudStack to 4.2, 
support old vswitch type in existing clusters if user changes the vswitch 
backend to another type of vSwitch |
| Sateesh Chodapuneedi | CLOUDSTACK-4362 : VM's are failing to start after its 
DATA volume is migrated to second zone wide primary storage 
 |
| Sateesh Chodapuneedi | CLOUDSTACK-4368 : UI: when source and destination 
hosts are in different cluster UI is not calling properAPI  
 |
| Sateesh Chodapuneedi | CLOUDSTACK-4375 : VM Migration is failing from one 
cluster to another cluster. 
|
| Unassigned   | CLOUDSTACK-4380 : [UPGRADE]Upgrade failed from 307 to 
4.2 (MySQLSyntaxErrorException: Table 'external_nicira_nvp_devices' already 
exists)  |
| Unassigned   | CLOUDSTACK-3138 : Flaws in upgrade documentation from 
3.0.2 -> 4.1.0  
 |
| Unassigned   | CLOUDSTACK-4081 : [DOC]Fresh install of cloud platform 
failed with dependency errors on centos5.5 OS   
|
| Unassigned   | CLOUDSTACK-4249 : [KVM]ceph:showing wrong template 
size 755.64 TB(template created from snapshot)  
|


Wido can you check on CLOUDSTACK:4249?