[GitHub] [cloudstack] weizhouapache commented on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
weizhouapache commented on issue #3179: Redundant VRouter guest network on 
wrong interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554555283
 
 
   @DennisKonrad 
   I have set up a testing environment with OVS. I cannot reproduce this issue.
   Do you test on official cloudstack release or with some your changes ?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] weizhouapache commented on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
weizhouapache commented on issue #3179: Redundant VRouter guest network on 
wrong interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554486187
 
 
   @DennisKonrad 
   if you look at CommandSetupHelper.java, you may find that IpAssocVpcCommand 
is send to hypervisors when associate a public IP, if VPC does not have 
redundant VRs. However, for VPC with RvRs, it always send IpAssocCommand (in 
createRedundantAssociateIPCommands), which does not make any sense.
   
   There should be some issues caused by it in the past, some of them have been 
fixed by different way, for example 6fc389a044288e8f12f41a651a711a1ab7113b86 . 
However, I insist that we should send IpAssocVpcCommand instead of 
IpAssocCommand , even it might lead to some issues.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] svenvogel commented on issue #3371: Fix virtual template size for managed storage / refactor cloud-install-sys-tmplt

2019-11-15 Thread GitBox
svenvogel commented on issue #3371: Fix virtual template size for managed 
storage / refactor cloud-install-sys-tmplt
URL: https://github.com/apache/cloudstack/pull/3371#issuecomment-554427287
 
 
   @syed added comment for QCOW2/KVM only.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] DennisKonrad edited a comment on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
DennisKonrad edited a comment on issue #3179: Redundant VRouter guest network 
on wrong interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554407013
 
 
   @weizhouapache Yes you are right:
   
   > the second function
   prepareNetworkElementCommand(final IpAssocVpcCommand cmd)
   does NOT work for normal setup (linux bridge), if we apply the change in 
#3179 (comment)
   
   That's the reason why I asked about why you want to apply the change in 
https://github.com/apache/cloudstack/issues/3179.
   
   We also thought about another bug beeing the root cause. A wrong MAC seems 
very plausible. I will help test the PR.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] DennisKonrad commented on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
DennisKonrad commented on issue #3179: Redundant VRouter guest network on wrong 
interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554407013
 
 
   @weizhouapache Yes you are right:
   
   > the second function
   prepareNetworkElementCommand(final IpAssocVpcCommand cmd)
   does NOT work for normal setup (linux bridge), if we apply the change in 
#3179 (comment)
   
   That's the reason why I asked about applying the change in 
https://github.com/apache/cloudstack/issues/3179.
   
   We also thought about another bug beeing the root cause. A wrong MAC seems 
very plausible. I will help test the PR.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] weizhouapache commented on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
weizhouapache commented on issue #3179: Redundant VRouter guest network on 
wrong interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554404116
 
 
   @DennisKonrad @svenvogel 
   I will create a PR when I test ok with VPC & RvR & linux bridge. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] weizhouapache edited a comment on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
weizhouapache edited a comment on issue #3179: Redundant VRouter guest network 
on wrong interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554395688
 
 
   @DennisKonrad 
   I did not see any IpAssocVpcCommand  in management server log, so I think 
all are IpAssocCommand , even when ip is associated to a VPC. Please correct me 
if I am wrong
   
   We have seen and fixed many issues with VPC & RvRs in cloudstack 4.7.1, 
especially when there are multiple public ip ranges.
   For example, network element should not be cleaned up when de-associate a 
public ip.
   
https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L377-L382
   If  IP is associated/de-associated to an isolated network, the command 
should be IpAssocCommand 
   If  IP is associated/de-associated to a VPC, the command should be 
IpAssocVpcCommand 
   
   the second function
   ```prepareNetworkElementCommand(final IpAssocVpcCommand cmd)```
   does NOT work for normal setup (linux bridge), if we apply the change in 
https://github.com/apache/cloudstack/issues/3179#issuecomment-552463825
   as you said in 
https://github.com/apache/cloudstack/issues/3179#issuecomment-553641686
   
   I have changed the first function to similar behavior as the second 
function. I got the same issue as the description (source nat ip on eth2, but 
no ip on eth1). Now I can conclude that the issue is a regression issue after 
#2304, but the root cause should be wrong mac address of public ip addresses.
   
https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/network/router/CommandSetupHelper.java#L812-L814
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] weizhouapache commented on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
weizhouapache commented on issue #3179: Redundant VRouter guest network on 
wrong interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554395688
 
 
   @DennisKonrad 
   I did not see any IpAssocVpcCommand  in management server log, so I think 
all are IpAssocCommand , even when ip is associated to a VPC. Please correct me 
if I am wrong
   
   We have seen and fixed many issues with VPC & RvRs in cloudstack 4.7.1, 
especially when there are multiple public ip ranges.
   For example, network element should not be cleaned up when de-associate a 
public ip.
   
https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L377-L382
   If  IP is associated/de-associated to an isolated network, the command 
should be IpAssocCommand 
   If  IP is associated/de-associated to a VPC, the command should be 
IpAssocVpcCommand 
   
   the second function
   ```prepareNetworkElementCommand(final IpAssocVpcCommand cmd)```
   does NOT work for normal setup (linux bridge), if we apply the change in 
https://github.com/apache/cloudstack/issues/3179#issuecomment-552463825
   as you said in 
https://github.com/apache/cloudstack/issues/3179#issuecomment-553641686
   
   I have changed the first function to similar behavior as the second 
function. I got the same result as the description. Now I can conclude that the 
issue is a regression issue after #2304, but the root cause should be wrong mac 
address of public ip addresses.
   
https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/network/router/CommandSetupHelper.java#L812-L814
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] DennisKonrad commented on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
DennisKonrad commented on issue #3179: Redundant VRouter guest network on wrong 
interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554361557
 
 
   @weizhouapache The second function 
   `prepareNetworkElementCommand(final IpAssocVpcCommand cmd)`
does work for linux bridge and ovs at the moment I think. But it doen't 
work for the redundant vpc offering with ovs.
   
   Can you explain why you want to
   > (1) apply the change in #3179 (comment)
   
   Do you think it would be possible to write a mac address map based function 
for both (ovs and linux bridge)?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] weizhouapache commented on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
weizhouapache commented on issue #3179: Redundant VRouter guest network on 
wrong interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554354605
 
 
   @svenvogel @DennisKonrad 
   
   there are two methods to handle ip association in 
LibvirtComputingResource.java
   ```
   public ExecutionResult prepareNetworkElementCommand(final IpAssocCommand 
cmd) {
   protected ExecutionResult prepareNetworkElementCommand(final 
IpAssocVpcCommand cmd) {
   ```
   In the past they have almost same processing. @fmaximus has changed the 
second method in #2304 for openvswitch setup. the first method is not changed 
which might be the root cause of this issue #3679 @DennisKonrad .
   
   For now all ip association in normal setup(vpc with rvr, linux bridge) are 
handled by the first method, which work fine.  I did not see any 
IpAssocVpcCommand (all are IpAssocCommand ) so I am confused how issue 
mentioned in #2304 is fixed. @svenvogel can you give me more details ?
   
   I found the mac address of nic and ip addresses are different, which might 
be why nic device id is determined by broadcast uri instead of mac address, and 
also the reason device id is null reported by @DennisKonrad  in 
https://github.com/apache/cloudstack/issues/3179#issuecomment-553940664
   
   in my opinion, we should 
   (1) apply the change in 
https://github.com/apache/cloudstack/issues/3179#issuecomment-552463825
   (2) different process for ovs and linux bridge in the two method above. to 
be clear, nic device id is determined by mac address map (if ovs) or broadcast 
url (if linux bridge).
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] borisstoyanov opened a new issue #3689: Add LDAP account button is not being shown when ldap configuration is added at domain level

2019-11-15 Thread GitBox
borisstoyanov opened a new issue #3689: Add LDAP account button is not being 
shown when ldap configuration is added at domain level
URL: https://github.com/apache/cloudstack/issues/3689
 
 
   
   
   # ISSUE TYPE
   
* Bug Report
   
   # COMPONENT NAME
   
   ~~~
   UI
   ~~~
   
   # CLOUDSTACK VERSION
   
   
   ~~~
   4.14
   ~~~
   
   # CONFIGURATION
   
   
   
   # OS / ENVIRONMENT
   
   
   
   # SUMMARY
   
   As root admin, when configuring LDAP at domain level we're not able to add 
LDAP accounts from the UI, the button will only show when there's a root domain 
configuration
   
   # STEPS TO REPRODUCE
   
   
   
   ~~~
   1. Configure LDAP at domain level 
   2. Observe there's no 'Add LDAP Account' button
   ~~~
   
   
   
   # EXPECTED RESULTS
   
   
   ~~~
   Administrator should be able to add account at domain level when LDAP 
configuration is available 
   ~~~
   
   # ACTUAL RESULTS
   
   
   
   ~~~
   Button does not appear
   ~~~
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] blueorangutan commented on issue #3425: [WIP DO NOT MERGE] Better tracking host maintanence success and failure

2019-11-15 Thread GitBox
blueorangutan commented on issue #3425: [WIP DO NOT MERGE] Better tracking host 
maintanence success and failure
URL: https://github.com/apache/cloudstack/pull/3425#issuecomment-55441
 
 
   Trillian test result (tid-478)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 28337 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr3425-t478-kvm-centos7.zip
   Intermittent failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermittent failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 75 look OK, 2 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_01_cancel_host_maintenace_with_no_migration_jobs | `Failure` | 27.13 | 
test_host_maintenance.py
   test_02_cancel_host_maintenace_with_migration_jobs | `Error` | 2.60 | 
test_host_maintenance.py
   test_03_cancel_host_maintenace_with_migration_jobs_ports_blocked | `Error` | 
3.72 | test_host_maintenance.py
   test_hostha_enable_ha_when_host_disabled | `Error` | 2.70 | 
test_hostha_kvm.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 301.74 | 
test_hostha_kvm.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] mdominka commented on a change in pull request #3186: Add possibility to set KVM MTU size for all NIC

2019-11-15 Thread GitBox
mdominka commented on a change in pull request #3186: Add possibility to set 
KVM MTU size for all NIC
URL: https://github.com/apache/cloudstack/pull/3186#discussion_r346753828
 
 

 ##
 File path: server/src/main/java/com/cloud/vm/UserVmManagerImpl.java
 ##
 @@ -1054,7 +1061,7 @@ public void validateCustomParameters(ServiceOfferingVO 
serviceOffering, Map

[GitHub] [cloudstack] svenvogel commented on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
svenvogel commented on issue #3179: Redundant VRouter guest network on wrong 
interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554288264
 
 
   @weizhouapache Hi Weizhou, sorry that I rummage in between. i think #2304 
was introduced from @fmaximus because we had some problem with the interface 
order on "OVS", "OpenvSwitch". There was no possibility to add a nat or 
something like that. Now linux bridges and OVS will work. From my side a better 
way would be to change the redundant VR component like the non redundant. 
   
   Can you support on this side? Can you give us some hints how and where we 
change the redundant part of VR?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [cloudstack] weizhouapache commented on issue #3179: Redundant VRouter guest network on wrong interface

2019-11-15 Thread GitBox
weizhouapache commented on issue #3179: Redundant VRouter guest network on 
wrong interface
URL: https://github.com/apache/cloudstack/issues/3179#issuecomment-554266163
 
 
   @DennisKonrad 
   I believe this is a regress issue caused by #2304
   I think we should revert #2304, and look for another solution for the issue 
mentioned in in the title of #2304
   However, I did not find more information about the issue.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services