[GitHub] cloudstack pull request: CLOUDSTACK-8891: Fixed default iptables r...

[jayapalu]

Github user jayapalu commented on the pull request:

https://github.com/apache/cloudstack/pull/867#issuecomment-142837601
  
@wido updated the patch. Deleted the log.


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

Re: [Blocker] Egress rules are not configured in VR

[Jayapal Reddy Uradi]

I am working on it.

-Jayapal
> On 24-Sep-2015, at 11:52 am, Raja Pullela  wrote:
> 
> Hi,
> 
> 
> 
> Hopefully this will be the last Blocker on the VR functionality ?
> 
> Can someone please pick this bug – ASAP ?
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-8905
> 
> 
> 
> best,
> 
> Raja

VR refactoring, concerns and a way out ?

[Raja Pullela]

Hi,



I understand a concern on the VR changes was raised earlier.  My apologies to 
restart this thread again.



However, my last conversation with Jayapal, who has fixed/have been fixing lot 
of VR issues, about the VR issues and he is pretty concerned about the 
refactoring that has happened.  I have had the same concern for sometime now  
(VR issues have been on the list of issues to be looked into for at least 4+ 
weeks) and wanted to see a good solution for this- with VR being very 
fundamental to the system.



Couple of solutions/proposals –

1)  Back out the VR changes – Pros: VR has been stable for some time and it 
is working well.

2)  Continue to fix/stability VR changes -   Concerns: is the unknowns, 
what we will find out and how long this will take to stabilize the VR 
functionality.



Please chime in if you have any thoughts or concerns around this,



best,

Raja

[GitHub] cloudstack pull request: CLOUDSTACK-8848: extra state to handle; n...

[resmo]

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/829#issuecomment-142882541
  
@anshul1886 @koushik-das 
@DaanHoogland  and I  had a debug session last friday, and since he is off 
for the next couple of days I can give you more details about we analysed. 

The powerReportMissing is not the problem, it is only the trigger. The 
graceful period is the problem. The calculation of this period is relaying (see 
https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachinePowerStateSyncImpl.java#L114)
 on the field `update_time` in table `vm_instance`. But if I look at the value  
it seems it doesn't get updated. So the grace period has most likely always 
passed. 

I tried to do a workaround doing the following, I ran an update sql for 
every 5 seconds which updated the `update_time` for my router r-342 which I was 
migrating around esx cluster nodes:
~~~
 mysql -e 'update cloud.vm_instance set update_time=NOW() where id=342;'
~~~
And the router didn't get rebooted:
~~~
2015-09-24 11:47:07,685 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-218:ctx-5849bd19) VM state report. host: 25, vm id: 342, 
power state: PowerOn
2015-09-24 11:47:07,696 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-218:ctx-5849bd19) VM state report is updated. host: 25, vm 
id: 342, power state: PowerOn
2015-09-24 11:48:06,462 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-55:ctx-84cd4323) VM state report. host: 19, vm id: 342, 
power state: PowerOn
2015-09-24 11:48:06,471 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-55:ctx-84cd4323) VM state report is updated. host: 19, vm 
id: 342, power state: PowerOn
2015-09-24 11:48:06,493 WARN  [o.a.c.alerts] 
(DirectAgentCronJob-55:ctx-84cd4323)  alertType:: 9 // dataCenterId:: 1 // 
podId:: 1 // clusterId:: null // message:: Router has been migrated out of 
band: r-342-VM
2015-09-24 11:49:06,539 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-29:ctx-2a57d676) Detected missing VM. host: 19, vm id: 342, 
power state: PowerReportMissing, last state update: 1443095344000
2015-09-24 11:49:06,539 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-29:ctx-2a57d676) vm id: 342 - time since last state 
update(-7197461ms) has not passed graceful period yet
2015-09-24 11:49:07,719 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-444:ctx-fdd4c055) VM state report. host: 20, vm id: 342, 
power state: PowerOn
~~~

Which means this patch is not fix the root cause. To me the root cause is 
that `update_time` is not updated or the gracePeriod calculation is wrong.

Any thoughts?


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

[GitHub] cloudstack pull request: CLOUDSTACK-8848: extra state to handle; n...

[anshul1886]

Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/829#issuecomment-142899514
  
From code it seems to be getting updated and DB also suggests that. It will 
not be updated if there is no power change for 
MAX_CONSECUTIVE_SAME_STATE_UPDATE_COUNT. But that is to reduce DB transactions 
and will not create issues as it is updated if there is change in power state.

Grace period can be increased by increasing ping interval. By default it is 
60 seconds. You can increase it to 90 or 120 seconds to increase the grace 
period.

Code which is doing update 

for (Map.Entry entry : 
translatedInfo.entrySet()) {

if (s_logger.isDebugEnabled())
s_logger.debug("VM state report. host: " + hostId + ", vm 
id: " + entry.getKey() + ", power state: " + entry.getValue());

if (_instanceDao.updatePowerState(entry.getKey(), hostId, 
entry.getValue())) {
if (s_logger.isDebugEnabled())
s_logger.debug("VM state report is updated. host: " + 
hostId + ", vm id: " + entry.getKey() + ", power state: " + entry.getValue());



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

[GitHub] cloudstack pull request: CLOUDSTACK-8848: extra state to handle; n...

[anshul1886]

Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/829#issuecomment-142903425
  
This simply means that there power_state has not changed for that period of 
time. As I pointed out in my previous comment that if state is consecutively 
updated with same power state thrice then we don't update state. If its state 
gets changed then only we update it. So I am assuming for these routers 
power_state_update_count is 3. 


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

[GitHub] cloudstack pull request: CLOUDSTACK-8848: extra state to handle; n...

[resmo]

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/829#issuecomment-142901959
  
Increasing the grace period for a few minutes won't help. If you look at 
these update_time values I queried from 10 running routers, you see these are 
days, weeks behind.
~~~
mysql> select instance_name, type, update_time from vm_instance where 
instance_name like 'r-%' and removed is NULL and state = 'Running' limit 10\G;
*** 1. row ***
instance_name: r-2978-VM
 type: DomainRouter
  update_time: 2015-08-24 21:54:42
*** 2. row ***
instance_name: r-3650-VM
 type: DomainRouter
  update_time: 2015-08-24 22:23:53
*** 3. row ***
instance_name: r-3651-VM
 type: DomainRouter
  update_time: 2015-08-26 00:57:40
*** 4. row ***
instance_name: r-3652-VM
 type: DomainRouter
  update_time: 2015-09-17 06:44:14
*** 5. row ***
instance_name: r-3653-VM
 type: DomainRouter
  update_time: 2015-08-24 22:18:43
*** 6. row ***
instance_name: r-3654-VM
 type: DomainRouter
  update_time: 2015-09-17 06:44:11
*** 7. row ***
instance_name: r-3655-VM
 type: DomainRouter
  update_time: 2015-09-15 05:34:30
*** 8. row ***
instance_name: r-3656-VM
 type: DomainRouter
  update_time: 2015-08-24 21:53:57
*** 9. row ***
instance_name: r-3657-VM
 type: DomainRouter
  update_time: 2015-08-24 22:33:40
*** 10. row ***
instance_name: r-3659-VM
 type: DomainRouter
  update_time: 2015-08-26 00:33:54
10 rows in set (0.01 sec)
~~~

But not updating the powerState (which would also update the update_date I 
assume) results in the gracePeriod uses a update_time weeks, months back.



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

[GitHub] cloudstack pull request: CLOUDSTACK-8905: Fixed hooking egress rul...

[jayapalu]

GitHub user jayapalu opened a pull request:

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

CLOUDSTACK-8905: Fixed hooking egress rules

Added hooking the FIREWALL_EGRESS_RULES chain into FW_OUTBOUND chain.
With this egress rules will effective.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jayapalu/cloudstack CLOUDSTACK-8905

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/881.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #881


commit 2bf7fb4b63932d80f641462073c751f07ab0c3ea
Author: Jayapal 
Date:   2015-09-24T11:36:11Z

CLOUDSTACK-8905: Fixed hooking egress rules




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

[GitHub] cloudstack pull request: CLOUDSTACK-8848: extra state to handle; n...

[resmo]

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/829#issuecomment-142906721
  
This is perfectly clear to me. The problem is we are relaying on the 
`update_time` (not to mix up with `power_state_update_time`).

~~~
*** 1. row ***
   instance_name: r-2978-VM
type: DomainRouter
 update_time: 2015-08-24 21:54:42
 power_state_update_time: 2015-09-09 08:30:42
power_state_update_count: 3
1 row in set (0.00 sec)
~~~

here
~~~java
// 2 times of sync-update interval for graceful period
long milliSecondsGracefullPeriod = PingInterval.value() * 2000L;

for (VMInstanceVO instance : vmsThatAreMissingReport) {

Date vmStateUpdateTime = instance.getUpdateTime();
//...
long milliSecondsSinceLastStateUpdate = 
currentTime.getTime() - vmStateUpdateTime.getTime();

if (milliSecondsSinceLastStateUpdate > 
milliSecondsGracefullPeriod) {
~~~ 

so this calculation would do this:
~~~
milliSecondsSinceLastStateUpdate = currentTime.getTime() - 
vmStateUpdateTime.getTime() 
2015-09-24 13:46:48 - 2015-08-24 21:54:42 ~= 1 month

if (1 month > 2 minutes grace period)
~~~

still the opinion, increasing grace period would help?


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

[GitHub] cloudstack pull request: CLOUDSTACK-8881: Fixed Static and PF conf...

[jayapalu]

GitHub user jayapalu opened a pull request:

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

CLOUDSTACK-8881: Fixed Static and PF configuration issue

1. For static nat filter rules are not configured in VR.
2. Corrected vm ip in PF rule.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jayapalu/cloudstack CLOUDSTACK-8881

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/882.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #882


commit 40138d2e994458250b8db706be993d4b040f95ca
Author: Jayapal 
Date:   2015-09-24T11:52:29Z

CLOUDSTACK-8881: Fixed Static and PF configuration issue




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

[GitHub] cloudstack pull request: CLOUDSTACK-8848: extra state to handle; n...

[anshul1886]

Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/829#issuecomment-142909650
  
Yes, increasing time should help. 


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

RE: VR refactoring, concerns and a way out ?

[Ramanath Katru]

My vote is for the approach no.1 - to backout completely. Most of VR 
functionalities are broken and are in a mess to say the least. It definitely 
will take some time and effort from several folks to get it to a stable state.

Ram Katru


-Original Message-
From: Raja Pullela [mailto:raja.pull...@citrix.com] 
Sent: Thursday, September 24, 2015 2:06 PM
To: dev@cloudstack.apache.org
Subject: VR refactoring, concerns and a way out ? 

Hi,



I understand a concern on the VR changes was raised earlier.  My apologies to 
restart this thread again.



However, my last conversation with Jayapal, who has fixed/have been fixing lot 
of VR issues, about the VR issues and he is pretty concerned about the 
refactoring that has happened.  I have had the same concern for sometime now  
(VR issues have been on the list of issues to be looked into for at least 4+ 
weeks) and wanted to see a good solution for this- with VR being very 
fundamental to the system.



Couple of solutions/proposals –

1)  Back out the VR changes – Pros: VR has been stable for some time and it 
is working well.

2)  Continue to fix/stability VR changes -   Concerns: is the unknowns, 
what we will find out and how long this will take to stabilize the VR 
functionality.



Please chime in if you have any thoughts or concerns around this,



best,

Raja

[GitHub] cloudstack pull request: CLOUDSTACK-8848: extra state to handle; n...

[resmo]

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/829#issuecomment-142912573
  
Cloud you follow my explanations? If this would help, I must set the ping 
interval to a year or somewhat identical. Are you REALLY followed my 
explanations? What did I miss?


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

Re: VR refactoring, concerns and a way out ?

[Sebastien Goasguen]

> On Sep 24, 2015, at 2:00 PM, Ramanath Katru  wrote:
> 
> My vote is for the approach no.1 - to backout completely. Most of VR 
> functionalities are broken and are in a mess to say the least. It definitely 
> will take some time and effort from several folks to get it to a stable state.
> 

So which VR changes are we talking about. If it was merged it should mean that 
tests passed and it worked at least in a controlled environment.

> Ram Katru
> 
> 
> -Original Message-
> From: Raja Pullela [mailto:raja.pull...@citrix.com] 
> Sent: Thursday, September 24, 2015 2:06 PM
> To: dev@cloudstack.apache.org
> Subject: VR refactoring, concerns and a way out ? 
> 
> Hi,
> 
> 
> 
> I understand a concern on the VR changes was raised earlier.  My apologies to 
> restart this thread again.
> 
> 
> 
> However, my last conversation with Jayapal, who has fixed/have been fixing 
> lot of VR issues, about the VR issues and he is pretty concerned about the 
> refactoring that has happened.  I have had the same concern for sometime now  
> (VR issues have been on the list of issues to be looked into for at least 4+ 
> weeks) and wanted to see a good solution for this- with VR being very 
> fundamental to the system.
> 
> 
> 
> Couple of solutions/proposals –
> 
> 1)  Back out the VR changes – Pros: VR has been stable for some time and 
> it is working well.
> 
> 2)  Continue to fix/stability VR changes -   Concerns: is the unknowns, 
> what we will find out and how long this will take to stabilize the VR 
> functionality.
> 
> 
> 
> Please chime in if you have any thoughts or concerns around this,
> 
> 
> 
> best,
> 
> Raja

Re: VR refactoring, concerns and a way out ?

[Wilder Rodrigues]

Raja,

A nice way out would be to have more people knowing about coding and git. I 
have no idea from where you got this non-sense approach, but I would say it can 
be compared with the previous git flow the community had: not tests; no PRs; no 
review.

@Ramanath: you, and many others, should have pitched in when the code was 
merged, months ago, and when effort to help testing was requested.

To sum it up: it’s easy to sit-down and wait for other people to work on 
features/test/fixes.

Cheers,
Wilder


> On 24 Sep 2015, at 14:33, Sebastien Goasguen  wrote:
> 
> 
>> On Sep 24, 2015, at 2:00 PM, Ramanath Katru  
>> wrote:
>> 
>> My vote is for the approach no.1 - to backout completely. Most of VR 
>> functionalities are broken and are in a mess to say the least. It definitely 
>> will take some time and effort from several folks to get it to a stable 
>> state.
>> 
> 
> So which VR changes are we talking about. If it was merged it should mean 
> that tests passed and it worked at least in a controlled environment.
> 
>> Ram Katru
>> 
>> 
>> -Original Message-
>> From: Raja Pullela [mailto:raja.pull...@citrix.com] 
>> Sent: Thursday, September 24, 2015 2:06 PM
>> To: dev@cloudstack.apache.org
>> Subject: VR refactoring, concerns and a way out ? 
>> 
>> Hi,
>> 
>> 
>> 
>> I understand a concern on the VR changes was raised earlier.  My apologies 
>> to restart this thread again.
>> 
>> 
>> 
>> However, my last conversation with Jayapal, who has fixed/have been fixing 
>> lot of VR issues, about the VR issues and he is pretty concerned about the 
>> refactoring that has happened.  I have had the same concern for sometime now 
>>  (VR issues have been on the list of issues to be looked into for at least 
>> 4+ weeks) and wanted to see a good solution for this- with VR being very 
>> fundamental to the system.
>> 
>> 
>> 
>> Couple of solutions/proposals –
>> 
>> 1)  Back out the VR changes – Pros: VR has been stable for some time and 
>> it is working well.
>> 
>> 2)  Continue to fix/stability VR changes -   Concerns: is the unknowns, 
>> what we will find out and how long this will take to stabilize the VR 
>> functionality.
>> 
>> 
>> 
>> Please chime in if you have any thoughts or concerns around this,
>> 
>> 
>> 
>> best,
>> 
>> Raja
> 

Building cloudstack failing on windows

[Sudharma Jain]

Hi,

While building cloudstack on windows, LocalTemplateDownloaderTest fails.

java.lang.AssertionError: Failed download
at org.junit.Assert.fail(Assert.java:88)
at
com.cloud.storage.template.LocalTemplateDownloaderTest.localTemplateDownloaderTest(LocalTemplateDownloaderTest.java:37)


Thanks,
Sudharma

[GitHub] cloudstack pull request: Strongswan vpn feature

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/872#issuecomment-142919266
  
@remibergsma @karuturi VPN is sort of broken for 4.5 and below, should we 
include this in 4.6 if this passes tests and review?


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

[GitHub] cloudstack pull request: CLOUDSTACK-8906: /var/log/cloud/ doesn't ...

[SudharmaJain]

GitHub user SudharmaJain opened a pull request:

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

CLOUDSTACK-8906: /var/log/cloud/ doesn't get logrotated on xenserver

After integrating XS with CCP the following folder gets created: 
/var/log/cloud/ however the logs in that are not rotated resulting in root file 
system fill up. It was a known issue and link 
http://support.citrix.com/article/CTX138064 describes the issue and solution. 
Used the article and added corresponding changes to Cloudstack. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SudharmaJain/cloudstack cs-8906

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/883.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #883


commit ffc786f40317c05e0a9b2b3ccd47fee21e1f76bb
Author: SudharmaJain 
Date:   2015-09-24T12:34:38Z

CLOUDSTACK-8906: /var/log/cloud/ doesn't get logrotated on xenserver




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

[GitHub] cloudstack pull request: CLOUDSTACK-8848: extra state to handle; n...

[anshul1886]

Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/829#issuecomment-142920071
  
I have followed your explanation but what I am trying to say is that it may 
get updated due to side effect of some other code as from my experience this 
was working as expected. 

If you want then we can safely change it to 
Date vmStateUpdateTime = instance.getPowerStateUpdateTime();


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

[GitHub] cloudstack pull request: Use java.io.tmpdir instead of hardcoded /...

[wido]

GitHub user wido opened a pull request:

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

Use java.io.tmpdir instead of hardcoded /tmp

Small fix to have the tests also work on other platforms

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/wido/cloudstack test-tmp-dir

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/884.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #884


commit 9e90b5393a82163b5baf9c87fa5e49ff00de808f
Author: Wido den Hollander 
Date:   2015-09-24T13:07:41Z

Use java.io.tmpdir instead of hardcoded /tmp




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

Re: Building cloudstack failing on windows

[Wido den Hollander]

On 24-09-15 14:46, Sudharma Jain wrote:
> Hi,
> 
> While building cloudstack on windows, LocalTemplateDownloaderTest fails.
> 
> java.lang.AssertionError: Failed download
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.cloud.storage.template.LocalTemplateDownloaderTest.localTemplateDownloaderTest(LocalTemplateDownloaderTest.java:37)
> 

Hmm, yes, that seems to be a hardcoded path to /tmp.

new LocalTemplateDownloader(null, url, "/tmp",
TemplateDownloader.DEFAULT_MAX_TEMPLATE_SIZE_IN_BYTES, null);

I just sent a PR: https://github.com/apache/cloudstack/pull/884

Wido

> 
> Thanks,
> Sudharma
> 

[GitHub] cloudstack pull request: CLOUDSTACK-8881: Fixed Static and PF conf...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/882#issuecomment-142921879
  
@jayapalu @karuturi 

We, @remibergsma, Funs and I will test the 3 PRs which are VR related now.


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

[GitHub] cloudstack pull request: CLOUDSTACK-8905: Fixed hooking egress rul...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/881#issuecomment-142921936
  
@jayapalu @karuturi 

We, @remibergsma, Funs and I will test the 3 PRs which are VR related now.


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

[GitHub] cloudstack pull request: Configured dnsmasq to listen on all inter...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/870#issuecomment-142922137
  
@jayapalu @karuturi

We, @remibergsma, Funs and I will test the 3 PRs which are VR related now.


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

[GitHub] cloudstack pull request: CLOUDSTACK-8891: Fixed default iptables r...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/867#issuecomment-142922291
  
@jayapalu @karuturi

We, @remibergsma, Funs and I will test the 3 PRs which are VR related now.


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

[GitHub] cloudstack pull request: CLOUDSTACK-8864: Not able to add TCP port...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/851#issuecomment-142922738
  
@jayapalu @karuturi

We, @remibergsma, Funs and I will test the 3 PRs which are VR related now.


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

[GitHub] cloudstack pull request: CLOUDSTACK-8863: VM doesn't reconnect to ...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/836#issuecomment-142922779
  
@jayapalu @karuturi

We, @remibergsma, Funs and I will test the 3 PRs which are VR related now.


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

Re: VR refactoring, concerns and a way out ?

[Remi Bergsma]

Are you serious? You consider to revert a PR that was merged over 6 months ago? 
And expect it to become more stable?

The problem, in MHO, is not that we find bugs that we consider blockers. The 
problem is we are unable to resolve them effectively because master is 
unstable. There currently isn’t a single PR that solves it, hence there is no 
way to test PRs. This is because we have many PRs open and they were all 
branched off of a master that doesn’t work. I simply can't test proposed PRs. 

This problem occurred about 3 weeks ago, because before that master worked and 
we could solve issues and merge PRs. I’m not saying it was bug-free, but at 
least we could work on stabilising it. Most likely, we accepted a “fix” that 
made things worse. Probably even multiple of them.

To get out of this, I think we need to combine a few PRs that make it stable. 
I’ll have a look today with Wilder and Funs to see if what fixes we need to 
combine to make it work again. Once we merge it and master actually works 
again, we can rebase any open PR with current master and work from there.

Regards,
Remi




On 24/09/15 14:00, "Ramanath Katru"  wrote:

>My vote is for the approach no.1 - to backout completely. Most of VR 
>functionalities are broken and are in a mess to say the least. It definitely 
>will take some time and effort from several folks to get it to a stable state.
>
>Ram Katru
>
>
>-Original Message-
>From: Raja Pullela [mailto:raja.pull...@citrix.com] 
>Sent: Thursday, September 24, 2015 2:06 PM
>To: dev@cloudstack.apache.org
>Subject: VR refactoring, concerns and a way out ? 
>
>Hi,
>
>
>
>I understand a concern on the VR changes was raised earlier.  My apologies to 
>restart this thread again.
>
>
>
>However, my last conversation with Jayapal, who has fixed/have been fixing lot 
>of VR issues, about the VR issues and he is pretty concerned about the 
>refactoring that has happened.  I have had the same concern for sometime now  
>(VR issues have been on the list of issues to be looked into for at least 4+ 
>weeks) and wanted to see a good solution for this- with VR being very 
>fundamental to the system.
>
>
>
>Couple of solutions/proposals –
>
>1)  Back out the VR changes – Pros: VR has been stable for some time and 
>it is working well.
>
>2)  Continue to fix/stability VR changes -   Concerns: is the unknowns, 
>what we will find out and how long this will take to stabilize the VR 
>functionality.
>
>
>
>Please chime in if you have any thoughts or concerns around this,
>
>
>
>best,
>
>Raja

Re: VR refactoring, concerns and a way out ?

[sebgoa]

On Sep 24, 2015, at 3:17 PM, Remi Bergsma  wrote:

> Are you serious? You consider to revert a PR that was merged over 6 months 
> ago? And expect it to become more stable?
> 

I have not followed all the latest development, but if we are talking about the 
VR refactoring, indeed it happened several months back. Reverting it now does 
not seem like a good idea.

I am probably missed a beat here, but the latest BVT results sent by Raja 
showed XS tests almost at 100%, there were only some issues with KVM.

> The problem, in MHO, is not that we find bugs that we consider blockers. The 
> problem is we are unable to resolve them effectively because master is 
> unstable. There currently isn’t a single PR that solves it, hence there is no 
> way to test PRs. This is because we have many PRs open and they were all 
> branched off of a master that doesn’t work. I simply can't test proposed PRs. 
> 
> This problem occurred about 3 weeks ago, because before that master worked 
> and we could solve issues and merge PRs. I’m not saying it was bug-free, but 
> at least we could work on stabilising it. Most likely, we accepted a “fix” 
> that made things worse. Probably even multiple of them.
> 

Master seemed stable and PR where being merged towards 4.6 with success (it 
seemed), so indeed if we have issues now of stability, we should identify what 
caused it

> To get out of this, I think we need to combine a few PRs that make it stable. 
> I’ll have a look today with Wilder and Funs to see if what fixes we need to 
> combine to make it work again. O
> nce we merge it and master actually works again, we can rebase any open PR 
> with current master and work from there.

Potentially, if you identify the commit or commits that brought the instability 
you could revert to that point and play forward PRs that did not render master 
unstable.

Thanks for looking into it.

-seb

> Regards,
> Remi
> 
> 
> 
> 
> On 24/09/15 14:00, "Ramanath Katru"  wrote:
> 
>> My vote is for the approach no.1 - to backout completely. Most of VR 
>> functionalities are broken and are in a mess to say the least. It definitely 
>> will take some time and effort from several folks to get it to a stable 
>> state.
>> 
>> Ram Katru
>> 
>> 
>> -Original Message-
>> From: Raja Pullela [mailto:raja.pull...@citrix.com] 
>> Sent: Thursday, September 24, 2015 2:06 PM
>> To: dev@cloudstack.apache.org
>> Subject: VR refactoring, concerns and a way out ? 
>> 
>> Hi,
>> 
>> 
>> 
>> I understand a concern on the VR changes was raised earlier.  My apologies 
>> to restart this thread again.
>> 
>> 
>> 
>> However, my last conversation with Jayapal, who has fixed/have been fixing 
>> lot of VR issues, about the VR issues and he is pretty concerned about the 
>> refactoring that has happened.  I have had the same concern for sometime now 
>>  (VR issues have been on the list of issues to be looked into for at least 
>> 4+ weeks) and wanted to see a good solution for this- with VR being very 
>> fundamental to the system.
>> 
>> 
>> 
>> Couple of solutions/proposals –
>> 
>> 1)  Back out the VR changes – Pros: VR has been stable for some time and 
>> it is working well.
>> 
>> 2)  Continue to fix/stability VR changes -   Concerns: is the unknowns, 
>> what we will find out and how long this will take to stabilize the VR 
>> functionality.
>> 
>> 
>> 
>> Please chime in if you have any thoughts or concerns around this,
>> 
>> 
>> 
>> best,
>> 
>> Raja

[GitHub] cloudstack pull request: Use java.io.tmpdir instead of hardcoded /...

[borisroman]

Github user borisroman commented on the pull request:

https://github.com/apache/cloudstack/pull/884#issuecomment-142934797
  
LGTM -> Unit test works as expected.


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

[GitHub] cloudstack pull request: Use java.io.tmpdir instead of hardcoded /...

[pdube]

Github user pdube commented on the pull request:

https://github.com/apache/cloudstack/pull/884#issuecomment-142936013
  
LGTM


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

[GitHub] cloudstack pull request: CLOUDSTACK-8848: extra state to handle; n...

[resmo]

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/829#issuecomment-142940617
  
So I made a new PR #885 as a replacement for new discussion how this issue 
can be solved.

IMHO this PR can be closed


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

[GitHub] cloudstack pull request: CLOUDSTACK-8848: ensure power state is up...

[resmo]

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/885#issuecomment-142941464
  
/cc @DaanHoogland @koushik-das @anshul1886


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

[GitHub] cloudstack pull request: CLOUDSTACK-8848: ensure power state is up...

[resmo]

GitHub user resmo opened a pull request:

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

CLOUDSTACK-8848: ensure power state is up to date when handling missi…

…ng VMs in powerReport

There 2 things which has been changed. 

* We look on power_state_update_time instead of update_time. Didn't make 
sense to me to look at the update_time.
* Due DB update optimisation, powerState will only be updated if < 
MAX_CONSECUTIVE_SAME_STATE_UPDATE_COUNT; so we can not really rely on these 
information if we can not make sure these are up to date.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/resmo/cloudstack fix/CLOUDSTACK-8848

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/885.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #885


commit d235255a55883745bac99d5640c965a5a4172a81
Author: Rene Moser 
Date:   2015-09-24T13:59:36Z

CLOUDSTACK-8848: ensure power state is up to date when handling missing VMs 
in powerReport

There 2 things which has been changed.

* We look on power_state_update_time instead of update_time. Didn't make 
sense to me to look at the update_time.
* Due DB update optimisation, powerState will only be updated if < 
MAX_CONSECUTIVE_SAME_STATE_UPDATE_COUNT; so we can not really rely on these 
information if we can not make sure these are up to date.




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

[GitHub] cloudstack pull request: Use java.io.tmpdir instead of hardcoded /...

[resmo]

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/884#issuecomment-142945491
  
LGTM


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

Re: [GitHub] cloudstack pull request: CLOUDSTACK-8848: ensure power state is up...

[Rajani Karuturi]

@resmo I will find some time tomorrow to test this. Can you add steps to
test please? Or are they already available on the other pr?


On Thu, Sep 24, 2015 at 19:39 PM, resmo  wrote:

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/885#issuecomment-142941464

/cc @DaanHoogland @koushik-das @anshul1886


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



-- 
-
Sent from Windows Phone
~Rajani

[GitHub] cloudstack pull request: CLOUDSTACK-8848: ensure power state is up...

[resmo]

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/885#issuecomment-142950081
  
It is actually not easy to test because you must hit a race condition. 

What I do is on vCenter make a few migrations of a VR to another hosts and 
look on the management server log for `Run missing VM report`. If you see this 
VR is missing, then you hit the race condition.




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

Re: VR refactoring, concerns and a way out ?

[Raja Pullela]

@wilder, Not sure why you would think it as a nonsense approach? sure, you 
realize amount of code churn and blockers we are dealing with when 4.6 is ready 
to go out. 

Agreed, the refactoring happened several months ago and we could have taken a 
closer look then-   the recent blockers filed have uncovered areas where in the 
implementation didn't exist.  I will post the bug details around this.  

Obviously, the refactoring changes missed multiple critical test scenarios and 
will take substantial time to test/stabilize. 

The BVTs are coming good for basic zone and Adv zone there are still a number 
of failures and it will take us good time to get those fixed.  

Besides the BVTs, regression tests are in a very bad shape.  Hope to get to 
these starting next week.  

Please see my latest bvt report, I will post in another 2 hrs, waiting for a 
new run to complete.  

> On Sep 24, 2015, at 7:00 PM, sebgoa  wrote:
> 
> 
>> On Sep 24, 2015, at 3:17 PM, Remi Bergsma  
>> wrote:
>> 
>> Are you serious? You consider to revert a PR that was merged over 6 months 
>> ago? And expect it to become more stable?
> 
> I have not followed all the latest development, but if we are talking about 
> the VR refactoring, indeed it happened several months back. Reverting it now 
> does not seem like a good idea.
> 
> I am probably missed a beat here, but the latest BVT results sent by Raja 
> showed XS tests almost at 100%, there were only some issues with KVM.
> 
>> The problem, in MHO, is not that we find bugs that we consider blockers. The 
>> problem is we are unable to resolve them effectively because master is 
>> unstable. There currently isn’t a single PR that solves it, hence there is 
>> no way to test PRs. This is because we have many PRs open and they were all 
>> branched off of a master that doesn’t work. I simply can't test proposed 
>> PRs. 
>> 
>> This problem occurred about 3 weeks ago, because before that master worked 
>> and we could solve issues and merge PRs. I’m not saying it was bug-free, but 
>> at least we could work on stabilising it. Most likely, we accepted a “fix” 
>> that made things worse. Probably even multiple of them.
> 
> Master seemed stable and PR where being merged towards 4.6 with success (it 
> seemed), so indeed if we have issues now of stability, we should identify 
> what caused it
> 
>> To get out of this, I think we need to combine a few PRs that make it 
>> stable. I’ll have a look today with Wilder and Funs to see if what fixes we 
>> need to combine to make it work again. O
>> nce we merge it and master actually works again, we can rebase any open PR 
>> with current master and work from there.
> 
> Potentially, if you identify the commit or commits that brought the 
> instability you could revert to that point and play forward PRs that did not 
> render master unstable.
> 
> Thanks for looking into it.
> 
> -seb
> 
>> Regards,
>> Remi
>> 
>> 
>> 
>> 
>>> On 24/09/15 14:00, "Ramanath Katru"  wrote:
>>> 
>>> My vote is for the approach no.1 - to backout completely. Most of VR 
>>> functionalities are broken and are in a mess to say the least. It 
>>> definitely will take some time and effort from several folks to get it to a 
>>> stable state.
>>> 
>>> Ram Katru
>>> 
>>> 
>>> -Original Message-
>>> From: Raja Pullela [mailto:raja.pull...@citrix.com] 
>>> Sent: Thursday, September 24, 2015 2:06 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: VR refactoring, concerns and a way out ? 
>>> 
>>> Hi,
>>> 
>>> 
>>> 
>>> I understand a concern on the VR changes was raised earlier.  My apologies 
>>> to restart this thread again.
>>> 
>>> 
>>> 
>>> However, my last conversation with Jayapal, who has fixed/have been fixing 
>>> lot of VR issues, about the VR issues and he is pretty concerned about the 
>>> refactoring that has happened.  I have had the same concern for sometime 
>>> now  (VR issues have been on the list of issues to be looked into for at 
>>> least 4+ weeks) and wanted to see a good solution for this- with VR being 
>>> very fundamental to the system.
>>> 
>>> 
>>> 
>>> Couple of solutions/proposals –
>>> 
>>> 1)  Back out the VR changes – Pros: VR has been stable for some time 
>>> and it is working well.
>>> 
>>> 2)  Continue to fix/stability VR changes -   Concerns: is the unknowns, 
>>> what we will find out and how long this will take to stabilize the VR 
>>> functionality.
>>> 
>>> 
>>> 
>>> Please chime in if you have any thoughts or concerns around this,
>>> 
>>> 
>>> 
>>> best,
>>> 
>>> Raja
> 

Re: VR refactoring, concerns and a way out ?

[David Nalley]

Everything else aside, do we really think that this could be backed
out cleanly? The initial merge should be easy to pull out, but 6
months of follow on work? There's no way that's coming out cleanly.

--David

On Thu, Sep 24, 2015 at 11:21 AM, Raja Pullela  wrote:
> @wilder, Not sure why you would think it as a nonsense approach? sure, you 
> realize amount of code churn and blockers we are dealing with when 4.6 is 
> ready to go out.
>
> Agreed, the refactoring happened several months ago and we could have taken a 
> closer look then-   the recent blockers filed have uncovered areas where in 
> the implementation didn't exist.  I will post the bug details around this.
>
> Obviously, the refactoring changes missed multiple critical test scenarios 
> and will take substantial time to test/stabilize.
>
> The BVTs are coming good for basic zone and Adv zone there are still a number 
> of failures and it will take us good time to get those fixed.
>
> Besides the BVTs, regression tests are in a very bad shape.  Hope to get to 
> these starting next week.
>
> Please see my latest bvt report, I will post in another 2 hrs, waiting for a 
> new run to complete.
>
>> On Sep 24, 2015, at 7:00 PM, sebgoa  wrote:
>>
>>
>>> On Sep 24, 2015, at 3:17 PM, Remi Bergsma  
>>> wrote:
>>>
>>> Are you serious? You consider to revert a PR that was merged over 6 months 
>>> ago? And expect it to become more stable?
>>
>> I have not followed all the latest development, but if we are talking about 
>> the VR refactoring, indeed it happened several months back. Reverting it now 
>> does not seem like a good idea.
>>
>> I am probably missed a beat here, but the latest BVT results sent by Raja 
>> showed XS tests almost at 100%, there were only some issues with KVM.
>>
>>> The problem, in MHO, is not that we find bugs that we consider blockers. 
>>> The problem is we are unable to resolve them effectively because master is 
>>> unstable. There currently isn’t a single PR that solves it, hence there is 
>>> no way to test PRs. This is because we have many PRs open and they were all 
>>> branched off of a master that doesn’t work. I simply can't test proposed 
>>> PRs.
>>>
>>> This problem occurred about 3 weeks ago, because before that master worked 
>>> and we could solve issues and merge PRs. I’m not saying it was bug-free, 
>>> but at least we could work on stabilising it. Most likely, we accepted a 
>>> “fix” that made things worse. Probably even multiple of them.
>>
>> Master seemed stable and PR where being merged towards 4.6 with success (it 
>> seemed), so indeed if we have issues now of stability, we should identify 
>> what caused it
>>
>>> To get out of this, I think we need to combine a few PRs that make it 
>>> stable. I’ll have a look today with Wilder and Funs to see if what fixes we 
>>> need to combine to make it work again. O
>>> nce we merge it and master actually works again, we can rebase any open PR 
>>> with current master and work from there.
>>
>> Potentially, if you identify the commit or commits that brought the 
>> instability you could revert to that point and play forward PRs that did not 
>> render master unstable.
>>
>> Thanks for looking into it.
>>
>> -seb
>>
>>> Regards,
>>> Remi
>>>
>>>
>>>
>>>
 On 24/09/15 14:00, "Ramanath Katru"  wrote:

 My vote is for the approach no.1 - to backout completely. Most of VR 
 functionalities are broken and are in a mess to say the least. It 
 definitely will take some time and effort from several folks to get it to 
 a stable state.

 Ram Katru


 -Original Message-
 From: Raja Pullela [mailto:raja.pull...@citrix.com]
 Sent: Thursday, September 24, 2015 2:06 PM
 To: dev@cloudstack.apache.org
 Subject: VR refactoring, concerns and a way out ?

 Hi,



 I understand a concern on the VR changes was raised earlier.  My apologies 
 to restart this thread again.



 However, my last conversation with Jayapal, who has fixed/have been fixing 
 lot of VR issues, about the VR issues and he is pretty concerned about the 
 refactoring that has happened.  I have had the same concern for sometime 
 now  (VR issues have been on the list of issues to be looked into for at 
 least 4+ weeks) and wanted to see a good solution for this- with VR being 
 very fundamental to the system.



 Couple of solutions/proposals –

 1)  Back out the VR changes – Pros: VR has been stable for some time 
 and it is working well.

 2)  Continue to fix/stability VR changes -   Concerns: is the 
 unknowns, what we will find out and how long this will take to stabilize 
 the VR functionality.



 Please chime in if you have any thoughts or concerns around this,



 best,

 Raja
>>

Re: VR refactoring, concerns and a way out ?

[Wilder Rodrigues]

Raja,

Do you actually know the amount of blockers we have and how many are VR 
related? Because I have seen emails from Rajani around concerning the blockers 
and I don’t see many. So, yes, I really do think your approach is non-sense.

I mentioned it before, about 1 week ago, but I think you just ignored the 
content of the email. We have 7 blockers, from which 4 are VR related but 
probably only 2 are related to the refactor of the router side (python code). 
You created 2 of the blockers. So, I think would be better to focus on fixing 
them other than making a storm out of it.

You can see the list here: 
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765

The java part of the router refactor was released on 4.5, quite some time ago. 
So, please have a look at git log before mentioned the refactor as a whole.

Another thing is: master is unstable - not because VR changes - and nobody 
could tests the PRs that should fix the VR issues.  When we suggested to 
stabilise Master, people kept pushing features through PRs thinking that it 
would help - even after we said only BLOCKER issues would be merged.

So, please stop this storm around the VR because we are trying to work.

Cheers,
Wilder


On 24 Sep 2015, at 17:21, Raja Pullela 
mailto:raja.pull...@citrix.com>> wrote:

@wilder, Not sure why you would think it as a nonsense approach? sure, you 
realize amount of code churn and blockers we are dealing with when 4.6 is ready 
to go out.

Agreed, the refactoring happened several months ago and we could have taken a 
closer look then-   the recent blockers filed have uncovered areas where in the 
implementation didn't exist.  I will post the bug details around this.

Obviously, the refactoring changes missed multiple critical test scenarios and 
will take substantial time to test/stabilize.

The BVTs are coming good for basic zone and Adv zone there are still a number 
of failures and it will take us good time to get those fixed.

Besides the BVTs, regression tests are in a very bad shape.  Hope to get to 
these starting next week.

Please see my latest bvt report, I will post in another 2 hrs, waiting for a 
new run to complete.

On Sep 24, 2015, at 7:00 PM, sebgoa mailto:run...@gmail.com>> 
wrote:


On Sep 24, 2015, at 3:17 PM, Remi Bergsma 
mailto:rberg...@schubergphilis.com>> wrote:

Are you serious? You consider to revert a PR that was merged over 6 months ago? 
And expect it to become more stable?

I have not followed all the latest development, but if we are talking about the 
VR refactoring, indeed it happened several months back. Reverting it now does 
not seem like a good idea.

I am probably missed a beat here, but the latest BVT results sent by Raja 
showed XS tests almost at 100%, there were only some issues with KVM.

The problem, in MHO, is not that we find bugs that we consider blockers. The 
problem is we are unable to resolve them effectively because master is 
unstable. There currently isn’t a single PR that solves it, hence there is no 
way to test PRs. This is because we have many PRs open and they were all 
branched off of a master that doesn’t work. I simply can't test proposed PRs.

This problem occurred about 3 weeks ago, because before that master worked and 
we could solve issues and merge PRs. I’m not saying it was bug-free, but at 
least we could work on stabilising it. Most likely, we accepted a “fix” that 
made things worse. Probably even multiple of them.

Master seemed stable and PR where being merged towards 4.6 with success (it 
seemed), so indeed if we have issues now of stability, we should identify what 
caused it

To get out of this, I think we need to combine a few PRs that make it stable. 
I’ll have a look today with Wilder and Funs to see if what fixes we need to 
combine to make it work again. O
nce we merge it and master actually works again, we can rebase any open PR with 
current master and work from there.

Potentially, if you identify the commit or commits that brought the instability 
you could revert to that point and play forward PRs that did not render master 
unstable.

Thanks for looking into it.

-seb

Regards,
Remi




On 24/09/15 14:00, "Ramanath Katru" 
mailto:ramanath.ka...@citrix.com>> wrote:

My vote is for the approach no.1 - to backout completely. Most of VR 
functionalities are broken and are in a mess to say the least. It definitely 
will take some time and effort from several folks to get it to a stable state.

Ram Katru


-Original Message-
From: Raja Pullela [mailto:raja.pull...@citrix.com]
Sent: Thursday, September 24, 2015 2:06 PM
To: dev@cloudstack.apache.org
Subject: VR refactoring, concerns and a way out ?

Hi,



I understand a concern on the VR changes was raised earlier.  My apologies to 
restart this thread again.



However, my last conversation with Jayapal, who has fixed/have been fixing lot 
of VR issues, about the VR issues and he is pretty concerned about the 

Re: VR refactoring, concerns and a way out ?

[Raja Pullela]

this is very disrespectful... Sorry to say that you don't understand the 
complexity and impact of this..  Let's not discuss this over an email and agree 
to disagree with each other... move on! 

> On Sep 24, 2015, at 10:20 PM, Wilder Rodrigues 
>  wrote:
> 
> Raja,
> 
> Do you actually know the amount of blockers we have and how many are VR 
> related? Because I have seen emails from Rajani around concerning the 
> blockers and I don’t see many. So, yes, I really do think your approach is 
> non-sense.
> 
> I mentioned it before, about 1 week ago, but I think you just ignored the 
> content of the email. We have 7 blockers, from which 4 are VR related but 
> probably only 2 are related to the refactor of the router side (python code). 
> You created 2 of the blockers. So, I think would be better to focus on fixing 
> them other than making a storm out of it.
> 
> You can see the list here: 
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765
> 
> The java part of the router refactor was released on 4.5, quite some time 
> ago. So, please have a look at git log before mentioned the refactor as a 
> whole.
> 
> Another thing is: master is unstable - not because VR changes - and nobody 
> could tests the PRs that should fix the VR issues.  When we suggested to 
> stabilise Master, people kept pushing features through PRs thinking that it 
> would help - even after we said only BLOCKER issues would be merged.
> 
> So, please stop this storm around the VR because we are trying to work.
> 
> Cheers,
> Wilder
> 
> 
> On 24 Sep 2015, at 17:21, Raja Pullela 
> mailto:raja.pull...@citrix.com>> wrote:
> 
> @wilder, Not sure why you would think it as a nonsense approach? sure, you 
> realize amount of code churn and blockers we are dealing with when 4.6 is 
> ready to go out.
> 
> Agreed, the refactoring happened several months ago and we could have taken a 
> closer look then-   the recent blockers filed have uncovered areas where in 
> the implementation didn't exist.  I will post the bug details around this.
> 
> Obviously, the refactoring changes missed multiple critical test scenarios 
> and will take substantial time to test/stabilize.
> 
> The BVTs are coming good for basic zone and Adv zone there are still a number 
> of failures and it will take us good time to get those fixed.
> 
> Besides the BVTs, regression tests are in a very bad shape.  Hope to get to 
> these starting next week.
> 
> Please see my latest bvt report, I will post in another 2 hrs, waiting for a 
> new run to complete.
> 
> On Sep 24, 2015, at 7:00 PM, sebgoa 
> mailto:run...@gmail.com>> wrote:
> 
> 
> On Sep 24, 2015, at 3:17 PM, Remi Bergsma 
> mailto:rberg...@schubergphilis.com>> wrote:
> 
> Are you serious? You consider to revert a PR that was merged over 6 months 
> ago? And expect it to become more stable?
> 
> I have not followed all the latest development, but if we are talking about 
> the VR refactoring, indeed it happened several months back. Reverting it now 
> does not seem like a good idea.
> 
> I am probably missed a beat here, but the latest BVT results sent by Raja 
> showed XS tests almost at 100%, there were only some issues with KVM.
> 
> The problem, in MHO, is not that we find bugs that we consider blockers. The 
> problem is we are unable to resolve them effectively because master is 
> unstable. There currently isn’t a single PR that solves it, hence there is no 
> way to test PRs. This is because we have many PRs open and they were all 
> branched off of a master that doesn’t work. I simply can't test proposed PRs.
> 
> This problem occurred about 3 weeks ago, because before that master worked 
> and we could solve issues and merge PRs. I’m not saying it was bug-free, but 
> at least we could work on stabilising it. Most likely, we accepted a “fix” 
> that made things worse. Probably even multiple of them.
> 
> Master seemed stable and PR where being merged towards 4.6 with success (it 
> seemed), so indeed if we have issues now of stability, we should identify 
> what caused it
> 
> To get out of this, I think we need to combine a few PRs that make it stable. 
> I’ll have a look today with Wilder and Funs to see if what fixes we need to 
> combine to make it work again. O
> nce we merge it and master actually works again, we can rebase any open PR 
> with current master and work from there.
> 
> Potentially, if you identify the commit or commits that brought the 
> instability you could revert to that point and play forward PRs that did not 
> render master unstable.
> 
> Thanks for looking into it.
> 
> -seb
> 
> Regards,
> Remi
> 
> 
> 
> 
> On 24/09/15 14:00, "Ramanath Katru" 
> mailto:ramanath.ka...@citrix.com>> wrote:
> 
> My vote is for the approach no.1 - to backout completely. Most of VR 
> functionalities are broken and are in a mess to say the least. It definitely 
> will take some time and effort from several folks to get it to a stable state.
> 
> Ram Katru
> 
> 
> -Orig

BVT report 9/23

[Raja Pullela]

BVT report 09/23

simulator basic - 30% , earlier runs had 100% pass rate, failures need to be 
analyzed 
Simulator adv - 50%, earlier runs had 100% pass rate, failures need to be 
analyzed 
XS basic - 95.3% 
XS Adv - 93.6% 
XS eip - 86.7%
KVM basic - 89.4%
KVM Adv - Deployment issue, need to check and will update 
KVM eip - 95.7% 
VMware Adv - deployment issue, need to check and update 

[GitHub] cloudstack pull request: [FUTURE]CLOUDSTACK-8907: POD Gateway opti...

[borisroman]

GitHub user borisroman opened a pull request:

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

[FUTURE]CLOUDSTACK-8907: POD Gateway optional

A gateway might not always be available. For instance, when the management 
network is an isolated network without internet access or inter domain/vlan 
routing.

How to test:
1. Deploy ACS
2. Add POD without gateway.
3. Let the systemvms deploy -> They don't have a gateway but can correctly 
connect to the management server.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/borisroman/cloudstack CLOUDSTACK-8907

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/886.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #886


commit f64bc58ee92eb3c895b3a32489ea1c6dfddc6c9a
Author: Boris Schrijver 
Date:   2015-09-24T11:16:46Z

Made gateway optional when creating pod.

commit 186c50bddf35e351b77d3759fddfb0c3e65cf46d
Author: Boris Schrijver 
Date:   2015-09-24T18:15:46Z

Removed double pod gateway definition.

Updated editPod() to accept null gateway.

commit acaf49f979b54e108d6710d867d561bd82a7f066
Author: Boris Schrijver 
Date:   2015-09-24T18:38:41Z

Fixed some finalizeVirtualMachineProfile() methods to handle null pod 
gateways.




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

Re: BVT report 9/23

[Sebastien Goasguen]

> On Sep 24, 2015, at 9:08 PM, Raja Pullela  wrote:
> 
> BVT report 09/23
> 
> simulator basic - 30% , earlier runs had 100% pass rate, failures need to be 
> analyzed 

What’s earlier ? yesterday, last week, six months ago ?

> Simulator adv - 50%, earlier runs had 100% pass rate, failures need to be 
> analyzed 

Same here, what’s earlier ? 

> XS basic - 95.3% 
> XS Adv - 93.6% 
> XS eip - 86.7%

Is this good enough from your view for release, or do you want 100% ?

> KVM basic - 89.4%
> KVM Adv - Deployment issue, need to check and will update 
> KVM eip - 95.7% 

Good so it’s running now.

> VMware Adv - deployment issue, need to check and update 
> 
> 

Testing ACS master + 7 PRs

[Wilder Rodrigues]

Hi all,

We have spent some extra time to test the current master in conjunction with 7 
PRs that should be fixing some PF/FW/VR problems.

There are still issues with the VPC VR when we try to stop/start the router of 
a VPC which contains tiers/VMs. In that case, 2 of 8 tests failed. Concerning 
the redundant VPC, the tests is failing due to timeout - which could be related 
to the problemas we have with default route.

Just to make a very clear point here: the tests mentioned above were passing 
fine 3 weeks ago!

We will proceed tomorrow, fixing the issue above mentioned and pushing 1 PR 
that once merged with close the ones below.

The list of PRs is as follows:

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

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

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

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

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

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

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

The results ares:


Test router internal advanced zone ... === TestName: 
test_02_router_internal_adv | Status : SUCCESS ===
ok
Test restart network ... === TestName: test_03_restart_network_cleanup | Status 
: SUCCESS ===
ok
Test router basic setup ... === TestName: test_05_router_basic | Status : 
SUCCESS ===
ok
Test router advanced setup ... === TestName: test_06_router_advanced | Status : 
SUCCESS ===
ok
Test stop router ... === TestName: test_07_stop_router | Status : SUCCESS ===
ok
Test start router ... === TestName: test_08_start_router | Status : SUCCESS ===
ok
Test reboot router ... === TestName: test_09_reboot_router | Status : SUCCESS 
===
ok

--
Ran 7 tests in 534.900s

OK
/tmp//MarvinLogs/test_routers_3MVY7R/results.txt (END)


Test redundant router internals ... === TestName: test_enableVPNOverRvR | 
Status : SUCCESS ===
ok

--
Ran 1 test in 473.712s

OK
/tmp//MarvinLogs/test_redundant_router_services_FR114B/results.txt (END)

Test advanced zone virtual router ... === TestName: test_advZoneVirtualRouter | 
Status : SUCCESS ===
ok
Test Deploy Virtual Machine ... === TestName: test_deploy_vm | Status : SUCCESS 
===
ok
Test Multiple Deploy Virtual Machine ... === TestName: test_deploy_vm_multiple 
| Status : SUCCESS ===
ok
Test Stop Virtual Machine ... === TestName: test_01_stop_vm | Status : SUCCESS 
===
ok
Test Start Virtual Machine ... === TestName: test_02_start_vm | Status : 
SUCCESS ===
ok
Test Reboot Virtual Machine ... === TestName: test_03_reboot_vm | Status : 
SUCCESS ===
ok
Test destroy Virtual Machine ... === TestName: test_06_destroy_vm | Status : 
SUCCESS ===
ok
Test recover Virtual Machine ... === TestName: test_07_restore_vm | Status : 
SUCCESS ===
ok
Test migrate VM ... SKIP: At least two hosts should be present in the zone for 
migration
Test destroy(expunge) Virtual Machine ... === TestName: test_09_expunge_vm | 
Status : SUCCESS ===
ok

--
Ran 10 tests in 1240.119s

OK (SKIP=1)
/tmp//MarvinLogs/test_vm_life_cycle_6XISXB/results.txt (END)


Test create VPC offering ... === TestName: test_01_create_vpc_offering | Status 
: SUCCESS ===
ok
Test VPC offering without load balancing service ... === TestName: 
test_03_vpc_off_without_lb | Status : SUCCESS ===
ok
Test VPC offering without static NAT service ... === TestName: 
test_04_vpc_off_without_static_nat | Status : SUCCESS ===
ok
Test VPC offering without port forwarding service ... === TestName: 
test_05_vpc_off_without_pf | Status : SUCCESS ===
ok
Test VPC offering with invalid services ... === TestName: 
test_06_vpc_off_invalid_services | Status : SUCCESS ===
ok
Test update VPC offering ... === TestName: test_07_update_vpc_off | Status : 
SUCCESS ===
ok
Test list VPC offering ... === TestName: test_08_list_vpc_off | Status : 
SUCCESS ===
ok
test_09_create_redundant_vpc_offering 
(integration.component.test_vpc_offerings.TestVPCOffering) ... === TestName: 
test_09_create_redundant_vpc_offering | Status : SUCCESS ===
ok

--
Ran 8 tests in 1460.812s

OK
/tmp//MarvinLogs/test_vpc_offerings_2I7ACT/results.txt (END)


Test reset virtual machine on reboot ... === TestName: 
test_01_reset_vm_on_reboot | Status : SUCCESS ===
ok

--
Ran 1 test in 528.656s

OK
/tmp//MarvinLogs/test_reset_vm_on_reboot_4QCNJC/results.txt (END)


Test VPN in VPC ... === TestName: test_vpc_remote_access_vpn | Status : SUCCESS 
===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS ===
ok

--
Ran 2 tests in 831.561s

OK
/tmp//MarvinLogs/test_vpc_vpn_RSH04G/results.txt (END)


Test iptables default INPUT/FORWARD policy on RouterVM ... === TestNa

[GitHub] cloudstack pull request: CLOUDSTACK-8805: Domains become inactive ...

[nitin-maharana]

Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/775#issuecomment-143041644
  
Hi. Here we have to access the database to see the behaviour of replace 
function. Because the replace function is evaluated in database server side. 
But in unit test we cannot access the database. We know the replace function 
will work properly if the parameters are sent correctly. So I have tested 
whether the parameters are sent correctly to the replace function while 
executing. I have done in two scenarios. Before the code change and after this 
commit. I have shared two screenshots of my test.

1. Behaviour before this commit

![pr_775_before_change](https://cloud.githubusercontent.com/assets/12583725/10085731/65abb18e-6328-11e5-8060-a1c4c8fab9ee.png)

2. Behaviour after this commit

![pr_775_after_change](https://cloud.githubusercontent.com/assets/12583725/10085734/6aeaf0ec-6328-11e5-9211-689ab5e347d0.png)




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

Re: VR refactoring, concerns and a way out ?

[Wilder Rodrigues]

Thinking about being disrespectful when one doesn’t read the emails, or does 
but filters parts of the message, and keeps storming about unclear things.

Yes, time to move on. We have to get a cloud running.

Cheers,
Wilder

> On 24 Sep 2015, at 20:29, Raja Pullela  wrote:
> 
> this is very disrespectful... Sorry to say that you don't understand the 
> complexity and impact of this..  Let's not discuss this over an email and 
> agree to disagree with each other... move on! 
> 
>> On Sep 24, 2015, at 10:20 PM, Wilder Rodrigues 
>>  wrote:
>> 
>> Raja,
>> 
>> Do you actually know the amount of blockers we have and how many are VR 
>> related? Because I have seen emails from Rajani around concerning the 
>> blockers and I don’t see many. So, yes, I really do think your approach is 
>> non-sense.
>> 
>> I mentioned it before, about 1 week ago, but I think you just ignored the 
>> content of the email. We have 7 blockers, from which 4 are VR related but 
>> probably only 2 are related to the refactor of the router side (python 
>> code). You created 2 of the blockers. So, I think would be better to focus 
>> on fixing them other than making a storm out of it.
>> 
>> You can see the list here: 
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765
>> 
>> The java part of the router refactor was released on 4.5, quite some time 
>> ago. So, please have a look at git log before mentioned the refactor as a 
>> whole.
>> 
>> Another thing is: master is unstable - not because VR changes - and nobody 
>> could tests the PRs that should fix the VR issues.  When we suggested to 
>> stabilise Master, people kept pushing features through PRs thinking that it 
>> would help - even after we said only BLOCKER issues would be merged.
>> 
>> So, please stop this storm around the VR because we are trying to work.
>> 
>> Cheers,
>> Wilder
>> 
>> 
>> On 24 Sep 2015, at 17:21, Raja Pullela 
>> mailto:raja.pull...@citrix.com>> wrote:
>> 
>> @wilder, Not sure why you would think it as a nonsense approach? sure, you 
>> realize amount of code churn and blockers we are dealing with when 4.6 is 
>> ready to go out.
>> 
>> Agreed, the refactoring happened several months ago and we could have taken 
>> a closer look then-   the recent blockers filed have uncovered areas where 
>> in the implementation didn't exist.  I will post the bug details around this.
>> 
>> Obviously, the refactoring changes missed multiple critical test scenarios 
>> and will take substantial time to test/stabilize.
>> 
>> The BVTs are coming good for basic zone and Adv zone there are still a 
>> number of failures and it will take us good time to get those fixed.
>> 
>> Besides the BVTs, regression tests are in a very bad shape.  Hope to get to 
>> these starting next week.
>> 
>> Please see my latest bvt report, I will post in another 2 hrs, waiting for a 
>> new run to complete.
>> 
>> On Sep 24, 2015, at 7:00 PM, sebgoa 
>> mailto:run...@gmail.com>> wrote:
>> 
>> 
>> On Sep 24, 2015, at 3:17 PM, Remi Bergsma 
>> mailto:rberg...@schubergphilis.com>> wrote:
>> 
>> Are you serious? You consider to revert a PR that was merged over 6 months 
>> ago? And expect it to become more stable?
>> 
>> I have not followed all the latest development, but if we are talking about 
>> the VR refactoring, indeed it happened several months back. Reverting it now 
>> does not seem like a good idea.
>> 
>> I am probably missed a beat here, but the latest BVT results sent by Raja 
>> showed XS tests almost at 100%, there were only some issues with KVM.
>> 
>> The problem, in MHO, is not that we find bugs that we consider blockers. The 
>> problem is we are unable to resolve them effectively because master is 
>> unstable. There currently isn’t a single PR that solves it, hence there is 
>> no way to test PRs. This is because we have many PRs open and they were all 
>> branched off of a master that doesn’t work. I simply can't test proposed PRs.
>> 
>> This problem occurred about 3 weeks ago, because before that master worked 
>> and we could solve issues and merge PRs. I’m not saying it was bug-free, but 
>> at least we could work on stabilising it. Most likely, we accepted a “fix” 
>> that made things worse. Probably even multiple of them.
>> 
>> Master seemed stable and PR where being merged towards 4.6 with success (it 
>> seemed), so indeed if we have issues now of stability, we should identify 
>> what caused it
>> 
>> To get out of this, I think we need to combine a few PRs that make it 
>> stable. I’ll have a look today with Wilder and Funs to see if what fixes we 
>> need to combine to make it work again. O
>> nce we merge it and master actually works again, we can rebase any open PR 
>> with current master and work from there.
>> 
>> Potentially, if you identify the commit or commits that brought the 
>> instability you could revert to that point and play forward PRs that did not 
>> render master unstable.
>> 
>> Thanks for looking into it.
>> 
>> -s

Re: VR refactoring, concerns and a way out ?

[Sebastien Goasguen]

Folks, 

Let’s take a deep breath here, everyone is aiming for a good release.

With 4.6 we are trying a new way of creating the release, it may not be the 
best, but I think we need to stick with the current process and release.
We can then have a post-mortem and see what worked and what did not work.

David and co have been working on hardware setup to finally get a CI running 
under ASF. This will help.

For now, we need to focus on the release. Reverting a 6 months old feature is 
in my view a no go, and I don’t have the feeling that it is the actual problem.

I suggest we all jump on a hangout tomorrow and try to figure this out.

* Wilder and co have done great work to test pending PR
* We have a set of blockers
* We have two great RMs.

The one thing that is very troubling to me are the statements that “this used 
to work 3 weeks ago”. I don’t understand how things can be broken now if only 
the RMs can merge to master. I will have a look tomorrow.

So please, let’s take a deep breath, only RMs can touch master, and let’s work 
it out tomorrow.

Cheers,

-sebastien

> On Sep 24, 2015, at 10:27 PM, Wilder Rodrigues 
>  wrote:
> 
> Thinking about being disrespectful when one doesn’t read the emails, or does 
> but filters parts of the message, and keeps storming about unclear things.
> 
> Yes, time to move on. We have to get a cloud running.
> 
> Cheers,
> Wilder
> 
>> On 24 Sep 2015, at 20:29, Raja Pullela  wrote:
>> 
>> this is very disrespectful... Sorry to say that you don't understand the 
>> complexity and impact of this..  Let's not discuss this over an email and 
>> agree to disagree with each other... move on! 
>> 
>>> On Sep 24, 2015, at 10:20 PM, Wilder Rodrigues 
>>>  wrote:
>>> 
>>> Raja,
>>> 
>>> Do you actually know the amount of blockers we have and how many are VR 
>>> related? Because I have seen emails from Rajani around concerning the 
>>> blockers and I don’t see many. So, yes, I really do think your approach is 
>>> non-sense.
>>> 
>>> I mentioned it before, about 1 week ago, but I think you just ignored the 
>>> content of the email. We have 7 blockers, from which 4 are VR related but 
>>> probably only 2 are related to the refactor of the router side (python 
>>> code). You created 2 of the blockers. So, I think would be better to focus 
>>> on fixing them other than making a storm out of it.
>>> 
>>> You can see the list here: 
>>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765
>>> 
>>> The java part of the router refactor was released on 4.5, quite some time 
>>> ago. So, please have a look at git log before mentioned the refactor as a 
>>> whole.
>>> 
>>> Another thing is: master is unstable - not because VR changes - and nobody 
>>> could tests the PRs that should fix the VR issues.  When we suggested to 
>>> stabilise Master, people kept pushing features through PRs thinking that it 
>>> would help - even after we said only BLOCKER issues would be merged.
>>> 
>>> So, please stop this storm around the VR because we are trying to work.
>>> 
>>> Cheers,
>>> Wilder
>>> 
>>> 
>>> On 24 Sep 2015, at 17:21, Raja Pullela 
>>> mailto:raja.pull...@citrix.com>> wrote:
>>> 
>>> @wilder, Not sure why you would think it as a nonsense approach? sure, you 
>>> realize amount of code churn and blockers we are dealing with when 4.6 is 
>>> ready to go out.
>>> 
>>> Agreed, the refactoring happened several months ago and we could have taken 
>>> a closer look then-   the recent blockers filed have uncovered areas where 
>>> in the implementation didn't exist.  I will post the bug details around 
>>> this.
>>> 
>>> Obviously, the refactoring changes missed multiple critical test scenarios 
>>> and will take substantial time to test/stabilize.
>>> 
>>> The BVTs are coming good for basic zone and Adv zone there are still a 
>>> number of failures and it will take us good time to get those fixed.
>>> 
>>> Besides the BVTs, regression tests are in a very bad shape.  Hope to get to 
>>> these starting next week.
>>> 
>>> Please see my latest bvt report, I will post in another 2 hrs, waiting for 
>>> a new run to complete.
>>> 
>>> On Sep 24, 2015, at 7:00 PM, sebgoa 
>>> mailto:run...@gmail.com>> wrote:
>>> 
>>> 
>>> On Sep 24, 2015, at 3:17 PM, Remi Bergsma 
>>> mailto:rberg...@schubergphilis.com>> wrote:
>>> 
>>> Are you serious? You consider to revert a PR that was merged over 6 months 
>>> ago? And expect it to become more stable?
>>> 
>>> I have not followed all the latest development, but if we are talking about 
>>> the VR refactoring, indeed it happened several months back. Reverting it 
>>> now does not seem like a good idea.
>>> 
>>> I am probably missed a beat here, but the latest BVT results sent by Raja 
>>> showed XS tests almost at 100%, there were only some issues with KVM.
>>> 
>>> The problem, in MHO, is not that we find bugs that we consider blockers. 
>>> The problem is we are unable to resolve them effectively because master is 
>>> unstable. There

Master frozen

[Sebastien Goasguen]

Folks,

Being so close to a release, master needs to be frozen and only RMs can make 
commits.

It seems that we relaxed this policy a bit in the last weeks and this is now 
causing us grief.

@Remi, @rajani, you should totally revert commits that are made by other people 
than you two.

You are building the release, you decide what gets in.

@everyone, freezing master is not slowing down your development, you can 
develop somewhere else but the onus is 100% on you to rebase your branch with 
master and what the RMs put in. Once you send your PRs they should be rebased.

-Sebastien

[GitHub] cloudstack pull request: [BLOCKER] Combined PRs that fix VR issues

[remibergsma]

GitHub user remibergsma opened a pull request:

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

[BLOCKER] Combined PRs that fix VR issues

Tonight I worked with @wilderrodrigues to figure out what is wrong with the 
virtual router. As we couldn't test single PRs any more (because of other 
issues with them causing tests to fail) we added all VR related PRs in a 
separate branch and started testing from there.

We combined the following PRs into this PR:
#836 #851 #867 #870 #881 #882 #842

After that, one issue remains: the VPC does not get a default gateway. 
Which is strange, because we already solved it in PR #738. When I look back, it 
was fixed again in PR #784. It could very well be that either one fixed one 
specific case, but also breaking the other. We need to investigate this, and 
make sure there will be a fix that works both for VPCs and VRs.

When we manually add the default gateway on the VPC, most tests pass and 
also spinning up two VPCs with one tier each, having a VM and them using s2s to 
VPN them together works fine. See for more details the report Wilder sent 
earlier.

Tomorrow we'll try to figure out how to fix the default gateway and merge 
this. Then we should have a base to work from again. Any PR that fixes another 
blocker, should at least then be rebased against the fixed master so we can run 
the tests against the PR branch. I'm not saying everything is fixed, I'm just 
saying that we can spin up a cloud that has working VMs.

When, in the mean time, someone has the time to checkout this branch and 
make the default route work for both VPC and VR that would be awesome. After 
that we should double check and verify the test results. 

Pinging @karuturi to let her know the current status.

Regards,
Wilder / Remi

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/schubergphilis/cloudstack vr_fixes_combined

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/887.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #887


commit a15df0569fa0e56b14a9a119858c53e8ae6085c3
Author: Jayapal 
Date:   2015-09-16T09:52:33Z

CLOUDSTACK-8843: Fixed issue in default iptables rules on shared network VR

commit 56d4429500d0d3da7334b3f1c559d1eca8ee85a4
Author: SudharmaJain 
Date:   2015-09-16T09:10:31Z

CLOUDSTACK-8863: VM doesn't reconnect to internet post VR 
RESTART/STOP-START/RECREATE

commit 96c38bf491d81e41975dddbfc3c87716293c7bdf
Author: SudharmaJain 
Date:   2015-09-19T18:10:21Z

CLOUDSTACK-8864: Not able to add TCP port forwarding rule in VPN for 
specific ports

commit dbedfe2557839332c394c44deb6c376f386681d9
Author: Jayapal 
Date:   2015-09-17T06:04:27Z

Configured dnsmasq to listen on all interfaces so that vpn  client gets dns

commit 746a5dc48e01cc07cbd4b319755d45e414c49504
Author: Jayapal 
Date:   2015-09-24T07:14:15Z

CLOUDSTACK-8891: Fixed default iptables rules on VR  for guest traffic

commit 2bf7fb4b63932d80f641462073c751f07ab0c3ea
Author: Jayapal 
Date:   2015-09-24T11:36:11Z

CLOUDSTACK-8905: Fixed hooking egress rules

commit 40138d2e994458250b8db706be993d4b040f95ca
Author: Jayapal 
Date:   2015-09-24T11:52:29Z

CLOUDSTACK-8881: Fixed Static and PF configuration issue

commit 8367911ef7f502eb760ca57d0a018d96620fdbed
Author: Remi Bergsma 
Date:   2015-09-24T13:35:00Z

Merge pull request #836 from SudharmaJain/cs-8863

CLOUDSTACK-8863: VM doesn't reconnect to internet post VR 
RESTART/STOP-START/RECREATE

The ongoing ICMP request reply session is broken when the VR is down, the 
expectation is that it would resume once the VR is up. Investigations revealed 
that the ongoing ICMP packets are sent out of eth2 without being NATed post VR 
stop/start or restart or recreate.

TCPDUMP output from VR post restart/stop-start/recreate on eth2:

root@r-4-VM:~# tcpdump -i eth2 icmp -n -vvv
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535 
bytes
06:22:52.749770 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP 
(1), length 84)
192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 81, 
length 64
06:22:53.749782 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP 
(1), length 84)
192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 82, 
length 64
06:22:54.749771 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP 
(1), length 84)
192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 83, 
length 64
06:22:55.749775 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP 
(1), length 84)
192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 84, 
length 64
06:22:56.749765 IP (tos 0x0,

Re: BVT report 9/23

[Raja Pullela]

Please see inline comments..

> On Sep 25, 2015, at 1:47 AM, Sebastien Goasguen  wrote:
> 
> 
>> On Sep 24, 2015, at 9:08 PM, Raja Pullela  wrote:
>> 
>> BVT report 09/23
>> 
>> simulator basic - 30% , earlier runs had 100% pass rate, failures need to be 
>> analyzed
> 
> What’s earlier ? yesterday, last week, six months ago ?
Earlier - yesterday's runs
> 
>> Simulator adv - 50%, earlier runs had 100% pass rate, failures need to be 
>> analyzed
> 
> Same here, what’s earlier ? 
Earlier - yesterday's runs
> 
>> XS basic - 95.3% 
>> XS Adv - 93.6% 
>> XS eip - 86.7%
> 
> Is this good enough from your view for release, or do you want 100% ?
We should get 100%
> 
>> KVM basic - 89.4%
>> KVM Adv - Deployment issue, need to check and will update 
>> KVM eip - 95.7%
> 
> Good so it’s running now.
Yes, after the agent fixes this is back up
> 
>> VMware Adv - deployment issue, need to check and update
> 

Re: BVT report 9/23

[Sebastien Goasguen]

> On Sep 25, 2015, at 3:25 AM, Raja Pullela  wrote:
> 
> Please see inline comments..
> 
>> On Sep 25, 2015, at 1:47 AM, Sebastien Goasguen  wrote:
>> 
>> 
>>> On Sep 24, 2015, at 9:08 PM, Raja Pullela  wrote:
>>> 
>>> BVT report 09/23
>>> 
>>> simulator basic - 30% , earlier runs had 100% pass rate, failures need to 
>>> be analyzed
>> 
>> What’s earlier ? yesterday, last week, six months ago ?
> Earlier - yesterday's runs

Ok so it is much wore than yesterday. I look forward to get your analysis .

>> 
>>> Simulator adv - 50%, earlier runs had 100% pass rate, failures need to be 
>>> analyzed
>> 
>> Same here, what’s earlier ? 
> Earlier - yesterday's runs
>> 
>>> XS basic - 95.3% 
>>> XS Adv - 93.6% 
>>> XS eip - 86.7%
>> 
>> Is this good enough from your view for release, or do you want 100% ?
> We should get 100%
>> 
>>> KVM basic - 89.4%
>>> KVM Adv - Deployment issue, need to check and will update 
>>> KVM eip - 95.7%
>> 
>> Good so it’s running now.
> Yes, after the agent fixes this is back up

Was this fix identified as a blocker, was there a PR for it and has it been 
merged ?


The reason I am asking is that it is difficult to understand these numbers out 
of context.
Seeing the results given some notion of the success, but we don’t really no 
what tests are run, on what exact setup.

Also you mentioned regression tests..what are those ? we don’t run regression 
tests upstream, so I suppose these are internal Citrix tests...


>> 
>>> VMware Adv - deployment issue, need to check and update
>> 

[GitHub] cloudstack pull request: [BLOCKER] Combined PRs that fix VR issues

[runseb]

Github user runseb commented on the pull request:

https://github.com/apache/cloudstack/pull/887#issuecomment-143140589
  
@jayapalu @SudharmaJain can you check this asap, as it merges all your past 
PRs in one and rebases with master. thanks


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

Re: BVT report 9/23

[Sebastien Goasguen]

> On Sep 25, 2015, at 8:14 AM, Sebastien Goasguen  wrote:
> 
> 
>> On Sep 25, 2015, at 3:25 AM, Raja Pullela  wrote:
>> 
>> Please see inline comments..
>> 
>>> On Sep 25, 2015, at 1:47 AM, Sebastien Goasguen  wrote:
>>> 
>>> 
 On Sep 24, 2015, at 9:08 PM, Raja Pullela  wrote:
 
 BVT report 09/23
 
 simulator basic - 30% , earlier runs had 100% pass rate, failures need to 
 be analyzed
>>> 
>>> What’s earlier ? yesterday, last week, six months ago ?
>> Earlier - yesterday's runs
> 
> Ok so it is much wore than yesterday. I look forward to get your analysis .

Raja, to try to understand this I just looked at the commits on master.
Yesterday there was one commit, related to Vagrantfiles for devcloud.

There is no chance that this commit can affect master and the tests…so this 
must be a glitch in the simulator runs.

-sebastien

> 
>>> 
 Simulator adv - 50%, earlier runs had 100% pass rate, failures need to be 
 analyzed
>>> 
>>> Same here, what’s earlier ? 
>> Earlier - yesterday's runs
>>> 
 XS basic - 95.3% 
 XS Adv - 93.6% 
 XS eip - 86.7%
>>> 
>>> Is this good enough from your view for release, or do you want 100% ?
>> We should get 100%
>>> 
 KVM basic - 89.4%
 KVM Adv - Deployment issue, need to check and will update 
 KVM eip - 95.7%
>>> 
>>> Good so it’s running now.
>> Yes, after the agent fixes this is back up
> 
> Was this fix identified as a blocker, was there a PR for it and has it been 
> merged ?
> 
> 
> The reason I am asking is that it is difficult to understand these numbers 
> out of context.
> Seeing the results given some notion of the success, but we don’t really no 
> what tests are run, on what exact setup.
> 
> Also you mentioned regression tests..what are those ? we don’t run regression 
> tests upstream, so I suppose these are internal Citrix tests...
> 
> 
>>> 
 VMware Adv - deployment issue, need to check and update
>>> 
>